I have a customer that is performing an upgrade to Presentation Server 4.5 right now. The way I setup their deployment is that the server is built with 2003 SP2 and then an unattended build of PS 4.5. Then after the server is joined to the farm, there’s an Installation Manager package group of about 50 core components that are pushed to the server. From a Citrix hotfix perspective, the following items are deployed:
PSE450W2K3R01.msp – Hotfix Rollup Pack 1
PSE450R01W2K3003.msp
PSE450R01W2K3004.msp
PSE450R01W2K3007.msp
PSE450R01W2K3008.msp
PSE450R01W2K3009.msp
PSE450R01W2K3010.msp
PSE450R01W2K3029.msp
PSE450R01W2K3033.msp
PSE450R01W2K3036.msp
PSE450R01W2K3042.msp
PSE450R01W2K3032.msp – Limited Release hotfix
These hotfixes were generally deploying well to all servers, but I’ve noticed an odd situation that’s sometimes occurring when I push the entire package group to a brand new server. It seems that during the deployment of PSE450R01W2K3008.msp it sometimes stalls the installation of the IM Package Group (i.e. it does ever seem to finish). Upon further investigation of the MSI log, I’m seeing where the problem is occurring. Here’s a snippet of the MSI log with the relevant MSI action that’s hanging the install:
MSI (s) (08:30) [11:11:00:350]: Executing op: ActionStart(Name=CtxComPlusAppRegister.E289452F_B008_4882_ABB2_77E22692D9C4,,)
MSI (s) (08:30) [11:11:00:350]: Executing op: CustomActionSchedule(Action=CtxComPlusAppRegister.E289452F_B008_4882_ABB2_77E22692D9C4,
ActionType=3073,Source=BinaryData,Target=CtxComPlusAppRegister,
CustomActionData=CitrixLogServer.E289452F_B008_4882_ABB2_77E22692D9C4=key_app_name=CitrixLogServer
key_type=2
key_component=C:\Program Files\Citrix\System32\CitrixLogServer.dll
component_tlb=C:\Program Files\Citrix\System32\CitrixLogServer.tlbcomponent_psdll=component_install_state=3component_action_state=3
key_role=__allrole_install_state=3role_action_state=3key_user=networkserviceuser_domain=nt authority
key_property=Identityproperty_value=nt authority\networkserviceproperty_type_value=6)
So the stall in deployment seems to occur when the COM+ Registration for CitrixLogServer.dll is attempting to happen. So what now?
So I’ve narrowed down my issue to a COM+ registration issue, now what?
One word….Google 🙂
After search for this COM+ registration issue, I came across a Citrix Support Forum thread with the same MSI error that’s happening to people when trying to install PS 4.5 straight up. So people seem to have this problem during the installation of PS4.5 and not from a specific hotfix like I’m having.
In response to that support thread, Citrix has published CTX113639 where they acknowledge an issue with PS 4.5 installation during the COM+ registration of the CitrixLogServer.dll. Citrix supplies a custom MSI transform (MST) to install PS 4.5 with if you’re having this issue.
So there’s definitely a COM+ issue, but why?
I opened a private support thread with Citrix to find out what specifically is contained in that MSI transform that’s allowing the installation to proceed where it otherwise would not. I received a response from Citrix that stated the issue with the original install and what is being resolved by the transform is that the installation routine is attempting to resolve the SID of the Network Service account using a Win32 API call named LookupAccountName. According to Citrix, when this call is being made there are certain situations within AD environments that will cause this lookup to take a long time to resolve. Something about broken domain trusts, blah blah blah. Well I was pretty certain that there weren’t any domain trusts in this environment, but I wanted to try and validate what Citrix was telling me. So I got some source code that utilized LookupAccountName from Advapi32.dll. I ran the code and performed a SID lookup on NetworkService. It returned S-1-5-20 within a fraction of a second. Well, either I was misled or there’s something else going on.
Dealing with the stalled hotfix deployment
Since I was unable to determine the root cause of the COM+ registration issue in my first attempts, I decided to see what I could do to resolve this issue without having to spend tons more time debugging it. I began with the obvious choice, I rebooted the server with the stalled deployment. To my surprise, after the reboot Installation Manager re-targetted PSE450R01W2K3008.msp against the server where it was previously stalled, but this time the installation completed within seconds. Hmmmmmm. So now what?
Bring on HRP02
Considering the combined issue that I really didn’t want to reboot the servers during the IM package group deployment AND Citrix recently released HRP02 which includes PSE450R01W2K3008.msp, I decided to at least investigate using HRP02 as a solution to my issue. I’m pleased to say that HRP02 installed on both existing servers with the older hotfixes, as well as fresh servers without any Citrix hotfixes without a hitch. The other great news is that Citrix seems to have resolved the issue that plagued HRP01 where MSI self-healing would trigger because of Speedscreen Browser Acceleration when deployed on servers that had a larger E: drive than C: drive. I know it’s an obscure problem, but it happened to me and at least a few other people out there based on the support forum threads.
So now I’m rolling with HRP02 and PSE450R02W2K3001.msp. So far, there’s been no issues.
Agree? Disagree? Let me know with a comment...