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
Hi Ryan,
Did you ever release any examples ?
Kindly
Michael
Windows Admin – Citrix
Wolseley Nordic
Hi Michael,
Sorry I did not. Blame it on me being lazy 🙂 I am uploading my video now and expect the article to be up by tomorrow.
The examples are up!
http://ryanwill.com/create-and-use-shims-with-microsoft-application-compatibility-toolkit/
Hey Ryan, are we supposed to be able to use CorrectFilePaths in the x64 version? I really need it, but I can’t find it, and while I can find someone else asking on the technet forums, they were never answered.
Kate,
Microsoft has excluded CorrectFilePaths for x64 applications. When I first ran into this it was frustrating because I needed it for a 64-bit application. What I ended up doing was using a symbolic link instead of a shim. From what I gathered, Microsoft didn’t include it with the x64 version because they didn’t think it was needed.
If you aren’t familiar with symbolic links, take a look at my slide deck from BriForum 2014. This should be able to accomplish what you need unless you need to filter based off an executable.
Thanks for asking!
Thanks! I’ll try that.
I tried, but it didn’t work for my (weird) work case. I have an App-V app that has hard coded paths on the Q:\ drive (can’t VFS or it breaks), but one of those folders needs to be out of the bubble because the program opens files with it in one of MANY programs which are all either running or likely to be running before this VAPP. Somehow, App-V manages to virtualize it no matter how I create a junction (/d, /j, excluding, not excluding, creating the folders before monitoring, creating them during monitoring, having the folder exist on the client, not having the folder exist on the client, and every combo). I may have to wait for us to get App-V 5 to fix it!
I give an example of how to use the symbolic links with App-V in this video from BriForum 2014 – Link
The example I went over was for AppV 5, but would have the same steps for 4.6.
Thanks again! It looks like what I’m doing is a bit too different to work, but at least now I know it!