• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

App-V 5 Does Not Like Shortcut Names That End With A Space!

Written by Dan Gough. Posted in App-V v5.x

I just sequenced an app that deployed a shortcut with a space at the end of the name, which went unnoticed. I imported the  resulting package using PowerShell to quickly test and all worked 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 not changes to them!

The event log read:

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!

Supressing UAC Prompts In App-V 5 With __COMPAT_LAYER

Written by Dan Gough. Posted in App-V v5.x

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:

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.


How To (sometimes) Fix A Crashing Sequencer! ImgBurn Recipe

Written by Dan Gough. Posted in App-V v5.x

I’ve come across a couple of apps that just do not want to be sequenced, crashing the sequencer in various ways, or even producing a package with an invalid manifest that cannot be imported. The first one was ImgBurn, a freeware disc image burning tool, and the second was IBM iSeries Access for Windows. I will use ImgBurn to demonstrate the issue, the debugging, and the solution.

The Problem

So, download and sequence ImgBurn, then attempt to go through to the process where you launch the applications for streaming optimisation, and you will see ‘Exception of type Microsoft.ApplicationVirtualization.Packaging.EncoderTools.EncoderToolsException was thrown’:

ImgBurn - Streaming Error

Hmm, not good. If you press OK and try to launch again the sequencer will hang forever. So, revert and try again but skip the streaming phase to go straight to the final package editing phase and you instead get ‘Microsoft Application Virtualization Sequencer has stopped working’:

ImgBurn - Editing Sequence

Not much better. So, revert again and this time just hit the option to save the package immediately – this time you will save a package but with an ‘Invalid manifest detected’ error:

ImgBurn - Invalid Manifest Detected


Now you at least have a package to play with – but it fails to import into the client. The error message is not of much use, it pretty much just tells us that the manifest is invalid like the sequencer already did:

ImgBurn - PoSh Import Error

The Event Log doesn’t show anything on the Sequencer or the Client. The hidden debug logs show nothing on the sequencer either, but there is one in particular you want to activate on the client – ManifestLibrary:

Event Viewer - Show Debug Log


Event Viewer - Enable ManifestLibrary Debug Log

After this, import the app again and you will see this in the event log:

ImgBurn - ManifestLibrary Error

According to this, there is a ProgId entry with a missing name. Rename the .appv file to .zip and examine the AppxManifest.xml file buried within. This is how a file association should look – notice that the file extension is associated with a ProgId, then the ProgId definition follows along with the shell commands. This is the same way the file extensions, ProgIds and commands are usually linked in the registry:

ImgBurn - Manifest ccd FTA

However, the definitions for .img and .iso appear different – there is no name listed for the ProgId:

ImgBurn - Manifest img FTA

Looking at regedit back on the sequencer with the app still installed, the .iso and .img extensions are pointing to the ProgId Windows.IsoFile. Also, rather than listing the commands under the ProgIds, ImgBurn takes the non-standard approach of listing the commands directly under the extensions:

ImgBurn - Registry iso


ImgBurn - Registry WindowsIsoFile


I am assuming that the sequencer has difficulties when commands are registered directly under the extension key, and that extension key links to an already existing ProgID. So lets fix that by linking the .img and .iso extensions to the already existing but seemingly unused ImgBurn.AssocFile.img and ImgBurn.AssocFile.iso ProgIds:

ImgBurn - Registry ImgBurnAssocFileIso

After making this link, the shell command exists twice (and gets picked up twice in the sequencer) so the duplicate commands listed directly under the extension keys should be deleted.


To remedy this, run the following reg file after installing whilst still monitoring:

Windows Registry Editor Version 5.00




Then proceed as normal; the file type associations will be picked up as they should and the application can be launched successfully during the streaming phase, saved and deployed.

Fixing Other Apps

The solution for IBM iSeries was slightly different; the installer nests two ProgIds, BCH and WS, under a common PCOMW key. The file associations for .bch and .ws then refer to the ProgId in the format PCOMW\BCH and PCOMW\WS. The AppxManifest.xml schema does not allow backslashes in ProgId names, so this was causing the error, found by exactly the same troubleshooting steps listed for ImgBurn. The fix in this case was to move these ProgIds into their own keys PCOMW.BCH and PCOMW.WS and update the file extension keys to suit, essentially replacing the backslash with a dot.

I ran into other issues preventing my from sequencing iSeries however, but this method of troubleshooting was still useful and can hopefully apply to other apps out there – let me know via the comments below if you’ve found any others!


Issue With App-V 5 and Java Mission Control

Written by Dan Gough. Posted in App-V v5.x

I recently encountered a strange error when trying to sequence the Java JDK. It has a shortcut named Mission Control, which produced the following error message when trying to launch on the client:

JDK Mission Control Error
Invalid Configuration Location – The configuration area at ‘C:\Users\testadmin\.eclipse\810663534\configuration’ is not writable. Please choose a writeable location using the ‘-configuration’ command line option.

This folder is present in the VFS and should be writeable. I tried various tricks such as enabling full VFS write permissions and setting the PVAD to this location, but to no avail. I first thought it might be something to do with the folder name starting with a dot – Windows doesn’t really like this, for instance it won’t let you create such a folder through Explorer. Busting out Procmon however showed that the application is trying to create and delete a .dll file in this folder to see if it’s writable; and this file extension is read-only in the VFS (see here for more info on which file types are blocked). Here is the Procmon trace:

JDK Mission Control - without local folder

Since this folder is in the VFS, I would not expect to see the first few PATH NOT FOUND entries, so perhaps there is something else going on here that’s forcing it to look at the real file system instead of the VFS. The app works however if I create the folder on the local file system:

JDK Mission Control - with local folder

So, the simplest solution to this is to not launch the Java Mission Control shortcut during sequencing! This way the folder never gets created or captured, and it will create the folder on the local file system automatically.

This issue is not just limited to the Java JDK. I have seen a forum post where the same issue affects Eclipse, and I also happened to run into the exact same issue on two other applications in the same week. The error message is identical, and they all appear to have some code based on a modified version of Eclipse.