Microsoft App-V Virtualisation Issues: 5x5x5 – Part 3
This is the third part of my by three part blog and it looks like I might have to add another piece – meaning that this is really the third part of a four-part series…oops.
As mentioned in the previous two postings, we need to get applications working on Windows 7 and App-V: together. This means getting an application successfully deployed and running on an App-V client running on top of Windows 7.
This blog posting relates to the challenges facing administrators who have existing App-V packages (client versions 4.1 and 4.2) that were probably sequenced on Windows XP and who will need to migrate these packages to the App-V client 4.5. In fact, though the most recent client version of App-V is 4.5 CU1, we really should be planning for clients to deploy to version 4.6, which is expected to be released by Microsoft to production soon. Thus, I have tailored our results of the SFT package analysis to take client 4.6 issues into account as well MCITP Certification.
With the updated release of Microsoft App-V 4.5 (and also relating to the update CU1 and 4.6 BETA), there have been a number of significant architectural changes that impacted how applications are sequenced. As a result, the sequencing practices are now different for versions for App-V 4.2 and later versions. As included in the release notes of App-V 4.5, there are now several core components which may generate application compatibility issues with App-V applications including:
..NET Installation Components
.Microsoft Internet Explorer Components
.Microsoft MSI Installer Redistributables
.Core Operating System (OS) components
.Installation artefacts (settings left-over from MSI Installation processes)
In addition to these issues, it appears that empty directories (or folders) that are captured as part of the sequencing process are causing the App-V VFS to crash on certain clients. We have not fully analysed this issue yet, however I’ve included the results for our AOK “Empty Directory Check” Plugin for illustrative purposes:
I am really surprised by the results. And, by means of qualifying the results, this is really a preliminary analysis of these App-V SFT file types. The AOK Plugins may need to be refined or seriously modified based on some real empirical evidence of client issues. That said, all of the manual testing of each of these “classes” of issues did match the AOK Plugin results.
I am going to spend some time analysing these results but it looks like the big issues are .NET and IE integration issues with a surprisingly high number of SFT packages with empty directories – something that is known to crash the Microsoft App-V client sub-system. Maybe some more thought is required here MCTS Training.
To help out with explaining what we are actually looking for in each App-V SFT file, I have included some brief “snippets” of the AOK Plugin descriptions included in this particular report. These descriptions should give you an idea of the things that we are looking for in each application package, and the reason why we are looking there.
Darwin Descriptors Registry Check
This AOK Plugin will analyse each selected and loaded application for the following Registry key HKEY_CLASSES_ROOT\extfile\shell\Open\command within each application package. If a Darwin descriptor registry key has been raised, and AMBER issues will be flagged by the AOK application.
Empty Directory Check
This AOK Plugin will analyse each loaded and selected application package and ensure that the loaded MSI or SFT file does not contain any non-system empty directory table entries. This Plug-in will raise an AMBER issue if these types of directories are detected in an application package.
Internet Explorer Integration Analysis
This AOK Plugin analyses each loaded and selected application package for file entries that are included as part of the Microsoft Internet Explorer 6 (IE6) redistribution package. This Plug-in will raise an AMBER issue if these files are detected in an application package.
Known DLL File Check Analysis
This AOK Plugin will analyse loaded and selected application packages for file level entries that match the list of Microsoft Known DLL’s. The DLL’s contained within this list will not support SxS isolation or any other Microsoft redirection technology. This AOK Plugin will generate AMBER results.
Microsoft .NET Sequenced Component Analysis
This AOK Plugin analyses each loaded and selected application package for file entries that are included as part of the Microsoft Windows .NET redistribution package. This Plug-in will raise an AMBER issue if these files are detected in an application package. Due to the Operating System and .NET installation requirements, if older versions (.NET 1.X and 2.X) are included in a sequenced package then application runtime issues may arise.
Windows Installer Redistributable Analysis
This AOK Plugin analyses each loaded and selected application package for file entries that are included as part of the Microsoft Windows Installer redistribution package. This Plug-in will raise an AMBER issue if these files are detected in an application package.
Sequencer Registry Exclusion Analysis
This AOK Plugin analyses each loaded and selected application package for file entries that are not fully captured as part of the Microsoft App-V sequencing process. This Plug-in will raise an AMBER issue if these registry settings are detected in an application package.
The final blog posting in this series will analyse some of the results and attempt to match these results to real world scenarios and possible application compatibility issues.
