I promised a while back to post some examples of creating and using shims. These are a little later than I wanted them to be, but here we are (finally). Since it took so long I added a bonus that I wasn’t able to include in my BriForum 2014 presentation, a video demonstration of the VIrtualRegistry shim.

My top 2 used shims:

• CorrectFilePaths – These are similar to symbolic links, but are defined per .EXE instead of system wide
• VirtualRegistry – Redirect registry calls. Can redirect HKLM to HKCU.

For a more detailed explanation on these, visit my previous post on shims.

Formatting your parameters:

CorrectFilePaths –

“original path”;”newpath”

Example:”C:\Programdata\Application X”;”Z:\ApplicationStore\Application X”

This will redirect the application call from the Programdata location to the Z drive. The Z could be a user mapped drive or any location you would prefer it go to. Keeping in mind that only the EXE(s) that you specify will only be redirected.

If you want to use environment variables such as %appdata%, I found that putting them at the begging of the parameter did not work. So I had to use “c:\users\%username%\appdata\roaming”.

Video Example:

VirtualRegisty –

ADDREDIRECT(key_to_redirect_from^key_to_redirect_to)

Example: ADDREDIRECT(HKLM\Software\Application\Database^HKCU\Software\Application\Database)

This will redirect the application whenever it calls the above HKLM key to the HKCU specified in the example.

Video example:

Download the Microsoft Application Compatibility Toolkit (ACT) here

As promised in my BriForum 2014 session, I will start a small series on Application fixes using shims and symbolic links. The first installment is on shims:

Shims can be really useful in just about any environment and I wish there were some better resources explaining how to use them. This is why I wrote this article explaining my two favorite shims.

As Microsoft releases new versions of their OS, folder structures and other key areas are bound to change. Or some applications may store personal user settings in a shared location or has a registry key that is best lived in HKCU instead of HKLM. This is where shimming or “Compatibility Fixes” come to the rescue.
A shim is installed at the system level and will essentially intercept an application call and change the default behavior of the application. The two main flavors of shims that I find extremely useful are CorrectFilePaths and VirtualRegistry. There are several hundred types of shims, but these two are the ones I find myself using a lot.

CorrectFilePaths
This shim is particularly useful when an application stores a file or folder in a directory that you want stored somewhere else. For example, say you install an application on an RDS server that stores a configuration file in ProgramData. This is not a good location if each user writes settings to it and get overwritten by other users. The CorrectFilePaths shim allows you to redirect the file call from the original path (e.g. C:\ProgramData\ABC Inc\UserConfig.ini) and replace it with a path that is user specific (e.g. %appdata%\ABC Inc\UserConfig.ini).

During shim creation you specify what process will be intercepted and redirected. This way when a user launches the process you specified and calls the file, it will be redirected to the new location. Now every user will have their own configuration file instead that doesn’t conflict with other users.

VirtualRegistry
Much like CorrectFilePaths, the VirtualRegistry shim allows you to redirect a registry call to a different location. An example where this would be useful is when an application stores a database server value in HKLM. This value may tell the application what server to establish a connection to. Now, say you have two groups of users – Group A & Group B. Group A connects to database server 1 and Group B connects to database server 2. Normally you would build a separate RDS server for each group to accommodate the multiple database values, but what if you wanted to have both user groups use the same server? How would you be able to accommodate that?

Create a new VirtualRegistry shim! You can redirect the HKLM values to HKCU and set those values with a logon script. This way Group A gets its registry key for database server 1 and Group B gets theirs for database server 2.

Shims sound great and they really are, but they can be a pain in the rear to get configured. I’ll post an article on both shims with examples in a few days.

If you want to get started Shimming, download the Application Compatibility toolkit from Microsoft here: http://go.microsoft.com/fwlink/p/?linkid=205020

About to deploy Acrobat and find there are a lot of updates to install? Good luck trying to find an updated installer higher than version XX.0. Not only is it a pain to download and run every applicable update, trying to figure out the upgrade path can be like doing super math.

To make your life a little easier when deploying Acrobat, follow these steps:

1 .Determine the upgrade path

There is an Acrobat and Reader release notes page that can help you determine the upgrade path. Click on the version numbers to determine what version is required before that update can be applied. The patching got a little easier in 10.X and 11.X with more cumulative updates, but 9.x is still a PITA. For version 9, I suggest you obtain the upgrade path from here.

2. Download the update(s)

You can download all updates from this page.

3. Modify the Acrobat setup.ini

Next, grab your xx.0 installer and extract it with an archive utility such as WinRAR.

Open setup.ini with notepad and look for the [Product] section. Start a new line here line that begins with “Patch=” and list the MSPs in order from oldest to newest separated by a semi-colon.

Here are some examples of what your Patch line would be at the time of this writing:

Acrobat 11:

Patch=”AcrobatUpd11007.msp”

Acrobat 10:

Patch=”AcrobatUpd10110.msp”

Acrobat 9:

Patch=”AcroProStdUpd910_T1T2_incr.msp;AcrobatUpd912_all_incr.msp;
AcrobatUpd913_all_incr.msp;AcrobatUpd920_all_incr.msp;AcrobatUpd930_all_incr.msp;
AcrobatUpd932_all_incr.msp;AcrobatUpd933_all_incr.msp;AcrobatUpd940_all_incr.msp;
AcrobatUpd942_all_incr.msp;AcrobatUpd945_all_incr.msp;AcrobatUpd946_all_incr.msp;
AcrobatUpd950_all_incr.msp;AcrobatUpd951_all_incr.msp;AcrobatUpd952_all_incr.msp;
AcrobatUpd953_all_incr.msp;AcrobatUpd955_all_incr.msp”

4. Copy in your patches

Place all of the MSPs into the root of the installation folder. This is the same folder that contains setup.ini.

5. Install

Run the Acrobat install and let it run all of the updates for you. The final version to be installed should be displayed in the installation menus. This can help you verify the latest version will be ready when the install is complete.

Optional

Use the Adobe customization wizard to generate a custom install. You can insert your license key, change the install directory, set default PDF viewers, disable the EULA, and many other useful settings. You can grab Adobe customization wizard 9 here,  X here, and XI here.

Hopefully these steps can keep you from going crazy when deploying Adobe Acrobat (especially version 9).