WARNING: XP’s File Association Web Service May Be Dangerous to Your Organization’s Health

Having been involved with supporting PC users for the past decade and a half, I've certainly run across my share of users who, by their own admission, know "just enough to be dangerous." I appreciate their honesty, but I'm often dismayed that they didn't know "just enough to stay out of trouble." Some new features in Windows XP that are supposed to make users more self-sufficient are resulting in the illusion that end users don't really need to know what they're doing. The unfortunate side effect of this illusion is that the requirements for getting into the "know enough to be dangerous" group just dropped and it's easier for users to get themselves into trouble. I recently experienced a real-life example of how making a task too easy can do more harm than good.

The Problem
XP Service Pack 1 (SP1) introduced the file association Web service. This Web service is triggered when users try to open a file by double-clicking it in Windows Explorer, but there isn't enough information about which application to use to open that file. As Figure 1 shows, XP lets users choose to use the Web service to find an appropriate program or select the program from a list. The default option is to use the file association Web service. In my opinion, this default is the fatal flaw because the chances are slim to none that typical users can find, obtain, and install the application they need. There are three scenarios that could play out when a user attempts to use the file association Web service:

In a perfect world, the Microsoft Windows File Associations Web page opens in the user's browser and displays information about the application needed to open the file. The user knows how to obtain and install the required software, and no IT involvement is required.

In a very nice world, the user gets accurate information about a supporting application from the File Associations page and contacts someone in IT who knows how to get and install the software.

In the real world, the desired file might have an obscure file extension that the File Associations page can't associate with a program. The user will probably click the CKNOW.COM link to the FILExt Web site and receive a list of several possible applications that might or might not open the file. To compound the problem, custom or internally developed applications that generate data files with special extensions certainly won't be listed in the FILExt site. You can only hope that the user will realize the chance of coming out of this unscathed is pretty slim and will ask IT for assistance.

My point is that if the majority of file association Web service visits are going to end up generating a service call, your users should be spared the frustration that results from unsuccessfully using the file association Web service. Fortunately, you have some options for blocking access to this Web service. You can also do your users a favor by configuring the file associations commonly used within your environment.

Blocking the File Association Web Service
Microsoft acknowledges that some organizations will want to control access to the file association Web service. It proposes three approaches for controlling access to the File Associations page: automatic software installation based on Group Policy settings, blocking access to the File Associations page at the Internet firewall, and perhaps the best option, disabling the feature through a registry setting.

You can configure Group Policy settings so that when a user tries to open a file whose application isn't on his or her machine, a copy of that application is automatically installed and the file association Web service isn't triggered. If you already deploy software using Group Policy, this approach might be a reasonable solution. However, if you don't currently use Group Policy to assign or publish applications, controlling the file association Web service isn't a good reason to start doing so. A decent overview showing how to use Group Policy for this purpose in a Windows Server 2003 environment can be found in the Microsoft article "HOW TO: Use Group Policy to Remotely Install Software in Windows Server 2003" (http://support.microsoft.com/?kbid=816102). Most of the information contained therein is also pertinent to XP and Windows 2000 clients in Win2K Server domains.

Blocking access to the File Associations page is an effective way to prevent users from using the file association Web service. However, depending on the information your firewall provides to the end user, this approach might ultimately generate the same amount of user frustration and resulting service calls as leaving access to the site open. If you choose this route, Microsoft recommends that you block access to any Web site that contains the string http://shell.windows.com/fileassoc/.

The third method for controlling access to the file association Web service is to disable the feature by adding one registry entry. I like this option best because it's simple, works well, and is easy to deploy. Plus, the majority of users won't realize that anything is missing.

Here are the steps you can take to manually add the registry entry that will disable the file association Web service:

This setting takes effect immediately, so no user interaction (e.g., log off, reboot) is required. The effect of adding this registry entry is that the traditional Open With dialog box is displayed. Users can then select an associated application from the list of applications that are installed on their system. Your users might still have some difficulty selecting the correct application to open their data file, but at least they didn't need to embark on a futile adventure to realize that fact.

If you decide to take this approach for your users, you can easily deploy the setting to your user base by using custom Administrative Templates with Group Policy. For more information about how to use Administrative Templates and Group Policy to deploy a registry setting, check out the article "Extending Group Policy," August 2004, InstantDoc ID 43203.

Configuring File Associations for Users
For the OS shell to know which application to launch when you double-click a data file, two items must be defined: the file-extension key and the associated program class. Files are classified based on their extension (e.g., .doc, .xls), so files with the same extension are considered to be the same type or class. You can instruct the shell to open files of a given class with a specific application—this is known as association.

File-extension keys and program classes are stored in the registry in the HKEY_CLASSES_ROOT subtree. This subtree contains values from the HKEY_LOCAL_MACHINESOFTWAREClasses subkey (which contains global settings) and the HKEY_CURRENT_USERSoftwareClasses subkey (which contains individual user settings). If a value exists in both Classes subkeys, the user setting wins over the global setting.

You might be familiar with the GUI methods for associating a file type with a program. If you attempt to open a data file for which no association exists, you're presented with the Open With dialog box, which gives you the option of making your selected application the default association. You can also create file associations in Windows Explorer by selecting Folder Options on the Tools menu, then clicking the File Types tab. These methods are fine if you know what you're doing and you need to create the file associations on only a couple of systems. However, if you need to create file associations for a large group of users, you should familiarize yourself with two XP command-line tools: Assoc, which lets you create a file-extension key, and Ftype, which lets you create a program class.

Listing 1 demonstrates how to use these commands. The first line creates a file-extension key called .elog that has a value of CompanyName Text. In simple terms, Assoc is telling the OS shell that when it encounters a file with the .elog extension, it should refer to the CompanyName Text program class for instructions on how to open that file. The next two lines accomplish the same task for two other file extensions (i.e., .ref and .glo). Note that when you specify the program class name in Assoc and Ftype, you just need to use the friendly name. If necessary, you can elaborate on the name to avoid confusion by adding a period (.) followed by the qualifier (e.g., CompanyName Text.Logfile).

The last line in Listing 1 uses the Ftype command to create the CompanyName Text program class. The Ftype command accomplishes this task by creating the CompanyName Text subkey in the HKEY_LOCAL_MACHINESOFTWAREClasses subkey. The value of the CompanyName Text subkey is the pathname of the executable file that will be used to open associated data files (in this case, C:Program FilesMicrosoft OfficeOfficeWinword.exe). The "%%1" parameter allows the data file to be passed to the executable as an argument; without that parameter, the application would open, but the data file that launched it wouldn't be loaded.

If you were to double-click a file with an .elog, .ref, or .glo extension after you ran the commands in Listing 1, Microsoft Word would open that file. You can add the Assoc and Ftype commands to a logon script or distribute the commands through other tools to provide consistent application usage among your users.

Note that the values you set using these commands will overwrite previous associations. So, if your users have made their own associations, you can still enforce your organization's standards. If you need to remove an association, it's easy to do so. For example, if you want to delete the .elog association, you'd run the command

Assoc .elog=

An Important Control
Although offering a Web-accessible repository of file extensions and possible associated applications is a noble concept, there are a few factors that make the file association Web service an unsatisfactory solution for end users and IT organizations. By disabling access to the file association Web service and configuring file associations for your users, you can head off frustration and wasted time for users and support staff alike.