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:

1. Open the registry editor.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system.
3. Choose New, DWORD Value from the Edit menu.
4. Name the new value NoInternetOpenWith.
5. Right-click the new NoInternetOpenWith entry and choose Modify.
6. Enter the number 1 in the Value data field and make sure the Hexadecimal option is selected, then click OK.
7. Close the registry editor.

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.

   Previous  [1]  2  Next