There are many situations where you need to be able to install two different applications onto a single Terminal Server for different groups of people that both use the same type of file. (Confused?) You’ll understand exactly what I mean with this example: The free Adobe Acrobat Reader and the full version of Adobe Acrobat.
Most likely you have some users who need to use the expensive full version of Adobe Acrobat while other users simply need to be able to view PDF documents with the free Acrobat reader. Ideally you’d like to mix these users on the same Terminal Server.
The challenge is not about securing access to the Acrobat application. Rather, the challenge is that when users double-click a PDF file, you want a few of them to open it with the full version of Acrobat and you want the rest of them to open it with the free Acrobat reader. (Another popular example of this is with the full version of Microsoft Word and the free Word viewer.)
This can be done by installing both applications on the same server and applying some scripting to adjust file type extensions.
In a nutshell, you’ll need to install both applications on the server and then configure the file extension associations on a per-user basis so that some users clicking a file open one application and some users open another.
File type information and associations are stored in the HKEY_CLASSES_ROOT (HKCR) hive of the registry. HKCR is built-up from two locations: HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\SOFTWARE\Classes. If a subkey or entry appears in either location, it automatically appears in HKCR. If there are any conflicts in the source keys, the HKCU takes precedence. (This is a good thing and what fundamentally allows us to do per-user file associations.)
A single file type can actually have multiple applications associated with it. This is why right-clicking and choosing “Open With…” on a .DOC file will list Microsoft Word and WordPad as options. There’s no real limit to the number of different applications that can be associated with a single file type, although each file type has a “primary” association. This primary association represents the program that’s used to open the file when the file itself is double-clicked, and it’s the option we care most about here.
Windows comes with a couple of slick command-line utilities (“ftype” and “assoc”) used to manage file extension associations. In theory these tools would be perfect for what we want to do. Unfortunately, these two tools are hardwired to change file association information stored in HKLM, not HKCU. Therefore, using these tools in a Terminal Server environment would change the file associations for all users on the server instead of the specific user where the tool was used. Because of this we’ll need to look to other ways of adjusting file associations.
Fortunately, we can customize file associations on a per-user basis simply by adding a new registry key / value pair. However, knowing exactly what to add for a specific application can be tricky, so we’re going to need to dig in again to learn more about how file type associations really work.
In 32-bit Windows environments, file type association is a two-step process.
- First, you need to configure a file type. For example, this would simply define “Microsoft Word Document” as a file type that’s opened with “c:\program files\microsoft office\program\winword.exe.”
- Second, you need to associate a particular file extension with a file type. In our example, that would be saying that files with the .DOC extension are of type “Microsoft Word Document.”
Fortunately the application setup procedures take care of registering the file types with Windows. They also associate the relevant file extensions with their file types. Therefore, in order to change a file association for a user, all we need to do is point the file extension to a different file type.
So why did we spend all this time talking about file types? In our simple example, we called the file type “Microsoft Word Document.” In the real world, the file type name is a bit more cryptic. (For example, the internal file type for a Microsoft Word Document is “Word.Document.8,” and the file type for a WordPad document is “WordPad.Document.1.”)
Therefore, before you can configure any file associations manually (or via a script), you need to figure out the internal file type names of your applications.
For me, the easiest way to do this is with a built-in command called “ftype.” I think it’s quickest and easiest to run “ftype |more” from a command prompt. Then, page through your results until you find the specific file type that you’re looking for and make a note of the name. (The name is always the full text that's on the left side of the “=” character on each line.) There is really no rhyme or reason to internal file type names. Take a look at some randomly selected ones:
As you can see, you won’t be able to guess these names on your own. If you’re having a hard time figuring out which file type is relevant to you, you can always look at the execution script names and paths for each file type from the output of the “ftype” command.
Once you know the internal file type name of the file type whose association you want to change, you can configure it in a user’s HKCU hive.
If you browse to HCKU\SOFTWARE\Classes, you’ll see that by default there isn’t too much there. That’s because this information is usually stored in the HKLM hive. Storing file association on a per-user basis in the HKCU hive is kind of a “manual override,” so we’ll have to manually create the keys and values we need.
To create a per-user file association, simply create a new key (the little folder icon) under the HCKU\SOFTWARE\Classes key. You’ll need to name that key with the file extension you want to associate. For our example, we would name the new key “.doc”. (Note that you must include the “dot” in the name, so it would type DOC.) Once you’ve created the new key, it will have one value. The value will be named “(Default),” and the data will be “(value not set)” Double-click the value and enter the internal file type name for the data. (For example, “WordPad.Document.1”. When you change this for a user, the change is instantaneous. You don’t need to wait for the user to log off and log on again.
Now that you know all about how file associations really work, let’s go step-by-step through how you would make this happen in a Terminal Server environment. We’ll use Adobe Acrobat and Adobe Reader for our example.
Let’s assume that you have a Terminal Server that’s been in use for a while and regularly serves about 50 users. It has Microsoft Office and the Acrobat Reader already installed. Then, someone tells you that you have to provide the full version of Adobe Acrobat to five of the fifty users.
- Create a group called “Acrobat Users” and add the five user objects to that group.
- Install Adobe Acrobat onto the Terminal Server.
- Configure NTFS permissions on Acrobat.exe so that only members of the “Acrobat Users” group are able to execute it.
- Since installing Acrobat changed the PDF file association for all your users, you need to change it back to the free Acrobat Reader. (Since you have many more users who need the free one and you don’t want to risk anything from a licensing standpoint, it’s a good idea to make the default option the free reader.)
- Execute “ftype |more” from a command line to find out the internal file type name for Acrobat Reader documents. (This will vary depending on your version of Acrobat, but it’s called “pdf_auto_file” for Acrobat Reader 6.02.) Remember, when you’re looking through the list, you need to make sure you find the one that’s associated with AcroRd32.exe, not Acrobat.exe. You’ll have to skip through several pages all the way down to the “P” section.
- Use a command called “assoc” to associate the PDF file extension with the internal file type for the free Acrobat reader. You can execute this command on the console directly, and it will modify the HKLM classes key that affects all users. In this case, the command would be “assoc .pdf=pdf_auto_file”
- Now that everyone is configured to launch PDF files with the free Acrobat Reader, you need to get the five users in the “Acrobat Users” group configured to use the full version of Acrobat. I like to do this via a logon script. If you’re using Kixtart, you can easily create a script that checks for group membership and then writes the proper registry key and value.
In this case, you’d want to add the following registry key:
Then, add the following value:
(The “AcroExch.Document” is the internal name for the full version Acrobat documents. We figured this out by using the “ftype” command.)
That’s all there is to it! Any user with this new registry key/value will launch the full version of Acrobat when they double-click a file. As you can see, once you understand how to do it, you’ll see it’s not that difficult and something that you’ll probably use in all of your Terminal Server environments.