Note: Folder redirection, roaming profiles, offline files and others are part of Microsoft’s User State Virtualization. Before implementing it though, make sure that roaming profiles reside on a file server local the user’s network. You’ll avoid the issue I’m about to describe. This small piece of information is not mentioned in Microsoft’s documents. By the way, throughout all this ordeal, we’ve had BranchCache enabled and this didn’t speed up the user experience either.

Ever since we upgraded to Windows 7 Enterprise, our branch office users started complaining about extremely slow logon and logoff. In some instances, a user logon or logoff could take over ten minutes!

When we migrated our users from Windows XP Professional to Windows 7 Enterprise SP1 (x64), we enabled a few enterprise features:

Roaming profiles (Users’ roaming profile folders are located on a file server in our datacenter)

Offline Files (Users’ home folders were set as offline files/folders)

Each branch office connects to our datacenter by means of a Internet based VPN connection. We provisioned each branch office with a business class Internet cable link connection with more than adequate bandwidth.

Each branch office has a local DC used only for authentication and printing purposes.

After three months of working with Microsoft, we finally came up to what seemed to be the cause(es) of the issue – folder redirection, AppData not redirected and the use of Dfs links!

Here’s an example on how we configured folder redirection in our environment.

In our environment, we take advantage of Dfs and its features almost everywhere, so it was natural for us to use Dfs links here as well.

Folder Redirection For AppData

As part of the troubleshooting process, Microsoft recommended us to configure folder redirection for AppData.

Originally, AppData was not redirected, so AppData resided on the user’s local computer/laptop. During a logoff process, logs revealed that AppData was causing delays because it had to write files the user’s roaming profile folder (roaming profile folders reside on a file server in our datacenter).

After making the change to our test group policy, and applying it to our test machine, this step improved the logon and logoff process drastically. Logon and logoff now took less than four minutes! However, we demanded for better improvements.

However, something else broke when we made this change…Acrobat Reader XI became unusable for it could not come out of its Not Responding… state. The quick fix for this – disable Protected Mode. Stick around for more details on this later on.

Enter Dfs (Distributed File System)…

The Microsoft case owner, running out of ideas by now, contacted his senior technical lead and he advised us to use server shares as opposed to Dfs links.

Now that we had folder redirected AppData, along with the other folders, we went ahead and changed each folder’s target to use a server share instead of a Dfs link.

Note: Even when using server shares Acrobat Reader XI would still not work properly. The Not Responding… messages weren’t as frequent, but it was still bad enough that users could get annoyed by the behavior.

This was the winning change!

The Acrobat Reader XI fix

Basically, you’re going to either add the following registry entry or do it directly on Acrobat Reader.

Here’s the registry key:

If you want to do it directly on Acrobat Reader, then go to Preferences, Security (Enhanced) and then un-check Enable Protected Mode at startup.

Not the end yet…

As of 4/2/2014, I’m now getting an average of 25 seconds logon and 35 seconds logoff on my test laptop at one of our branch office!

I’m now going to check what causes our Dfs domain infrastructure to behave this way.

As of 9/30/2014, the AppData re-direction workaround broke Internet Explorer browsing – pages take a very long time to load while browsing using IE (10 and up). I opened a case with Microsoft and it looks like the slow down of IE is by design because we’re re-directing AppData and AppData, in our environment, isn’t on a local server to the users’ network. We moved AppData to our central file server located on our data center in a co-location. Again, this bit of information isn’t found on Microsoft’s documentation, so be careful before you go re-directing AppData!We’re now looking into possibly removing roaming profiles and AppData re-direction because this is affecting productivity for our users.

There are several blogs on this topic; however, some seem to be lacking one or more details or may not show how to patch and customize Adobe Acrobat Reader XI. In this blog, I will show you how to patch, customize and deploy, via SCCM, Adobe Reader XI (11.0.03).Pre-requisite: Make sure you have installed Adobe Customization Wizard XI

Next, from an administrator command line, we’re going to extract the MSI from the EXE file using the following command: AdbeRdr11003_en_US.exe -nos_o”c:\SomeDirectory” -nos_ne

Do not close this command line window as we’ll use it again.

For this example I’m extracting the contents to C:\temp\Adobe XI (11.0.03) folder.

Once we’ve extracted the source files from the EXE file, then let’s run (as an administrator) the Adobe Customization Wizard XI to create the MST file that we’re going to use to customize Adobe Reader XI.

If the customization wizard isn’t run as an administrator, you won’t be able to save the package.

Basically, we’re going to make changes in the the following sections:

Personalization Options

Installation Options

Shortcuts

WebMail Profiles

Online and Adobe online services Features

Once the customization options have been completed, proceed to click on Transform menu option then click on Generate Transform…

Save the MST file in the same folder where the Adobe Reader MSI exists.

For this example, we’re going to save this file as AcroRead.mst

Next, click on File and then click on Save Package.

Back to the command line and let’s create an Application Installation Point (AIP) in order to patch Acrobat Reader.

In the folder where the MSI file was extracted, you’ll notice that file AdbeRdrUpd11003.msp is located there – that’s our patch file that we’ll be applying.

For this example we’re going to create a new folder – C:\AdobeAIP

From the command line, in step 3, we’re going to create the AIP with the following command: msiexec /a AcroRead.msi

Once the wizard comes up, make sure to point it to the folder created in step 8.2

At this time, folder C:\AdobeAIP should contain a patched Acrobat Reader XI as well as the customization file. We’re going to use the contents of folder C:\AdobeAIP as our deployment files to create our SCCM 2012 deployment package.

Copy all contents of C:\AdobeAIP to the share that SCCM uses to deploy applications in your environment.

Let’s create a new application deployment package in SCCM. First, go to the Software Library section, and click on Application Management and then click on the Applications container to create the new package.

Right click on the Applications container then click on Create Application option.

Point to the network share where you copied the files in Step 15 and select the file AcroRead.msi

You may get a warning message about not being able to verify the publisher of this MSI file, just click on Yes.

In the General Information wizard screen, in the Installation program field, add the following:TRANSFORMS=”AcroRead.mst”

This line should read: msiexec /i “AcroRead.msi” TRANSFORMS=”AcroRead.mst” /q

Continue accepting defaults until the application wizard finishes.

Now, you can deploy this new application to a selected number of computers or users.

Supersedence Notes

In my environment, I’m replacing, or superseding, and older version of Adobe Acrobat Reader. Here’s a quick screenshot on how it’s done.