• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Automate Your App-V Client / Sequencer Test Builds With Boxstarter!

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


I recently decided to rebuild my App-V lab from scratch. I also work on various client sites and often have to whip up an App-V sequencer and test client from scratch, and in the past this has always been a manual process. So this time I decided to automate it!

There’s a lot of buzz around automation frameworks at the moment – you may have heard of Chocolatey, Boxstarter, Chef, Vagrant, PuppetDSC, etc. I started writing my own script in PowerShell before realising that one of the features I wanted to implement – applying Windows Updates and rebooting with autologon until the process had completed – was already implemented in Boxstarter. Boxstarter is written in Powershell so a lot of my existing code could be ported over too, with some of it replaced with Boxstarter’s own built-in functions.

This script will be constantly evolving but here is what it does at the moment:

  • Prompt the user to ask if the machine is a client or sequencer if it cannot find out from looking at HKLM\SOFTWARE\Microsoft\AppV
  • Installs pre-reqs for App-V via Chocolatey:
    • .Net 3.5 & 4.5.2
    • Powershell 4.0
  • Enables Microsoft Update
  • Applies all Windows Updates except those that need the user to accept a license (e.g. language packs, Skype, Silverlight)
  • Disable automatic updates
  • Sets execution policy to Unrestricted
  • Disables Security Centre and hides task tray icon
  • Disable System Restore and deletes any existing restore points
  • Optimises the OS for running on an SSD
  • Disables computer password change (to prevent falling off the domain when reverting)
  • Configures power options to disable screen off and standby timers
  • Enables remote desktop
  • Sets Explorer options to show file extensions and hidden files
  • Sets Windows 8 to boot to desktop, show all apps view by default, etc
  • Pins Command Prompt, Powershell, Regedit, Notepad, and Snipping Tool to the taskbar
  • Disables Internet Explorer Enhanced Security Configuration (for server OS)
  • Disables IE first run prompts and sets home page to blank
  • For a Client build:
    • Install App-V Manage, ACE, InstEd, 7-Zip and Sysinternals Suite via Chocolately
    • Pin App-V Manage and ACE to the task bar
  • For a Sequencer build:
    • Disable UAC
    • Disable Windows Defender
    • Disable Windows Search
    • Disable over a dozen scheduled tasks
    • Create empty ODBC Data Sources registry keys
  • Run ngen.exe to optimise .NET assemblies
  • Perform disk cleanup via cleanmgr.exe
  • Wipe %TEMP% and C:\Windows\Temp
  • Run sdelete.exe to zero unused bytes on disk (allows the VHD to be compacted more efficiently when complete)

Note that is does not actually install any App-V components, since these are not available via any public download locations and I am not authorised to distribute them. But who knows, with Microsoft’s adoption of OneGet in Powershell v5, we may be able to install those components that way in the future! Anyhow, it’s a good idea to take a snapshot of the clean base configuration before any App-V components are installed, plus not all environments will be running the latest version.

There are a few known issues at present:

  • Sometimes checking for Windows Updates can return an error on the first attempt – hence running the command twice in a try / catch block as a workaround.
  • Disabling Defender on Windows 8 is difficult as the service is locked down, so for now it drives the GUI… which does highlight a flaw in Windows that you can disable the built in antivirus without admin rights! The timings of this may need fine tuning as I have seen it stall once or twice. Perhaps I will just figure out how to do it properly instead.
  • UAC still seems to be left enabled when configuring a sequencer build on Windows 7, yet it works on Windows 8.

The great thing about this is that it can be run from a simple URL – which I have plugged into an easily memorable URL shortener. So to run this script on a machine, all you have to do is hit Win + R to get the run box and enter:


Easy, eh?

Of course you may want to customise this for your own needs – just download the script as a text file and head over to Boxstarter.org to learn how to run your own version from your own URL. You can even run it from a network share or USB key if internet access is an issue on the test VMs.

Please comment below if you find any issues or have any other suggestions. I hope you find this useful and it saves you some time, or if not perhaps it will expose you to some cool tools that you might not have heard of before. I used Chocolatey for example to reinstall a bunch of tools on one of my machines after reinstalling the OS!


Broken Database Connectivity in App-V Apps

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


In my previous post I described an issue with an in-house developed app that was unable to connect to it’s database when running inside App-V. A few weeks later, different client, different app (Trojan CASPAR), and I encounter the issue again:


SQL Database Logon Error

Form: FrmUserLogin

Procedure: Open database

Error Code: -2147467259

Description: [DBNETLIB][ConnectionOpen (Initialize()()).]General network error. Check your network documentation.

I fixed it previously by disabling the entire virtual registry at the package level; but this was not an  option this time as there were vital registry entries in this package. And unfortunately I didn’t have any ‘network documentation’ to check.

So, I busted out Procmon, but could not find anything that jumped out at me. Then I decided to give SpyStudio a whirl (which by the way is now available free of charge for the full version). The great thing about this app is that it lets you do two captures and compare them; so I did one with the app running natively, and one with the app running inside the bubble. Straight away I could see a big block of different behaviour in green so I checked there first. The broken app was making numerous call to HKLM\System\CurrentControlSet\Services\WinSock2\Parameters:



The package did not contain any registry entries under this location, so I decided to add a pass through path so that the App-V client directs all reads and writes to this key directly to the real registry, bypassing the virtual registry entirely. Under HKLM\Software\Microsoft\AppV\Subsystem\VirtualRegistry is a multi-sz value PassThroughPaths that lists various keys that bypass the virtual registry. I added this WinSock2 key here, closed and restarted the app, and it could then connect without a hitch!

So, next step is to automate applying this key via an App-V script. I stuck with vbscript for this since it’s simple to use, and I already had a script in my toolbox to do the job! Save this as AddWinSock.vbs under the Scripts folder of the App-V package:

Then I added this to DeploymentConfig.xml under an AddPackage trigger:

I did not add a RemovePackage equivalent to undo the change just in case there ended up being multiple apps requiring this fix then removing one could break the others. But if you want to implement it, the function to do so it right there in the vbscript.

Changing this key affects all packages on the client however. So, unless you can find a package that contains and requires entries under the WinSock2 key, which I have not yet come across, then this should be safe to apply – but of course use this at your own risk!


Today’s Fixed App-V Apps!

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

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!

Beware When Sequencing Access Runtime!

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

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”>
<PATHEnvironmentVariablePrefix>[{ProgramFilesX86}]\Microsoft Office\Office12\</PATHEnvironmentVariablePrefix>
<ApplicationId>[{ProgramFilesX86}]\Microsoft Office\Office12\MSACCESS.EXE</ApplicationId>
<Extension Category=”AppV.AppPath”>

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.