I had been running XenApp 6.5 with App-V 4.6 for a few months prior to App-V 5.0 being released. As it turns out, App-V 5.0 and it's connection groups greatly assisted me with resolving an integration issue between Microsoft Office 2010 and a few other apps.
Brilliant!
So needless to say, App-V 5.0 was placed into production. However, File Type Associations (FTAs) were curiously not being applied from the App-V 5.0 package. Keep in mind, I was logging into an XA 6.5 server with a pre-existing user account and one which had previously logged into an XA 6.5/App-V 4.6 server. After deploying Microsoft Office 2010 to the farm with App-V 5.0, I was bombarded with calls from users who were unable to open, for example, a .docx file....since there was no associated application.
Since all of my applications are published globally to a XenApp server, I thought this was odd since, by default, I assumed FTAs from the package should do all of the heavy lifting. Furthermore, publishing the package to the user (not the machine) correctly associated the FTAs for that logged in user. Weird. Taking this into account, I was not so keen on publishing Office 2010 to a user each time they logged in to their ICA session.
The Workaround
XenApp content redirection. Since my first priority was to restore some functionality for the users, I went about letting XenApp take care of the FTAs for the time being. This was simple enough to enable via the properties for the published app. From here-on-in, XenApp would intercept the FTAs and launch the required application were applicable. So for now, users happy.
The Problem
I was determined to let App-V 5.0 take care of the FTAs rather than XenApp intervening. The key to my problem was existing user accounts that had previously logged into an XA 6.5/App-V 4.6 server. These users had already had their user profiles populated with FTAs from the previous environment and as it turned out, it wasn't as straight forward as App-V 5.0 taking ownership of the FTA's. Disabling Content Redirection simply disassociated the FTA with an application and put users back at square one.
Furthermore, logging into a XenApp 6.5/App-V 5.0 server with a NEW account, let the App-V 5.0 FTA's take straight away. This way, I could happily switch between XenApp Content Redirection and Native FTA's at will. Although, the prospect of deleting and recreating thousands of Citrix User Profiles was not exactly high on my agenda. There had to be another way....and there was.
The Solution
Buried within the user profile was the UsrClass.dat file (%AppData%\Local\Microsoft\Windows). In this file, all of the FTA's are kept for the user. At login, this .dat file is loaded along with the typical NTUSER.dat file. However, when mounting and browsing through the NTUSER.dat file, I couldn't find the required FTA's ANYWHERE! Much to my delight, when I found, mounted and browsed through the UsrClass.dat file, I could see ALL of the FTAs and their existing associations to the App-V 4.6.
As a test, I located the .docx extension key within the hive and deleted it. After dismounting, I logged in to an XA 6.5/App-V 5.0 server and voila! App-V 5.0 has control of the FTAs. When comparing a .doc (controlled by XA Content Redirection) and a .docx (native App-V 5.0), I could see that when Content Redirection was disabled, the .doc was inoperable whilst the .docx would happily open up Word. If content redirection was re-enabled for both, .doc and .docx would open Word, however, this was being initiated by the XA Online-plugin.
As such, it was simply a case of configuring Citrix UPM to NOT synchronize the UsrClass.dat files at logon/off. To prevent UPM from inadvertently loading the UsrClass.dat file, I used a straight-forward Powershell script to search for and delete all instances of UsrClass.* from the UPM profile store.
Since then, all FTA's are maintained by App-V 5.0 and function exactly as expected.
Enjoy.
No comments:
Post a Comment