You may run into a little bit of a challenge upgrading a Windows 7 system from the XenDesktop 5.6 VDA (I was using 5.6.200.9 on this particular machine) to the latest XenDesktop/XenApp 7.5 VDA (7.5.0.4523). If you uninstall the 5.6 VDA, reboot, then try to install the 7.5 VDA expecting a clean install, it will fail and you’ll get the always wonderful and completely generic “InstallFailure 1603” error message:
When you View error details, you’ll see something like this:
Error Id: XDMI:CFF2362A
Exception:
Citrix.MetaInstaller.MetaInstallerException Installation of MSI File ‘BrokerAgent_x64.msi’ failed with code ‘InstallFailure’ (1603).
at Citrix.MetaInstaller.Msi.InstallProduct(InstallationContext context, String msiPath, String parameters)
at Citrix.MetaInstaller.MsiComponent.Install(InstallationContext context)
at Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)
Apparently this is an issue related to .NET changes by Microsoft. Even if you uninstall and re-install each .NET version manually, the install will fail. I’m aware of at least 4 incidents lodged with Citrix Support on this issue since 7.5 was released so not everyone may be impacted. It’s been kicked up to development and I’m sure a fix is forthcoming.
In the meantime, it was suggested to re-image the system. That’s not going to fly with me. I tried several things to fix this and here is what finally worked for me:
1. Completely uninstall the “half-way” installed XenDesktop/XenApp 7.5 VDA
2. Uninstall any other Citrix components from previous VDAs if anything is left over (the only thing I left was Receiver)
3. Download and run CCleaner – http://www.piriform.com/ccleaner/download
4. Click Registry on the side and hit “Scan for Issues”. You’ll notice a ton of Citrix related stuff left in the registry. Click “Fix selected issues” then reboot.
5. Once it’s back up, do step 4 again and you might still notice a few things picked up by the scan. Fix and reboot yet again if you do see anything.
6. Once it’s back up, intstall the 7.5 VDA and it should complete installation and register with the Delivery Controller
Hope this helps you out. I expect the next VDA version to resolve this issue and hopefully this workaround will hold you over till then.
Jason Samuel is a visionary product leader and trusted advisor with a proven track record of shaping strategy and driving technology innovation. With extensive expertise in enterprise end-user computing, security, cloud, automation, and virtualization technologies, Jason has become a globally recognized authority in the IT industry. His career spans consulting for hundreds of Fortune 500 enterprises across diverse business sectors worldwide, delivering cutting-edge digital solutions from Citrix, Microsoft, VMware, Amazon, Google, and NVIDIA that seamlessly balance security with exceptional user experiences.
Jason’s leadership is amplified by his dedication to knowledge-sharing as an author, speaker, podcaster, and mentor within the global IT and technology community. Recognized with numerous prestigious awards, Jason’s contributions underscore his commitment to advancing technology and empowering organizations to achieve transformative results. Follow him on LinkedIn.
Chris Hahn
June 4, 2014 at 12:14 PM
Ran into a similar issue installing any of the XD 7.5 components would fail. Ended up uninstalling .NET 4.5.1, then ran Citrix installer. Citrix installer then runs fine and reinstalls .Net 4.5.1.
Gwyn Llewelyn
June 25, 2015 at 4:33 AM
I came across this problem whilst upgrading from XenApp 6.0 to XenApp 7.6, and running CCleaner didn’t work, neithier did reinstalling .NET.
I’ve found exactly what the above problem is (at least in my case). I had the exact error in your screenshot above with BrokerAgent_x64.msi.
The problem here is that the XenDesktop installer is poor at passing any kind of meaningful error message from the MSI installer involved, because 1603 just means “install failed”.
Anyway, I found the BrokerAgent_x64.msi on the XenDesktop install media and ran it manually, and this gave a much more meaningful error:
“Could not open key: UNKNOWN\Components\(long-key)\(another-long-key). Verify that you have sufficient acces to that key, or contact your support personnel.”
Now just replace the ‘UNKNOWN’ section of the above path with:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18
and you have the whole path to the registry where it doesn’t have access.
So all you need is to take ownership of the keys where the permissions are incorrect (remembering to ‘Replace permissions on subcontainers’, and then give Full Control to the local ‘Administrators’ group for these keys, then all the other permissions will follow suit.
So if you sort out these permissions then you’ll be able to run the install without problem, hopefully.
Much better than running CCleaner in my opinion 🙂