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.

Prerequisites

Media

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.

Exclusions

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

REGISTRY\USER\[{AppVCurrentUserSID}]\Software\Microsoft\Office\15.0

Required to avoid issues when sending emails via Acrobat

C:\Programdata\Adobe\SLStore

Required to avoid issues due to licensing

PVAD

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

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

Sequencing

Installation

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

build\setup.exe

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

Suggestion;

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”

Configuration

Start Adobe Acrobat once, but perform no additional configuration

Post-editing

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.