Back in App-V 4.x and earlier, the client could not quite cope with any apps that required admin rights. Since Vista, applications should have an embedded or external manifest file that defines the requested execution level, either:

• asInvoker – Run with limited user rights unless specifically elevated or called from an already elevated process
• highestAvailable – Request admin rights if the user is an admin, otherwise run without them
• requireAdministrator – Request admin rights; application will not launch unless they are granted

If either of the last two were specified, the app would fail to launch as the sfttray.exe launch process was not compatible with UAC. The common fix was to add an environment variable to the package __COMPAT_LAYER=RunAsInvoker (note the double underscores at the beginning!). This would then instruct Windows to override the requested execution level with ‘asInvoker‘ for all applications in that virtual environment.

By the way, there are a few ways of checking the value used by an executable:

• Use Sysinternals SigCheck tool with the -m switch to dump the internal manifest
• Use Sysinternals Process Explorer to view the strings contained within any running process
• Use a resource editor such as Resource Hacker to view the manifest directly

External manifest files are also possible, although Windows is configured by default so that the internal ones take precedence.

This issue of not being able to launch these applications no longer exists in App-V 5 since it has been written from the ground up to work with UAC. If a sequenced application requires admin rights, it will also request admin rights when deployed on the client.

I was sequencing an application in App-V 5 that specified the ‘requireAdministrator’ setting – it only needed this so that it was able to write to a certain area of the HKLM registry for licensing purposes. Since the App-V sandbox allows full write access to the registry (and also optionally the file system as of 5.0 SP2 Hotfix 4), admin rights were not actually needed, so I was looking for the best way to suppress this UAC prompt to allow standard users to launch the application. Here are the options:

• AppSense / Avecto (and others) – There are dedicated privilege escalation suites out there to dynamically grant admin rights to various processes without the user requiring a full admin account. The client I was working with did not have any of these available so this was not an option.
• Replace the internal manifest – I know this is possible using certain Microsoft tools mt.exe and mage.exe, but have never gone so far to attempt it. I have recently discovered that my trusty old Resource Hacker tool can be used to edit the internal manifest directly! This method could cause issues if the binaries are signed however as it would invalidate the digital signature.
• Add an external manifest – This is not the preferred solution as you also need to reconfigure Windows to prefer the external manifest, which poses additional risks.
• Add a local registry shim – When you view the properties of an exe you can enable certain shims such as ‘Windows XP SP3′ or ‘Run As Administrator’. These are stored in the registry and use the exact same naming format the __COMPAT_LAYER variable – so although the property form has no option for it, you can specify RunAsInvoker here too. The only caveat is that these registry keys need to be set outside the virtual environment, perhaps by a script.
• Application Compatibility Toolkit – Rather than manage shims by directly manipulating registry, ACT can used to select the exe(s) and shim(s), and export to a database file which can be reimported on each client.
• Add the __COMPAT_LAYER=RunAsInvoker environment variable to the virtual application – Our old friend; however, I could not get this to work. At first, anyway!

So I attempted to add this environment variable to my package to suppress the UAC prompt, by running the following command from an elevated command prompt during monitoring:

setx __COMPAT_LAYER RunAsInvoker /m

But it did not work. If I launched a command prompt in the bubble though, I could see the environment variable was set, and if I launched the exe from there, it obeyed the setting and launched without UAC! Using Process Monitor, I could see that when the application was launched from the start menu, the process was created without the environment variable; yet when I viewed the same process in Process Explorer, the environment variable was there. I can only assume that the App-V client attaches the virtual environment variables to the process just after it launches, which is too late for the __COMPAT_LAYER setting to work its magic.

My solution was to alter the shortcut to run cmd.exe as a middleman; this process will be started, the environment variables added, then it will start my application which will inherit the variable from the parent process:

You will also need to manually set the icon and ensure the ‘Start in’ field is set to the application directory.

This did the trick! No more UAC prompts and standard users can now launch the application.

This is a bit of a hacky workaround though, and in environments where cmd.exe is blocked for standard users, you will have to resort to an alternative man in the middle such as VBScript or PowerShell. Tim Mangan’s LaunchIt tool should in theory be able to do the trick also, or any stub exe that is capable of passing on parameters to launch another application. You could even write your own pretty easily in C++ or C#, which I just might do one day if the need arises.

Just sequenced an app that deployed a shortcut with a space at the end of the name, which went unnoticed. Imported the  resulting package using PowerShell to quickly test, all went fine, but it failed to deploy with SCCM due to invalid xml.

SCCM will always use the configuration xml files, but I did not apply these during testing as I had made no changes to them!

The event log states:

Failed to validate provided xml.
DOM Error: Unknown HResult Error code: 0xc00ce169
Reason: ‘MYAPPNAME ‘ violates pattern constraint of ‘[^\s]|([^\s].*[^\s])’.
The element ‘{http://schemas.microsoft.com/appv/2010/deploymentconfiguration}Name’ with value ‘MicrodietV2 ‘ failed to parse.

So for some reason a name ending in a space is perfectly valid in the manifest file contained within the appv file, but not in the external xml files. Watch out for this, and Microsoft please update your regular expression to allow for this, or at least detect/correct it in the sequencer!

This may be intersting to those that have longed for Microsoft to provide a solution to virtualising IE in App-V. If you download the latest IE preview from the Internet Explorer Developer Channel, you will find it is packaged with App-V and bundles in a version of the App-V client! In fact, it fails to install if you have the App-V client already installed (although you can extract the IEDC.appv file and publish it to a regular App-V client, the only other pre-req is to have IE11 installed).

I’m told that Microsoft have no plans to release IE in App-V format for production use however!

Well, I have been for 6 weeks now – I meant to post this a while back, but better late than never!

I am honoured to have received the Most Valuable Professional (MVP) for App-V from Microsoft. If you’ve never heard of the MVP program, you can find out more here. But in a nutshell, it’s a way for Microsoft to reward those who make top contributions to technical communities via conferences, forums and websites like this (among other ways). As a result, I now get to participate in regular product group interaction sessions with the App-V team where we get to give our feedback and hear about what’s coming in the future, and also get invited to the annual MVP Summit in Redmond. There are plenty of other benefits too, including free subscriptions to MSDN and Office365, and many vendors offer free licenses of their software to MVPs also!

Big thanks those that helped make this happen, including Nicke Källén, Rory Monaghan and Tim Mangan among others. Also to Colin Bragg, who not only first got me involved with App-V and also inspired me to start this site!

If you’re interested to know who the other App-V MVPs are around the world, click here.

Want to be an MVP? Here’s what it takes:

• Start a blog site and post original content that helps others – not steal content from other people’s blogs like some have done to me and others!
• Present at conferences and user groups, or organise your own!
• Contribute to forums such as Technet and AppVirtGuru.
• Produce (or assist in producing) additional written content such as books and whitepapers on your technical subject of expertise.
• Engage with other MVPs and users through social media like Twitter and LinkedIn (not Facebook – that’s for sharing dumb clickbait articles and drunken photos!)

You may have seen Nicke Källén’s blog post about this issue recently along with some workarounds provided by the App-V community:

http://www.applepie.se/app-v-and-wisptis-exe

Microsoft have now however provided an official fix in the form of an update rollup to the .NET Framework, I recommend anyone using App-V apply this as soon as possible!

http://support.microsoft.com/kb/3026376/en-us

Just a quick post to warn of something I encountered today. I had an application that required an older Access 2007 Runtime (Access 2013 was installed locally). The sequencer picked up Access 2007 as an application along with all of its filetype associations, which I duly deleted in the last tab of the sequencer before saving the package.

However these filetype associations still exist, and after publishing the application, Office 2013 triggers a time consuming self-repair when the user double-clicks on an mdb file.

The solution is to disable these FTA’s from within the configuration files; I could do this quickly by disabling the entire subsystem as my application did not register any. But if your application has some, you will need to comment out all of the Access related ones, which is no simple task as there are so many!

I applied this change to both DeploymentConfig and UserConfig xml files (as I did not know how the app was going to be published):

<FileTypeAssociations Enabled=”false“>

Whilst I was digging around in this file I also noticed an app path was registered. Trying to run msaccess.exe via Explorer’s run box tried to launch the virtual Access 2007 runtime rather than my local Access 2013. It would be possible to disable this entire subsystem also:

<AppPaths Enabled=”false“>

However my application had an app path I wished to keep so I just commented out the ones I did not require:

<!–Extension Category=”AppV.AppPath”>
<AppPath>
<Name>MSACCESS.EXE</Name>
<ApplicationPath>[{ProgramFilesX86}{~}]\MICROS~1\Office12\MSACCESS.EXE</ApplicationPath>
<PATHEnvironmentVariablePrefix>[{ProgramFilesX86}]\Microsoft Office\Office12\</PATHEnvironmentVariablePrefix>
<ApplicationId>[{ProgramFilesX86}]\Microsoft Office\Office12\MSACCESS.EXE</ApplicationId>
<CanAcceptUrl>1</CanAcceptUrl>
</AppPath>
</Extension>
<Extension Category=”AppV.AppPath”>
<AppPath>
<Name>MsoHtmEd.exe</Name>
<CanAcceptUrl>1</CanAcceptUrl>
</AppPath>
</Extension–>

Remember these config files are not used by default when either publishing from the App-V Mangement Server or installing from the MSI so they will need to be specified. If you are using the MSI packages I have a solution to import the config files over here.

If you didn’t know, I spend most of my days sequencing and packaging applications, and fixing broken packages. This is just a quick post to detail two App-V 5 apps I’ve fixed today, perhaps the information may be of use if you encounter similar issues on the front line!

Access 2007

This customer had Office 2007 on the base and Access 2007 deployed via App-V so that they could control who had ‘access’ to it (badoom-tish). All worked fine until you tried to export some data to Excel, where Excel would refuse to load with an ‘out of memory’ error. It turns out that Excel just flat out refused to open inside the virtual environment of this package. I suspected that it was because this Access package had been sequenced on a clean machine, making various Office folders and registry keys set to override. Resequencing with Office 2007 already on the base resolved the issue.

In-house App

This in-house line of business application was located on a network share, and the App-V package was simply used to create a shortcut pointing to the exe on the network share. For some reason, it refused to connect to its database when run inside the virtual environment. Since the App-V package contained no files or registry entries, I decided to start my troubleshooting by disabling these virtual subsystems in the package config files. I started with the registry:

<Registry Enabled=”false“>

Hey presto, that worked, but I’m not going to pretend to know the reason why! But sometimes you just have to accept you’ve fixed it and move on, there’s plenty more broken apps needing my attention!

The MDOP 2015 release which includes App-V 5.1 is now available.

Microsoft have a very good summary of what’s new in the 5.1 release, so rather than repeat that I will just direct you there!

https://technet.microsoft.com/en-us/library/mt346500.aspx

Not many of you would want to actually sequence this… If you are using App-V, chances are you have licenses to use Microsoft Office already! But if you want to learn a cool trick that might help out with other apps, read on!

This one was coming up with an error on launch:

Procmon showed that it was trying to access (but could not find) the user profile of the account used to sequence it, even though it was not launched during sequencing, there was no appdata folder in the package, and there was no evidence of the user name stored anywhere that I could find. This is a prime example of why you should always use a different account to test the app than the one used to sequence it by the way!

My solution was to install the MSI under the System account during monitoring. The user profile for this account is stored under C:\Windows\System32\config\systemprofile, and with VFS Write enabled, users should not have a problem accessing this folder within the bubble. To do this I used Sysinternals tool PsExec to start a CMD prompt as System:

psexec -s -i cmd

Then install the software from within there.

Now the sequenced package works! I could not find it trying to write to the System profile during use, instead the application writes to %APPDATA%\LibreOffice as intended, but this little trick solved whatever was causing it to hiccup during launch previously.

You may have noticed Windows Firewall prompts appearing when launching virtualised applications:

This is because App-V does not support detecting or applying firewall rule changes. You could of course apply these rules via group policy, but this becomes difficult since the rule needs to contain the full path including the package and version GUIDs. We can however apply them with a script!

On your sequencer, open the advanced firewall settings by running wf.msc and find the rules that were added by the application. If the installer did not add them, then launching the application and dismissing the dialog as shown above will create a rule for you. You may have both inbound and outbound rules to deal with.

As mentioned in this article, you should use the netsh advfirewall firewall command rather than the deprecated netsh firewall command. The full syntax for this command can be found here. You should take care to ensure that the rules you set up adhere to any security policies in your organisation (e.g. you may want to only allow an app to communicate if connected to the domain network) so don’t necessarily copy the examples provided here exactly. The basic form I am using here for an outbound rule (use dir=in for inbound) is:

netsh.exe advfirewall firewall add rule name="RULE NAME" dir=out action=allow program="PATH TO EXE.exe" enable=yes

And to remove:

netsh.exe advfirewall firewall delete rule name="RULE NAME" program="PATH TO EXE.exe"

This particular application adds two rules so I am going to use the new Scriptrunner.exe method that requires App-V 5.1. For more info on how to do this refer to the following links:

https://blogs.technet.microsoft.com/sbucci/2015/09/14/app-v-5-1-scriptrunner

https://technet.microsoft.com/en-us/itpro/mdop/appv-v5/about-app-v-51-dynamic-configuration

I am also going to use another feature added in 5.1, which is the ability to place the script inside the internal AppXManifest.xml so that we don’t have to rely upon the external DeploymentConfig.xml file. I used Tim Mangan’s excellent App-V Manifest Editor tool to make this easier. This results in the following snippet added to AppXManifest.xml:

<appv:MachineScripts>
  <appv:AddPackage>
    <appv:Path>Scriptrunner.exe</appv:Path>
    <appv:Arguments>-appvscript netsh.exe advfirewall firewall add rule name="Rule 1" dir=out action=allow program="[{ProgramFilesX86}]\MyApp\MyApp.exe" enable=yes 
-appvscript netsh.exe advfirewall firewall add rule name="Rule 2" dir=out action=allow program="[{AppVPackageRoot}]\MyApp.exe" enable=yes</appv:Arguments>
  </appv:AddPackage>
  <appv:RemovePackage>
    <appv:Path>Scriptrunner.exe</appv:Path>
    <appv:Arguments>-appvscript netsh.exe advfirewall firewall delete rule name="Rule 1" program="[{ProgramFilesX86}]\MyApp\MyApp.exe" 
-appvscript netsh.exe advfirewall firewall delete rule name="Rule 2" program="[{AppVPackageRoot}]\MyApp.exe"</appv:Arguments>
  </appv:RemovePackage>
</appv:MachineScripts>

And since SCCM automatically imports the DynamicConfig.xml, the script should go in there too, otherwise the blank entries in the generated file may override what’s provided in the manifest:

<MachineScripts>
  <AddPackage>
    <Path>Scriptrunner.exe</Path>
    <Arguments>-appvscript netsh.exe advfirewall firewall add rule name="Rule 1" dir=out action=allow program="[{ProgramFilesX86}]\MyApp\MyApp.exe" enable=yes 
-appvscript netsh.exe advfirewall firewall add rule name="Rule 2" dir=out action=allow program="[{AppVPackageRoot]\MyApp.exe" enable=yes</Arguments>
  </AddPackage>
  <RemovePackage>
    <Path>Scriptrunner.exe</Path>
    <Arguments>-appvscript netsh.exe advfirewall firewall delete rule name="Rule 1" program="[{ProgramFilesX86}]\MyApp\MyApp.exe" 
-appvscript netsh.exe advfirewall firewall delete rule name="Rule 2" program="[{AppVPackageRoot]\MyApp.exe"</Arguments>
  </RemovePackage>
</MachineScripts>

I’ve opted to use AddPackage and RemovePackage here rather than PublishPackage and UnpublishPackage. The reason for this is that again, when deploying with SCCM, it imports the UserConfig file which overrides the PublishPackage script defined at the machine-level (which I consider a bug, but that should be another post!).

Now after adding that package you should be able to see your rules added in the firewall settings on the App-V client. If you used an App-V variable as above like [{ProgramFilesX86}] or [{AppvPackageRoot}] when defining your exe path, it should be converted to the full virtual path under C:\ProgramData\App-V!

Assemblies written using the .NET Framework aren’t compiled directly to machine code. The exes and dlls are like a halfway house between written code and pure machine code, and are compiled ‘just-in time’ by the .NET Framework as required. This enables them to run on any processor type rather than needing separate binaries for 32-bit and 64-bit.

The .NET Framework has a background service that compiles some of these assemblies to pure machine code (referred to as ‘native images’) to increase performance. By default it usually just processes the components belonging to the .NET Framework, but application installers can also add some of their own components to the queue.

Myself and Tim Mangan have referenced this in the past, here’s a few related posts:

http://packageology.com/2012/09/fix-net-applications-broken-app-v-security-updates

http://www.tmurgent.com/TmBlog/?p=2175

http://www.tmurgent.com/TmBlog/?p=2350

The main points of those articles are:

• Native images captured in the sequence are used
• Application crashes can occur if a .NET Framework update on the client renders these native images invalid (do not sequence with an unpatched .NET 4.0!)
• Application crashes could also occur if monitoring is stopped before the compilation process has completed

I came across an issue at a client site recently where a sequenced application was crashing. Opening the package showed that it had captured lots of native images belonging to the .NET Framework, and there were also messages in the event log that appeared to be warning about mismatched versions of .NET components. It turns out the application required both .NET 3.5  (which wasn’t installed by default on the Windows 8 sequencer) and 4.6 (which wasn’t installed either). Both of these were installed before sequencing, but then the monitoring process picked up various native images of core .NET components coming from the background compilation process, which I can only assume were causing conflicts on the client.

My recommendations are as follows. Create a simple batch file that runs the following commands (the 2nd one is only required on x64):

C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executequeueditems C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executequeueditems

These commands force the compilation of the current queue to speed things along. You should run this on your sequencer whenever you install a new version of the .NET Framework or apply Windows Updates. You can even add it to the startup folder under the start menu on your sequencer to ensure it is run before you start sequencing. It’s also a good idea to run this after installing the application, just before stopping the monitoring process. After re-sequencing with these practices in place, the application crashes were cured!

I fixed an application recently (KeySIGN add-in for AutoCAD) that added three new environment variables and used these as parameters in the shortcut it created. I do not have the exact detail to hand but the form was something like this:

"C:\Program Files\MyApp\MyApp.exe" "%VAR1%\MyApp.ini" "%VAR2%\Another.ini" "%VAR3%"

When launching on the client, it complained that it could not find a file, the path of which was specified by one of these variables.

The explanation is simple; the sequencer captured the shortcut exactly as it was put down, but when Windows came to launch it on the client, it had no knowledge of these variables, as they only exist within the confines of the virtual environment. There are two main workarounds available for this:

• Modify your shortcut during monitoring to replace the environment variable with its actual contents. In this instance this was not an option, as I had three variables each with long paths and there was not enough room to enter the entire command!
• Modify your shortcut to run cmd.exe as a middleman – when cmd.exe starts it will be able to see the new environment variables and use them to start the application. Here’s an example command:

C:\Windows\System32\cmd.exe /c START "" "C:\Program Files\MyApp\MyApp.exe" "%VAR1%\MyApp.ini" "%VAR2%\Another.ini" "%VAR3%"

If you’re wondering what the “” is for, if START sees spaces in the following command it thinks it is receiving multiple parameters, the first of which being the window title; so we give it an empty one to satisfy it!

UPDATE: This issue can now be resolved by adding a registry key, see here for further details.

Office 365 uses a new installation technology named ‘Click-to-Run’ that shares it roots with App-V and the new App-X application model. In fact you will notice that they use very similar folder structures, for example:

C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesX86

Also if you view the running process for Word for example in Sysinternals Process Explorer, in the bottom pane that shows the loaded dlls you will see AppVIsvSubsystems32.dll (App-V uses AppVEntSubsystems32.dll).

A common scenario in App-V deployments is to have Office installed locally, then virtualise add-ins either by creating separate shortcuts to launch each Office app with each add-in, or use RunVirtual to drag them kicking and screaming into a virtual environment with the required add-ins. Most folks simply do not virtualise their core install of Office, since if you come across an add-in or other application that requires Office but has problems with App-V, you might have to roll back the whole solution and install Office natively.

This is all well and good, unless you are using a copy of Office installed from the Click-to-Run source, which is all editions of Office 365, and the retail copy of Office 2016 (or at least the one available from MSDN). Perhaps because the Office applications hook the competing AppVIsvSubsystems32.dll, it does not seem to possible to launch these applications ‘in the bubble’.

I ran into this issue a couple of years ago:

https://social.technet.microsoft.com/Forums/en-US/86103a0c-f33b-47b4-a7f9-1490d6700313/virtualizing-an-office-addin-with-office-365-installed-possible?forum=mdopappv

I advised the client at the time to remove Office 365 and install the volume license media for Office 2013, which resolved the issue. I came across this again at another client recently. However they were informed by Microsoft that the Click-To-Run media was the only option for them with their Office 365 subscription! Which reduces their options down to these:

• Virtualise Office, easy enough to do by converting the Click-To-Run source to App-V format using the Microsoft provided documentation, then pray that all of your apps that need Office also play nice with App-V.
• Keep Office 365 installed and forget about virtualising any apps that contain Office add-ins or that need to be able to launch Office apps in their own virtual environments to work.

I’m surprised to not have seen many complaints on this, although I expect to see more as more as enterprises sign up to Office 365!

This is an issue that has been known to many since Internet Explorer 11 was released, discussed on various forums, but never to my knowledge distilled into a blog post. I hit this issue in an unexpected way recently so thought it was high time it was shared!

Basically, when IE11 is launched for the first time for each user, the initial setup needs to happen outside of a virtual environment, otherwise it freezes/crashes.

The unusual way I came across this was that I had sequenced AutoCAD Civil 3D 2017, which worked fine on all machines except the new Windows 10 clients. It turned out that the application shows a splash screen that hosts an IE window, which was locking up the application. We did not see this on the other clients as they had already launched IE in the past. IE had never been launched on the Windows 10 clients because the the default browser was Edge!

One workaround for this is to use Active Setup to launch Internet Explorer once per user per machine. Paste this into a .reg file if you want to try this method:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\LaunchInternetExplorer]
@="Launch Internet Explorer"
"Version"="1,0,0"
"StubPath"="C:\\Windows\\System32\\cmd.exe /c START \"\" \"C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe\""

If you happen to have IE in a Connection Group via RunVirtual, then you will need some kind of script to open IE before creating the RunVirtual keys. I’ll leave that one to you!

As you may know, the App-V sequencer also spits out an old-school MSI package by default as part of its output. These are useful not only if you just want to quickly import a package for testing, but also for those using 3rd party deployment tools or Microsoft Intune to manage their packages. I have previously published a couple of .MST transforms to deal with various issues found in the MSI packages that the App-V sequencer creates:

Applying Dynamic Config To App-V 5 MSI Packages

Fix For MSI Packages Created With App-V 5.0 SP1

The format of these MSIs has changed slightly through the releases:

• 5.0
  • Initial release.
• 5.0 SP1
  • MSI packages broken and fail to install!
• 5.0 SP2
  • Custom action added to quit if a repair action is detected. Previous versions would wipe out a registry key during repair that prevented the MSI from being uninstalled.
  • Launch condition added to prevent older version of an MSI being installed over a newer one.
  • Platform no longer set to x64 on packages created with the 64-bit sequencer. No big deal, just that these packages take longer to fall over as they fail to install rather than get blocked at the very beginning.
• 5.0 SP3
  • Custom action modified to automatically import DynamicConfig.xml file.
  • Custom actions broken so that MSI will now only install/uninstall from an elevated session!
• 5.1
  • Reverted to 5.0 SP2 format!
• 10.0.14393 (from Windows 10 ‘Anniversary Update’ v1607 ADK)
  • Launch conditions now use AppSearch and RegLocator tables to look for HKLM\Software\Microsoft\AppV\Client instead of the Sequencer MSI
  • Current implementation is broken as packages created on 32-bit look under the 32-bit registry area on a 64-bit machine and fail to detect the App-V client.

A new issue has reared its head recently. Up until now, the MSI packages checked for the existence of the App-V client MSI before they will proceed. With the new Anniversary Update v1607 for Windows 10, the App-V client is built in, so this check fails and you are unable to install the MSI packages. The sequencer bundled with the latest ADK resolves this, and Microsoft recently issued an official workaround to remedy existing packages:

https://technet.microsoft.com/en-us/itpro/windows/manage/appv-release-notes-for-appv-for-windows

However (at the time of writing) this does not work by simply following the steps listed, so here are the additional steps required!

• You need to install the Windows 7 SDK, as the msidb.exe tool it relies upon was deprecated since the Windows 8 release. You just need the Tools feature under Windows Native Code Development.
• You then need to set an environment variable MSSDK pointing to the install location of this. To do this in your Powershell session type:
  

  $env:MSSDK = 'C:\Program Files\Microsoft SDKs\Windows\v7.1'

• In Powershell, the function is not available until you ‘dot-source’ the script:
  

  . .\Update-AppvMsiPackage.ps1

Whilst the official fix above will make it possible to deploy your MSI on Windows 10, may I present to you an alternative…

The Über Fix

I have updated my MST to fix all of the known issues and bring back the 5.0 SP3 functionality. By creating a base MSI with all of the issues it was possible to create a transform that will apply to all versions; the one exception being to fix the MSIs created by the Windows 10 v1607 x86 sequencer (you cannot add a row and modify the same row within the same transform). There is also a script to apply the changes directly to an MSI, or even a whole folder full of them, so that you don’t have to rely upon the MST being set up correctly during deployment.

Download Links

Direct Download:

https://github.com/DanGough/Fix-AppvMsiPackage/archive/master.zip

GitHub Repo:

https://github.com/DanGough/Fix-AppvMsiPackage.

Contents

• Fix-AppvMsiPackage.mst – This contains the bulk of the fixes.
• Fix-AppvMsiPackage_1607x86.mst – This contains just the small change necessary to allow Windows 10 v1607 x86 MSIs to install on x64 clients.
• Fix-AppvMsiPackage.ps1 – A Powershell script to apply the transforms directly to an MSI.
• Fix-AppvMsiPackage.cmd – A helper script companion to the .ps1 file to allow drag and drop operation.
• WixToolset.Dtf.WindowsInstaller.dll – Dependency of the Powershell script.
• Base.msi – The base MSI used to create the MST file. If you wish to modify the MST yourself, you should do so against this package otherwise you may lose elements of the transform upon save.

What Does It Do?

• Packages can now install with the App-V client built into Windows 10 v1607.
• MSIs will now automatically apply DeploymentConfig.xml (using 5.0 SP3 method)/
• You can now install packages just by double clicking on them as UAC elevation now works properly.
• You can also uninstall and repair from Add/Remove Programs. Repairing will now add / publish the package if it was removed, and will repair extensions to bring back deleted shortcuts etc.
• The ‘change’ option has been removed from Add/Remove Programs, since they have no features to select.
• Packages now have an App-V icon in Add/Remove Programs, making it easy to tell which apps are virtualised.
• Packages are prevented from installing over a new version.

How Do I Use It?

There are a couple of ways:

Apply MST Dynamically During Deployment

Specify the TRANSFORMS property on your msiexec command line to apply the changes at install time without modifying the MSI, e.g:

msiexec /i <PATH TO MSI> /qn TRANSFORMS=Fix-AppvMsiPackage.mst

If you are deploying MSIs created with Windows 10 v1607 x86 on an x64 client, you will need to layer on the additional fix:

msiexec /i <PATH TO MSI> /qn TRANSFORMS=Fix-AppvMsiPackage.mst;Fix-AppvMsiPackage_1607x86.mst

Fix Your MSI(s) Before Deployment

Simply run the Powershell script Fix-AppvMsiPackage.ps1, passing a parameter of either an MSI file name, or a folder path that contains one or more MSI packages, e.g:

.\Fix-AppvMsiPackage.ps1 'C:\Test\Test.msi'

.\Fix-AppvMsiPackage.ps1 '\\appvserver\content'

If you forget to supply this, it will ask for it. If a folder is given, the script will recursively search for all MSIs within, so take care. Any existing MSI will be backed up with the .bak extension (and it will not overwrite these .bak files if it is re-run).

The dependency WixToolset.Dtf.WindowsInstaller.dll needs to be located in the same folder as the script. This library is pinched from WiX, and I must give credit to Laurie Rhodes here for helping me get on the bandwagon with this one. Seriously, if you are interested in writing Powershell scripts that interact with Windows Installer, and Heath Stewart’s Powershell Module doesn’t have you covered, using this library is a hell of a lot easier than using the COM interface!

To make your life easier, simply drag and drop your MSI or folder on top of the Fix-AppvMsiPackage.cmd file. As long as the .ps1 and .dll are in the same location, will process whatever you drop onto it!

I recommend you run this script against all of the template MSI packages found in the sequencer directory, e.g:

.\Fix-AppvMsiPackage.ps1 'C:\Program Files (x86)\Windows Kits\10\Microsoft Application Virtualization\Sequencer'

This way, any packages you create with the sequencer will have the fixes built in already!

This goes without saying, but this is all provided on a use-at-your-own-risk basis. But if you have any issues, comment below and I’ll do my best to fix them.

Known Issues

It appears that all of these MSI packages fail to install if Powershell execution policy is applied via Group Policy. The installer fails with the message:

Failed to publish the package due to the following error: Windows Powershell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specfic scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted.

This is a benign warning since policy has set the system to Unrestricted, but the installer is treating it as a fatal error. This would require Microsoft to modify the custom action dlls to fix this, unless I bin them all and replace them with Powershell commands. This isn’t a road I’m going to go down, but if this is a show stopper for you, get in touch!

In my previous post on this subject, I came to the conclusion that Office 365 apps just wouldn’t run in an App-V virtual environment. However there is a fix for this that can be applied to the client registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClickToRun\OverRide] "AllowJitvInAppvVirtualizedProcess"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ClickToRun\OverRide] "AllowJitvInAppvVirtualizedProcess"=dword:00000001

Now, the only official mention of this key anywhere online used to be in this knowledge base article:

https://support.microsoft.com/en-us/help/3159732/-click-to-join-fails-to-invoke-skype-for-business-on-computers-that-us

Even a Google search for ‘AllowJitvInAppvVirtualizedProcess’ turns up this article, however all reference to it has now been removed. What this means in terms of support I have no idea, so this setting should be added at your own risk; however I have found it to fix multiple issues including:

• Creating shortcuts to Excel as a way to sequence Excel add-ins
• Pasting Visio objects from virtualised Visio into Office 365 Word

I have so far not seen any negative effects from using this setting and am recommending that people use it, with the disclaimer that anybody should contact Microsoft support before doing so!

App-V 4.x gave you the option of either installing an application to its default location on C: (known as a VFS install), or a special virtual drive Q: (known as an MNT install). Best practice was to use this MNT (or mount) drive since everything ran slightly quicker due to the file system driver not having to layer those files over the existing OS contents. However some apps were fussy and would only work with either an MNT of VFS install. One of the first things the sequencer did was to ask you to enter the location of the root directory on Q: where you would be installing to.

For App-V 5, Microsoft pretty much re-wrote everything from scratch. The virtual drive letter was no more, but the sequencer still asked the user where the Primary Virtual Application Directory (PVAD) was prior to sequencing. This caused many people to question why it still worked like this and found that you can just enter a dummy folder name in here every single time and most apps would still work just fine. In the end Microsoft removed this PVAD functionality from the sequencer (although you could bring it back with a startup switch or registry key).

Just as with App-V 4 where some apps required either a VFS or MNT install, today there are many apps that require to be sequenced to the PVAD in order to work. In fact it’s one of my primary troubleshooting steps if an app is not working as expected, as it can often magically fix problems without having to bang your head against Procmon trying to work out what’s going wrong. But what difference does it make under the hood if you install to the PVAD and why is it required to enable certain applications to work? I believe it boils down to two main reasons:

Shortened Paths

Paths can get ridiculously long in App-V 5. Instead of running from C:\Program Files\MyApp, your app could now be running from C:\ProgramData\App-V\ReallyLongGUID\AnotherReallyLongGUID\Root\VFS\ProgramFilesX64\MyApp. This could make you hit the 260 character path limit, or hit another limit when it comes to shortcuts, especially if your command line features parameters that also contain these long paths. Sequencing to the PVAD means the app could be running directly from the Root folder, resulting in shortened paths.

This problem is less common than the next one I will describe, but a PVAD install of some versions of Crystal Reports for example is known to resolve issues for this very reason.

Path Values in the Registry

This was a eureka moment for me as it means it is possible to fix some apps by changing a single registry key instead of having to re-sequence them to the PVAD.

If you have a registry value that points to the install location of your application, for example C:\Program Files\MyApp, they would be encoded differently in the registry of the resulting package depending on whether or not you used the PVAD:

VFS Install: [{ProgramFilesX64}]\MyApp

PVAD Install: [{AppVPackageRoot}] (assuming the PVAD was set to C:\Program Files\MyApp)

When the package is published on the client, these variables are replaced but they are handled rather differently. Inside the virtual environment, the registry values would read as:

VFS Install: C:\Program Files\MyApp

PVAD Install: C:\ProgramData\App-V\ProductID\VersionID\Root

Now, when you hit an issue with an app that doesn’t like being installed to the VFS, you often get a cryptic error message suggesting that the app has realised things have moved. For example, ArcGIS:

Also WinZip (this is v15, they seem to have fixed this issue in recent versions BTW):

I believe that App-V’s file redirection works the same way for the VFS and PVAD; the exes are running from C:\ProgramData\App-V and if they ask the OS where they are running from they will be told so. If the app happens to request reads or writes to the C:\Program Files path originally installed with, then it will step in and perform the redirections as required. However, if you did a VFS install, registry entries would still say C:\Program Files. If the app tries to be too clever and verify itself by comparing the known install location pulled from the registry to the actual runtime location, that’s when things can go awry.

So as an example, the error seen in WinZip above goes away if you open RegEdit in the bubble and change the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ProductCode\InstallLocation to reflect the actual path where the exe now lives. So change the value from this:

C:\Program Files\WinZip

To this:

C:\ProgramData\App-V\ProductID\VersionID\Root\ProgramFilesX64\WinZip

So it appears that WinZip is saying “hey Windows, where am I running from?” and comparing that to this registry value, and thinking something is wrong if they don’t match.

To fix this in the actual package, you need to be a bit sneaky and substitute in the [{AppVPackageRoot}] variable. So the original value in the package when sequenced to the VFS would be:

[{ProgramFilesX64}]\WinZip

Change this to:

[{AppVPackageRoot}]\VFS\ProgramFilesX64\WinZip

I’ve fixed a handful of apps using this method now instead of having to re-sequence the entire application, I’ll try and post more info as I encounter them!

As demonstrated in my previous article, older versions of WinZip had issues with App-V 5, requiring you to either install to the PVAD or hack the registry to get it to run. WinZip fixed this at some point during the last couple of years, however I attempted the latest version 22 when writing that article only to find it fail in a completely different way! Try a standard sequence and select the option to edit the resulting capture before saving, and you will see this:

Failed to load virtual services information – Failed to create a manifest instance.

The last time I hit a similar issue with the sequencer generating an invalid manifest, it crashed out completely, requiring you to choose the quick save option to even get a package out of it that you could even debug. At least now in this Windows 10 1703 sequencer things are handled a little more gracefully.

However it appears they’ve taken one step forward and two steps back here, as the event logs that you could view to identify exactly which section of the manifest was at fault are no longer in Windows 10 1703! I had to try and add this broken package to a Windows 7 machine with App-V 5.1 with the debug logs enabled in order to see the cause in the event viewer:

ERROR: A manifest document failed validation against the schema(s).
DOM Error: -1072898030
Reason: Content for element ‘{http://schemas.microsoft.com/appv/2014/manifest}ProgId’ is incomplete according to the DTD/Schema.
Expecting: {http://schemas.microsoft.com/appv/2014/manifest}Name.

To troubleshoot this we have to delve into the AppxManifest.xml file buried within the .appv package (you can extract it by treating it as a zip file). The error message says we are looking for a ProgId entry with no name, and it didn’t take long to find one. Spot the difference between this file type association for .hqx and .img:

.hqx has a ProgId named WinZip associated with it; .img has a ProgId entry that has no name, and the same applies to the .iso extension. You could fix this in 3 ways:

1. Export the manifest within the sequencer and edit those extensions to match the structure of the other file extensions. Not recommended unless you really like XML.
2. Fix the original MSI package (assuming you grabbed the MSI version from WinZip’s alternative download page) by filling in the word WinZip in the empty ProgId columns in the Extension table:

   
   NB: wzcloud has no ProgId in this table either, but the sequencer creates one for it, so I presume the only difference is because .iso and .img entries pre-exist in Windows and point to the ProgId Windows.IsoFile.

3. Add these registry entries after installing WinZip and whilst still monitoring:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.img]
   @=”WinZip”

   [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.iso]
   @=”WinZip”

Microsoft have released patches for the App-V client built into Windows 10 build 1703 and 1709, as well as one for App-V 5.1 (Hotfix 11):

• App-V 5.1: https://support.microsoft.com/en-gb/help/4074878/march-2018-servicing-release-for-microsoft-desktop-optimization-pack
• Windows 10 1703: https://support.microsoft.com/en-gb/help/4077528/windows-10-update-kb4077528
• Windows 10 1709: https://support.microsoft.com/en-gb/help/4074588/windows-10-update-kb4074588

The major headline for the Windows 10 patches is reverting the registry system from the new container-based system (CREG) back to the old virtual registry system (VREG). This should resolve a range of reported issues that crept in with 1703.

All 3 patches also contain a fix to prevent registry corruption under HKCU when using connection groups, so it’s recommended to update as soon as possible!

The latest patches for App-V contain this in the list of fixed issues:

• Addresses an issue in which the user’s hive data in the registry isn’t maintained correctly when some App-V packages belong to the connection group.

Having recently hit this issue myself but not found it described anywhere online, I thought I’d detail the symptoms of this issue so that you can know what to look for if you happen to be stuck using a system without the latest patches!

Prior to these fixes, if using the VREG registry system, i.e. App-V 5.1 or Windows 10 1703/1709 prior to the aformentioned patches but with VREG enabled via a registry setting:

If you tried to write a registry value under HKCU containing the string C:\ anywhere within, it would result in a corrupt unreadable value and also prevent the system from reading any further keys added after that point:

Regedit would also show the values as missing:

The value C:\ could be anywhere within the string; other driver letters seem to be ok, and both the colon and backslash are required to trigger it. Plenty of apps like to store data under HKCU listing configuration items such as folder locations, it appears that these apps could have been potentially broken when using connection groups prior to these patches!