App-V: The Case of the Lingering File Type Association
I recently encountered an issue where a customer deployed a virtualized instance of Adobe Reader and then later moved to a locally installed version. The customer was wondering why clicking on the PDF documents resulted in the virtualized instance of Adobe Reader trying to open the document (which was removed so an error was displayed.)
We examined HKEY_CLASSES_ROOT and found there was still the presence of the old FTA going back to SFTTTRAY /launch. Since the FTA’s stored in HKEY_CLASSES_ROOT are an amalgamation of User and System FTA’s, we needed to check both the HKEY_LOCAL_MACHINE\Software\Classes key as well as the HKEY_CURRENT_USER\Software\Classes key because the USER-configured FTA’s will take priority.
In fact, tracking FTA’s with virtualized applications require searching the following keys to track down FTA storage:
- HKEY_USERS\<User SID>\Software\Classes (or HKEY_CURRENT_USER\Software\Classes)
When searching for the .PDF and its corresponding document objects we found that the left over FTA was coming from the User Hives:
HKEY_USERS\<User SID>\Software\Classes (or HKEY_CURRENT_USER\Software\Classes)
The file type associations were no longer present under
HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\FileTypes
We found that after removing the Adobe Application from the client, it would always appear to remain no matter what we were trying from the App-V angle. Even purging the global and user caches manually, the FTA would always come back even though it was not on any app-v client or server.
A Roaming, Mandatory Profile
Even going into the registry and manually removing it would not cause this issue to permanently go away.
What was even more disturbing was the fact it was still showing up under:
after every logoff.
That’s when it hit me! Roaming Profiles were being used. I was already aware of that but what we did not know (until I was looking at a userenv.log file to see if there were profile upload issues upon logoff) was the fact that the user was using a mandatory profile.
Now, while mandatory profiles are not recommended or needed for App-V server-based environments, they will not cause these types of problems in and off themselves so long as the mandatory profile is user-neutral of any App-V configuration.
So how did the FTA get there?
The Profile was created while an account had been logged in and connected to an App-V management server. Before the user logged off to preserve the profile, the App-V client had done a refresh against the publishing server and brought down Adobe Reader and the file type associations. The FTA information was stored in the user’s registry.
Modifying the original hive from the source mandatory user profile resolved the issue.