• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Obligatory “I am now an App-V MVP” Blog Post!

Written by Dan Gough. Posted in Miscellaneous

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!)


The latest Internet Explorer preview is virtualised with App-V!

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

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!


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.