Acrobat XI and App-V 5 – 2015

I previously wrote a few blog-articles for Acrobat XI and App-V 5, however I thought I would condense the information into a single-post. So, tag along with how you get Acrobat working with App-V 5.

Adobe Customization Wizard XI

Adobe Customization Wizard is a generic tool to edit one type of Acrobat deployment. I previously used (and recommended) leveraging the Adobe Creative Cloud Packager, however there are limitations with the CCP and the ACW has been updated for every version of adobe (currently at the Document Cloud edition).

CCP offers some basic settings (disable updates) and in the end it will actually wrap the MSI into the Adobe lipstick-on-a-pig-approach of deployment.

Settings to consider for your package;

Installation Options

Caching of installation-files should be disabled. This will increase the package size with roughly about ~500mb when its enabled.



To avoid excessive overhead when starting the Virtual Environment there are two Run-registry keys that are removed from the package


In addition you should remove the ability for the end-user to trigger a repair of Acrobat from the help menu. This registry key should be added to disable the Repair-menu option.

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\Adobe Acrobat\11.0\Installer]



Cleaning up shortcuts is a good idea and completely removing the shortcuts on the Desktop is a not to unusual enterprise practice.


Online Services and Features

Just disable everything in the Online Services and Features view, however quite a few of the settings here will not be captured within the App-V 5 package. We will touch on this later on…



You can set the installer to not install the Adobe Updater services based on the information in their Enterprise Guide. Set the DISABLE_ARM_SERVICE_INSTALL to 1

Reproducible installation

In the end of this process you should have a generic MSI-package along with a specific MST-file that contains your predefined settings. In addition to the settings there are numerous patches for Acrobat. Gather up all of them and ensure that we create a simple file to install all of them in a single run. This is a sample approach containing all but the two latest patches, that I will save in a simple-to use batch file (crude, but does the job).

msiexec /i "%~dp0vc10rt_x64\vc_red.msi" /qb /norestart

msiexec /i "%~dp0acropro.msi" /qb TRANSFORMS=customer.mst
msiexec /p "%~dp0AcrobatUpd11001.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11002.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11003.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11004.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11005.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11006.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11007.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11008.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11009.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11010.msp" /qb /norestart

The not App-v 5 part of the deployment


As stated previously there are somethings that will not be part of the final package. A sample of those are the settings that will limit some Acrobat UI options. Like Updates for example. The reason for this is how Adobe handles these settings. In their wisdom they have (correctly) placed the settings in the registry under a specific key named Policies. App-V 5 will (per default, can be reconfigured) exclude these keys from the virtual registry. Regardless of what is in the package this exclusion happens at the client; this leaves the option of either remove the exclusion (or pass-through as its named) for the client and thereby all packages or to set the natively, or to set them natively. Personally, this is where we go for Group Policy as this is really a setting that should be enforced, however; any and all means for getting a registry key set on the client is fair game.

Registry keys are as follows on a x64-system;

HKLM\Software\Wow6432Node\Policies\Adobe\Adobe Acrobat\11.0\FeatureLockDown



App-V 5 can’t handle drivers and in terms of the Acrobat package there is a specific need to install a printer (aka Distiller) to enable loads of the functionality provided by Acrobat. The printer can not (easily at least) be extracted from the Acrobat installation package, however it is available in the XI-version from other installation packages such as FrameMaker or RoboHelp. There is a minor tweak necessary that was detailed in the previous blog post. Repeating again; This printer needs to be deployed seperately and outside of the App-V 5 sequence. Any means that you have at your disposal will of course to install the driver. One route is to use Dependencies within ConfigMgr, a different route is to install it as a script during the deployment of the App-V 5 package.

App-v 5 sequencer setup


Acrobat will integrate to quite a few different applications and therefore it is vital that these are installed on your sequencer before you start sequencing to avoid issues in the long run. If you want Acrobat to integrate with an application the recommendation is to install it as a prerequisite on the sequencer. Here is the sample used:

Windows 7 x64
.NET Framework 4.0
App-V 5.0 SP2 sequencer
Microsoft Office 2007 SP2
Adobe Illustrator CC 2014
Adobe Photoshop CC 2014


There are exclusions that are required for the application to work, and others will just make your life easier. Here is the list as written previously


REGISTRY\USER\[{AppVCurrentUserSID}]\Software \Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem

REGISTRY\USER\[{AppVCurrentUserSID}]\Software \Microsoft\Windows NT


Decision time

To PVAD or not to PVAD, that is the question. PVAD stands for Primary Virtual Application Directory. If you have been tagging along since the Softgrid days this is the new way to have the Q-drive discussion. Multiple rants have been given about its usage and I have aggressively proclaimed that you should avoid it. However, if you want to use it you should know why you want to use it. And here comes the why in this instance. (as you notice there is an avoidance of explaining what it actually does. Noone is certain, it does give the user full-write access to that directory. Unless you enable VFS-write. Therefore its existance is something you will discover while sequencing with older versions of the sequencer – not in App-V 5.0 SP3 which is the latest – as the option is removed by default in the latest version.

Adobe has an appaling installation method and Acrobat is actually the better part of this, however their licensing engine is far worse. In part of getting their licensing engine operating without issues the user (regardless of their permisson level on the system in question) must posses write-abilities to quite a few directories. App-V 5 RTM and quite a bit along the way was a bit step backwards in terms of functionality when it comes to permissions, and not until the App-V 5.0 SP3 release was there a suistainable way forward. So,

Pre App-V 5.0 SP3

C:\Program Files (x86)\Common Files\Adobe\Adobe PCD

In addition, the directory has to natively exist and the end-user must have full permissions to it.

Post App-V 5.0 SP3
Enable full Virtual Filesystem Write.

The first scenario is extensively tested. The second scenario is a logical continuation, however not extensively tested.


Run your bat-file

Start Acrobat once, and then close it. Stop sequencing. Enable all COM and named objects interaction. Save your sequence.


To enable full-functionality you are required to publish the package globally. A global publication will enable full usage of the Internet Explorer plugin. In addition you are required to enable the integration between any applications that have Acrobat plugins – such as Office applications.

Sample way for Outlook;

reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /ve /d XXX_YY /f

Easiest way? Do this when the publishing action occurs. Create the below sample code for the Deployment Configuration-file. Of course, to create beautiful XML like the part below use the Virtual Engine ACE.

 <ProductSourceURLOptOut Enabled="true" />
 <Registry />
 <Arguments>/c reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\winword.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\excel.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\powerpnt.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /ve /d XX_YY /f</Arguments>
 <Wait RollbackOnError="false" />
 <Arguments>/c reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\winword.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\excel.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\powerpnt.exe /f</Arguments>
 <Wait RollbackOnError="false" />


Known issues

Using the Review Tracker fails to start. Within the installer this is known as the Synchronizer. Not entirely sure why this happens and haven’t spent (any) a lot of time troubleshooting it.

(this can be found under View –> Tracker)

Adobe PDF Addon download

Previously I discussed the deployment of Adobe PDF Addon with a virtualized instance of Adobe Acrobat. The Adobe PDF Addon is also known as the Adobe PDF Printer or the Adobe Distiller. In the end – its a piece of software that contains a driver and therefore can not be virtualized.

Extracting this from a generic piece of Adobe Acrobat media is rather painful, if at all possible, however the Adobe Distiller (aka Adobe PDF Addon) is available as a standalone installer.

How would one retrieve this standalone installer?

Well, by an odd-chance I bypassed the Creative Cloud Packager and downloaded the Adobe FrameMaker 12 from the Adobe Licensing Website. Hidden within these source-files there is a folder named;



There are a few things needed to silently install this msi (distillr.msi).

Visual C++ 2010 SP1 (x64) is a prerequisite for the application.

There is a check by the installer to ensure that it is not installed standalone. Within the InstallExecuteSequence table the following CustomAction-reference needs to be removed;


With the above in place – you are all set togo!

Adobe Acrobat XI and AppV 5

Adobe Acrobat (along with any other Adobe software) has always been something people want to virtualize due to different reasons. In larger organizations the primary driver for this has been the poor handling of locking of files by applications that Acrobat integrates with. In essence, the installation fails if common applications are running – such as Outlook or Word.

With their latest suite of deployment tools there is actually a document of “process conflicts” which is list to long for anyone to care about.

The solution to workaround the limitation has never been nice, and App-V has in some cases allowed for a less disrupting delivery. As App-V 5 brings in a new set of features that resolves quite a few of the limitations (such as browser helper objects) that previously existed, perhaps we can leverage this to deploy Acrobat without the impacting the user experience?

Within the Microsoft Sequencing Guide for App-V 5 there is still a limitation of the drivers not beeing possible to make a part of the virtual package. We understand why, and assume that bringing support for this would require some changes or new inventive ways of “doing funky stuff” under the hood.

Just to clarify; The below suggestion is not supported by anyone. Acrobat virtualized is not, and has not been communicated that it will be at any time, supported by Adobe. Microsoft clearly states that drivers are not supported, and the below method is not advised by them to resolve issues relating to drivers.

What can we do in the mean time?

Well, here is a recipe and some great stuff for you to bring back to Adobe.



You will need App-V 5.0 SP2 sequencer setup on your packaging machine. The target environment this specific scenario has been tested for is Windows 7 x64, so that will be the packaging machine aswell. Office version this is tested with is Office 2007 and 2010 – both running as 32-bit applications.

The source media has been a Creative Cloud generated build, with default settings. The Build only contains Adobe Acrobat, and no other components.

I don’t see a reason that it will not work for traditionally created deployments using Adobe Customization Wizard, but I haven’t tested that.


There are four exclusions required to be created;

REGISTRY\USER\[{AppVCurrentUserSID}]\Software\Microsoft\Windows NT

Required to avoid issues when printing documents from Acrobat

REGISTRY\USER\[{AppVCurrentUserSID}]\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem


Required to avoid issues when sending emails via Acrobat


Required to avoid issues due to licensing


Primary Virtual Application Directory is set to the default installation path of Acrobat;

C:\Program files (x86\Adobe\Acrobat 11.0



From a command-prompt, run all the commands to finish the installation. It should look something like this;

exceptions\ExceptionDeployer.exe –workflow=install –mode=pre


exceptions\ExceptionDeployer.exe –workflow=install –mode=post


Goto the following registry key;

HKLM\Software\Adobe\Acrobat Distiller\11.0\PrinterName

Alter the name to a printer to every client has, perhaps this one;
”Microsoft XPS Document Writer”


Start Adobe Acrobat once, but perform no additional configuration


Directly skip to the Edit-mode of the sequencer (unless you need to set a Feature Block 1). Verify that the exclusions were effective and that nothing in the above locations have been captured.

Also goto the Advanced-tab and check the boxes. Required to avoid issues when sending emails via Acrobat


Save your package.

Now you have a virtual application, however the printer-driver is still not there. Perhaps you reviewed the italic suggestion under the installation-part? Well… this is where it gets fun. Most likely  you can get the application working with the suggestion, however – the Adobe Distiller (aka Adobe PDF Printer) is actually available as a separate installer. Unfortunately – getting your hands on it is just pure luck in some cases.

This is the splash-screen of the version the customer had;


It’s a perfectly crafted MSI, that can easily be deployed to any system. By pure luck, a different piece of software had licensed this and brought it out as a separate installer. It seems that the user-base was overlaping each other and therefore this was already on the clients.

So, App-V people – perhaps you can bug Adobe about make this deployment method available for enterprise customers so Acrobat can be virtualized, without impacting functionality?

I reached out to Adobe and got the generic response back with a link to their support statement. I assume you will. But they will never change this unless customers demand it.