January 14, 2019

Windows-as-a-service use Case

In a previous post we discussed the many advantages of Microsoft’s staggered approach to Windows upgrades – (called Windows as a service, or WaaS”), and the challenges it presents to organizations with large application estates. We also discussed Rimo3’s bulk automation approach, available through the recently launched product ACTIV.

A recent customer deployment (a regional government) illustrates the usefulness of the ACTIV approach: It shows an ancillary ability to deal with complex and problematic application estates. This highlighted ACTIV’s usefulness in ensuring application package estates are up-to-date, and functional. We have chosen to call the process Rationalization – and is the focus of this Blogpost.

The customer was interested in ensuring its current application estate (approx. 700 applications) was compatible, with what was, until recently, the latest available version of Windows 10 – 1803 (build 17299), and turned to ACTIV for help. As the customer is highly distributed across many sites, SCCM was not available, and Rimo3’s sister company, Camwood, was asked to manage the process as a professional service.

Attempting to on-board the customers’ application packages, it became immediately evident that the application estate was chaotic: approximately 1500 packages were found upon initial scan (ACTIV provides a feature that scans selected shared directories for usable installation packages). Unfortunately, most of those turned out to be unusable (out of date, duplicates, fail to install, updates, uninstall only). Many of the packages that did install were found to not install any useful applications. Surprised by this, the packages were retested by ACTIV on a Windows 7 machine.

In the end, using ACTIV’s package management features and ability to retest packages as often as required, the estate was rationalized and shown to have approx. useful 300 packages: Once tested, the following results were obtained:

  • 65% were found to be compatible.
  • 32% were found to be partially compatible: They installed successfully however either these packages installed no usable applications, or some (but not all) of the applications installed failed testing,
  • 3% were found to be completely incompatible (failed to install, or all of the installed applications failed).

It is interesting to note that onboarding and initial testing of the package (A process known as “Discovery” in ACTIV), took approx. 4 days. However, rationalization took a further 2 weeks. Although, once done, applications could be tested and retested with no limitations, including testing on different operating system versions.

The Following examples illustrate the complexities of rationalization

Example 1 – “Duplicate/Redundant” Packages

A package for an application that is continually updated removes previous versions of the application by design.  Thus the Directory Scan feature of ACTIV found multiple packages for different versions of the application. However, because the package for any given version of the application removes the previous version of the application, testing can be carried out against just 1 package, the one which installs the latest version of the application, on the reasonable assumption that by design none of the older versions should exist in the estate.

Example 2 – “Multi MSI Payload” Vendor Install

It is not uncommon for vendors to break installations up into multiple MSI’s along the lines of different products in a suite or different components of the product. Again, the Directory Scan feature of ACTIV would find all of these MSI’s. However, unlike products that perform a static analysis, ACTIV doesn’t need to test each MSI explicitly and hypothesize what the compatibility status might be if a particular MSI is installed. When ACTIV installs a package, any MSI’s that are inherently deployed by the customer’s chosen configuration are thus implicitly tested as well and therefore an actual, not theoretical, compatibility result can be reported.  So 1 Package listed in ACTIV could represent multiple MSI’s that make up an installation without diluting the reported results by including information for MSI’s that are not installed.

Our takeaway from this deployment, so early after the product Launch (October 2018) is that to achieve the full benefit of ACTIV, Packages must be rationalized first. However, ACTIV’s ability to easily install and verify unknown packages is quite useful and greatly speeds up and simplifies the rationalization process.