One side effect of improved per-user customization in Windows is that it's difficult to determine what application opens a specific document type for users. This can be crucial if you're attempting to monitor application usage to verify compliance with company policies or licensing restrictions, or predict breakage caused by old user customizations after application migrations.
The central problem with finding the document handler used by an application for a specific user is that the information is stored in a location that isn't normally accessible from any context but that of the user. Windows uses the HKEY_CLASSES_ROOT (HKCR) registry subtree to determine what document handler to use, but this key is synthesized at logon by taking machine-wide settings from the HKEY_LOCAL_MACHINE (HKLM) subtree and overlaying user-specific customizations from the HKEY_CURRENT_USER (HKCU) subtree. Although you can access the registry remotely, what you read will be based on either the HKLM key or your own HKCU key (if your profile was loaded) retrieved by that machine—not the logged-on user's key.
To inspect user-specific registry data, the only realistic solution is to handle the inspection from the user's context. This will always return information that's correct from the user's standpoint. You can use code like that shown in Listing 1 in a logon script to perform this kind of user-based document-handler check.
To make the document-handler check code work properly, you should customize the extension value set in callout A to match the file extension of the handler you need to check. As written, the code will check the document handler for PDF files.
Given the file-type extension, the code in callout B looks up the handler the same way Windows does—by checking the default open command for that file type. Specifically, the code first obtains the name of the class for the file type from the extension's registry key. The code then goes to that class's registry key to obtain the default open command and assigns this document-handler information to the OpenCommand variable. If the extension or the associated file type isn't correctly registered, the code will throw an error. If an error occurs, the code suppresses the error and assigns a value of "undefined" to the OpenCommand variable.
Next, the code collates the extension, username, and document-handler information in a variable named data. In callout C, the code then sets the variable named server to the name of the logon server, then writes the data variable's contents to that server's Application log. The resulting messages will look similar to
user aka opens .pdf documents with:
"C:\PROGRA~2\FOXITS~1\FOXITR~1
FOXITR~1.EXE" "%1" on system X51
Events logged from a Windows Script Host (WSH) script always use WSH as the source application.
When you incorporate the code in Listing 1 into a logon script, you can occasionally check the logs to find the default application handling specific documents on a per-user basis on individual client workstations. If you want to find the document handler used by an application for a specific user but you don't want to incorporate the code in Listing 1 into a logon script, you can comment out the code in callout C, uncomment the code in callout D, and run it on the user's machine.
You can download the code in Listing 1 by clicking the Download the Code Here button at the top of the page. I wrote this code for use on Windows XP and later.
Listing 1: Code That Checks for User-Based Document Handlers |
 |
Register
