There is a bug in the installation routine for PS 4.5 HRP01 that in certain server configurations will cause MSI Self Healing to be triggered on systems where HRP01 has been installed. There are very specific conditions that cause this problem and there are several workarounds/fixes. First let’s start by describing the symptoms of the problem:
1) You’ve deployed Hotfix Rollup Pack 1 (HRP01) to your PS 4.5 Servers.
2) You have Speedscreen Browser Acceleration enabled. This is a default setting.
3) Users see an MSI Self Healing attempt whenever they run a published Internet Explorer application. This self healing does not throw any error messages and eventually does complete (after around 4 self healing attempts). However, it appears every single time one of your users attempts to run Internet Exporer (in otherwords, it’s not really healing anything).
4) You notice the following sequence of errors in your Event Logs.
5) First you see an event like this:
7) Then a message stating that Product Configuration completed successfully. One would think that this meant the self healing worked.
Now that we’ve described the symptoms, let’s talk about the conditions in which this occurs and then talk about what you can do about it.
1) You’re running PS 4.5 and have deployed HRP01 (duh!)
2) You have a multiple partition OS install (i.e. C: and D: for example).
3) The non-C: disk partition has more available disk space free than the C: partition.
4) On this other partition, users do not have Read permission to the root of the drive.
While I have no inside information from Citrix on this issue, my personal belief is that this is occuring because of a feature of Windows Installer that attempts to install software to the drive letter disk the most disk space. In the Windows Installer world, folks usually set an MSI property called ROOTDRIVE that will force the instalation of the component to a particular drive letter to avoid this issue (more on this property later).
What to do about it:
Now that you fully understand what the problem is, let’s discuss the workarounds/solutions:
What to do if you’ve already deployed HRP01 to your servers and are having this issue (only one fix is necessary):
1) In the first event log error dialog you can see that it references “E:\ does not exist”. It’s not that E:\ does not exist, it’s that the logged in user doesn’t have rights to Read the root of the E: drive. To solve the problem, you could grant Authenticated Users or Domain Users read access to E:\ (or whatever drive is referenced)
2) This problem is due to the Speedscreen Browser Acceleration feature of Presentation Server. If you disable Speedscreen on those servers (or at a farm level) this issue goes away.
3) You can make a registry hack to prevent the HRP01 self healing from trying to access the E:\ drive (or whatever drive it’s referencing). Here’s the contents of the registry file that will resolve the issue. Simply save these contents as a .REG file and double-click to fix (you could also place this into a template IM script for deploying via Installation Manager as I’ve done. This reg file assumes you’ve installed Presentation Server to the C: drive. If you’ve installed it to some other drive, simply edit the letter listed below accordingly.
Windows Registry Editor Version 5.00
If you have not deployed HRP01 yet (only one fix is necessary):
1) Wait for HRP02. Citrix has confirmed this issue as a bug in HRP01 and they’ve committed that it will be fixed in HRP02. So if you haven’t deployed HRP01 yet, you could wait until HRP02. However, there’s a lot of good fixes in HRP01 and the post HRP01 hotfixes, so I wouldn’t recommend this as an option.
2) Use ROOTDRIVE property on HRP01 installation. As I mentioned earlier, all Windows Installer packages can be deployed using a command line property named ROOTDRIVE. If you use the ROOTDRIVE=C:\ parameter when installing HRP01 you’ll avoid this issue. You can either supply it manually on the command line if installing HRP01 interactively, or you can add it to the command line properties within Installation Manager.
Congratulations! You’re all fixed now.
As a future recommendation, I’d suggest that you take the approach of using the ROOTDRIVE property when installing all Citrix hotfixes to ensure that this doesn’t happen again. I seem to remember this issue having occurred in the MF XP or PS4 product line, but I can’t find any references to the issue now. Using the ROOTDRIVE=C:\ should not cause any negative side effects and would ensure that the issue doesn’t repeat itself.