Citrix XenApp

Upgrading from XenDesktop 5.6 VDA to XenDesktop/XenApp 7.5 VDA

on

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:

vda install failure

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.
2

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.

About Jason Samuel

Jason Samuel is an Infrastructure Architect in Houston, TX with a primary focus on mobility, virtualization, and cloud technologies from Citrix, Microsoft, & VMware. He also has an extensive background in web architecture and information security. He is certified in several technologies and is 1 of 50 people globally that is a recipient of the prestigious Citrix Technology Professional (CTP) award. He is 1 of 28 people in the world that is an Atlantis Community Expert (ACE). He is a featured author on DABCC which provides the latest IT Community News on Cloud, Data Center, Desktop, Mobility, Security, Storage, & Virtualization. In his spare time Jason enjoys writing how-to articles and evangelizing the technologies he works with.

Recommended for you

2 Comments

  1. 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.

  2. 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 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *