I am often asked about our algorithmic assessments and runtime testing for the latest iterations of the Microsoft MSIX platform. Here are my thoughts on where Readiness stands and delivers on assessing, converting, testing and publishing to the Microsoft MSIX format.
MSIX assessment – What are the assessment criteria?
Readiness provides through its automated algorithmic assessment engine a rigorous analysis of the application installation logic, content, and intent.
Here is a summary of the types “checks” that performed against each application:
- RELS File Extensions: This check looks for OPC “relationship part” files (.rels) in a folder named _rels.
- Active Setup Detection: This check analyses each application for the presence of Microsoft Active Setup components or logic.
- Advertised Features: This check identifies advertised features that will be installed on demand.
- Click Once Applications: Readiness looks for ClickOnce applications, as they may need additional packaging effort when converting to MSIX.
- COM+ Analysis: This check identifies any COM+ application-level issues.
- DCOM Analysis: An application issue will be raised if any DCOM related entries are found.
- Inaccessible Control Panel Detection: Readiness analyses each loaded and selected application package for the presence of Control Panels applets which do not work on virtualized environments.
- Microsoft Office Add-In Detection: This check detects the presence of Microsoft Office add-ins. Amber issues will be raised if any are present.
- Microsoft Office Add-In Extensibility Detection: This check detects the presence of Microsoft Office add-in extensibility usage.
- MSIX Entry point Analysis: This check ensures that packages contain a shortcut that can be used by MSIX to start the program. The shortcut must point towards an EXE that will be used as the main method for starting the application.
- Non-Supported Drivers – Generic Printer drivers are not recommended for inclusions into MSIX packages.
- Non-Supported Drivers – Printer: This check identifies the presence of printer drivers in an application.
- Non-Supported Drivers – Kernel Mode Drivers are identified as technical challenges for MSIX inclusion.
- Run And RunOnce Detection: This check detects the presence of ‘Run’ and ‘RunOnce’ registry keys and raises issues where they are found.
- Shortcuts on the desktop: This check identifies packages that install shortcuts to the desktop. Desktop shortcuts are not supported in MSIX.
- Unsupported Applications Registry Data: This check identifies MSIX packages that will not be able to integrate with Windows Explorer as well as their original installs.
- Unsupported File Associations This check identifies file registrations that are unsupported by Microsoft’s MSIX platform.
- Unsupported Fonts Detection: This check identifies packages installing custom fonts which are currently not supported by MSIX.
- Unsupported Predefined Shell Object Associations: This check identifies MSIX packages that will not be able to integrate with Windows Explorer as well as their original installs.
- Unsupported Shortcut WkDir: This check identifies packages with a working directory set in its shortcut.
- Web Browser Add-in Detection – Internet Explorer: This check detects the presence of web browser add-ins.
How does Readiness help with MSIX conversions.
One of the challenges of using Microsoft’s MSIX technology over the past years has been the rapid change in features and functionality on the platform. There are multiple versions of the converter tools from Microsoft, several 3rd party vendors offering conversion utilities and Readiness has created their own MSIX creation engine. As a result, we expect that our customers will want to choose what tools and may require multiple conversion cycles (to keep up to date with the latest offerings. Readiness can support multiple tools to convert an application portfolio, and then automatically test the results, providing a baseline assessment for the application portfolio. Basically, what works best for that customer. Given that once imported, applications can be converted automatically by Readiness repeatedly. We recommend this with a periodic “re-compile” of the entire application portfolio.
How does Readiness help with MSIX fixing or “fixups”?
Unfortunately, the conversion process for most applications is not straightforward due the security and platform restrictions imposed by the MSIX application format. Using the list of assessment checks for Readiness as a baseline Readiness offers automated fixes for many compatibility, security and quality challenges that occur during the conversion process. The fixes are automated and fully integrated into the Readiness platform and include (but not limited to) the following:
- Corporate branding and detection keys
- File and Registry Redirection
- Enhanced Shortcut support
- Command line option enhancements
These fixes can be tuned per customer and project and are fully documented and included in any package release.
How does Readiness help with “Smoke Testing” applications?
One of the primary challenges of any conversion project is that how the platform validates each stage and test the output (in this case MSIX packages). Readiness has a unique approach to application, packaging and conversion testing that acknowledges the complexity and unique features of a client’s application portfolio and target platform. Rather than just testing an application, which is fine, but not sufficient – Readiness tests all application on the source platform, and then runs another complete install, runtime, update, roll-back and uninstallation on the target platform. Readiness then performs a “delta” or change analysis on the differences be the two results. This approach can be scaled to multiple platforms with multiple package formats (MSI, MSIX, Liquidware, App-V).
We don’t generally need to know that 200,000 registry keys or thousands of files are installed. We (really) do want to know the following:
- What applications installed on one platform but failed on another.
- Which services did not start on a particular platform.
- Did a firewall change on one platform get implemented successfully?
- Did all the printers get installed? For each application?
- How were Microsoft Defender Exclusions handled?
- Did all the scheduled tasks for each application get handled properly on each platform.
We have included a list of the data recorded and included in our analysis of each package, across each platform and conversion format:
- Shortcut Validation
- Event Logs Analysis
- Disk Usage (across builds)
- Services Check
- COM+/DCOM Reporting
- Printer
- Security Settings
- Environment Changes
- Compatibility (flags and hard stops)
- Scheduled Tasks
- Defender Exclusions
The Readiness team has worked intimately with the App-V team (when the technology was called Softricity and based in Boston) and has operated within the MSIX engineering and leadership team since its inception. Our history with the MSIX fix ups goes back even further with members of Readiness involved with the Detours project within Microsoft – the basis for the folder and registry redirection fix-ups. Delivering MSIX packages for insurance providers, medical device provides and the public service sector in both the UK and US has provided Readiness with the expertise, but more importantly a tested, trusted platform to assess, test and deliver MSIX packages with a 100% guarantee on all deliveries.
