Creating Custom File Associations to Support Side-by-Side Applications

I'll explain how to adjust custom file associations for multiple users on the same Terminal Server if your admins need to install two different apps to open the same file.

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.

  1. 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.”
  2. 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.

Step-by-Step Configuration

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.

  1. Create a group called “Acrobat Users” and add the five user objects to that group.
  2. Install Adobe Acrobat onto the Terminal Server.
  3. Configure NTFS permissions on Acrobat.exe so that only members of the “Acrobat Users” group are able to execute it.
  4. 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.)
  5. 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.
  6. 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”
  7. 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:

Value: (Default)
Type: REG_SZ
Data: AcroExch.Document

(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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by an anonymous visitor on April 20, 2004
I've been looking for a way to do this so I can install English and Italian and French versions of Acrobat and MS Office on the same server. My idea was to create a group for each language.
Anyone got experience of using the Multi-language version of Windows and Office?
This message was originally posted by Kimmo Jernstrom on April 20, 2004
I'd like to convert this article to a PDF document and make it a downloadable item at my site (, would that be OK for you?
This message was originally posted by Freddie on April 21, 2004
My solution is to make two different user profiles whit the files associated whit the two apps. in question, works very good.

About the MUI question.
The only thing to rely think about is to have an English OS on the server or Wks and apply the MUI.

See ya…
This message was originally posted by an anonymous visitor on April 22, 2004
how can i contact you?
please can you post some info on your solution
This message was originally posted by DDILL on April 26, 2004
This is good stuff. I will use this with the addition of creating an ADM template that makes the registry change. This way I can assign this as a group policy to a group for Adobe Full.
This message was originally posted by Bob Petra on June 28, 2004
Hello DDILL,

Is it alright for you to send me a sample of you "homemade" adm file?


Bob Petra
This message was originally posted by Another IT Geek on September 22, 2004
Quickly resolved an issue where all but one user on a terminal server used openoffice, and the other used excel. Have exported the reg files for easy re-use if required.
This message was originally posted by Max Penfold on September 27, 2004
Told me exactly what I need to know
This message was originally posted by an anonymous visitor on November 10, 2004
I have two terminal servers, one with the adobe reader and one with the reader and the writer and on both server, the pdf file type is associated with AcroExch.Document.
When I try to switch between using the reader and the writer, nothing is written in HKCU\software\classes but rather it is written in HKCU\software\microsoft\windows\currentversion\explorer\fileexts\.pdf

and nowhere could I find a file type called "pdf_auto_file"

where did you come up with all this stuff?
I can't believe that so many people are wanting to dot he same thing as me just now! I'd be really grateful to anyone who has an ADM that will do this if they could email a copy to rkew<REPLACE THIS WITH AN @>

Many thanks,
Any way you could send me the custom .adm you created ?
sounds like a great solution!
This is my first reply to a post so I am sorry if it's not in exactly the right place.

If this class does not exist, you can save the original class from Adobe Reader if you install that first. It will create an AcroExch.Document class but associated with the Reader, not Acrobat. Rename the registry key to AcroExch.Document2 and export it as a reg file to the file system. Then rename the registry key it back to AcroExch.Document and install Adobe Writer. It will overwrite the settings in the key. However, if you then run your reg file, it will insert the AcroExch.Document2 key into the registry. You can then associate pdfs with that class. It will work and so will the user class override.

However, I have one more query. This works for pdfs opening in the file system but I'm still stuck on user specific settings to get pdfs to open in the Adobe app of my choice within an Internet browser. I wonder if anybody has been able to get around this. I suppose one workaround (which I haven't tried yet) would be to set pdfs to open in a separate window from the browser but I don't think users would go for that. Replies on this would be most welcome.
Ummmm... Not to be obtuse, because I really love this "up to your elbows under the hood" approach, but it's a lot easier and less hassle to promote J. Random User to Admin-equivalent, install any/all apps s/he needs, then demote them back. (Obviously you'd install the most common app for all, then override that for the "special" ones.) If I wanted to spend all my time hacking & cracking at the command line, I'd have installed Linux. Come to think of it, where's that RedHat CD? ;^)

Of course, knowing all this means (if you have some kind of "NewRunAs" app, or a Policy to allow HKCU changes) we can create .REG files for when Windows "forgets"...

Not your biggest tip, but a really nice one all the same. I'm still glad to have your URL soaking up an entire allocation unit on my HDD! Thanks!
PS: I forgot... When you hand-edit file associations (esp. in the GUI), you'll notice there's an entry for "Open" as well as a separate entry for "Edit". Here's my challenge: Get this working so a User can double-click a PDF & get the Reader, but if they right-click & pick "Edit", Acrobat (whatever they call the creator -- it's time they used more than just one word!!) opens the file for editing...

Just a thought. Maybe not worth the hassle here, but I'm also dealing with image files, with, say, ACDSee to browse, view, & manage them & Photoshop or some such to actually alter the pix.

Like I said, Mr. Madden, this is Good Stuff!! Thanks again!
I actually got the per user file association working for the print option. The same should work for edit. I had a scenario where I needed Full Acrobat to open when double-clicking a PDF attachment in Outlook but when they used File-Print, I wanted the Reader to handle the printing (that's the only way it would print the attachments along with the e-mail).

Using a script with group validation, I setup custom file associations that were user-based in HKEY_CURRENT_USER\Software\Classes.

It works.

If you use a SID finder for any individual on your network/Domain, you can go to the HKey Users, find their SID\software\classes and make the changes for just that individual. has a SECTOK tool that is very helpful here. Just login as the user run the sectok tool and it gives you their sid.
We are Running Presentation Server 4 on Windows Server 2003. The in house app can export an excel spread sheet. But everytime I go to save it, it will save it on the server rather than on the local machine. I have content redirection turned on. How do I make it save on the local machine rather than on the server. Is there a registry fix for this issue.

Please Help me with this issue. Thanks.
Do i have to do this steps on all Terminal Servers i have?
Do i have to do this on every Terminal Server or is it enough to do this on the first Terminal Server the user connects??
Does the ADM file exist, if so where can I get it from?
Great Article,.. will do the job well... but i have one question :)
I am trying to get some users on our TSE server to open Jpegs, Tiffs etc with a program called PhotoFiltre but when I run Ftype at CMD prompt and examine the output, i cant see a 'filetype' for this application.
is there a way of manually adding filetypes? and then associating them with the file extension?
VERY very nice.
One of M$'s "updates" switched all of my user's file associations for TIF's back to Windows Document and Fax Viewer. They hated it due to the cumbersome printing options in the app. Used ASSOC in a login script and everyone is warm and fuzzy again!

This is exactly the problem I'm having, trying to get half my office running Acrobat and the other half Reader. Like many of you out there I have about 20 different jobs at my office and don't have time to learn how to write a logon script to do this. Does anyone have one they could share???
After struggling with this for about a week and following Brians directions I finally got this to work with Acrobat 8.1 on windows 2003 Server running Presentation Server 4. The thing that finally worked for me was adding BPDXFileType for data under the .pdf key created in the HKCU hive.
Phewww, what a struggle...

Could you be a little more specific about how you managed to have it working with Acrobat Reader 8.1
I'm having the exact same problemat the moment.
The ftype for Reader and Standrard seems to be the same since Reader 8.1 : Acroexch.Document.
If you could explain how you ha it working with both version that'd be great.


Hi everyone! Followed the procedure step by step but it only works for the administrator. When tested with normal user's it doens't work. Any idea? Pleas reply also to lehnert "at" (AT sign not working)


hey, which keys you used for 8.1:
AcroExch.FDFDoc="M:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe" "%1"
AcroExch.XDPDoc="M:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe" "%1"
AcroExch.XFDFDoc="M:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe" "%1"
Did you find pdf_auto_file key?




utility for per-user file associations -

Martin Zugec