Jump to content
Welcome to our new Citrix community!
  • 0

Upgrading from 7.15 LTSR to 7.1912 LTSR

Matt Kozlowski




I'm currently planning an upgrade from XenDesktop 7.15 CU2 LTSR to 7 1912 LTSR

I'm reading through the documentation:






I was wondering if folks had any feedback regarding caveats or things to watch out for?

anything with StoreFront or UPM?


We use the following products:



Provisioning Services


License Server

XenServer 7.1 CU2


WEM (just starting)


Link to comment

8 answers to this question

Recommended Posts

  • 0

Just an update on the in-place upgrade failures. I think we isolated the cause to antivirus. We use Sophos, and while i had tried disabling all the Sophos services, what i missed was there was a HitmanPro service that was still running. This also correlated to events we were seeing in the event logs. So i should either plan to make sure my Citrix exclusions are up to date, or plan to disable that service as well for the production upgrade. Honestly, should probably do both. Another piece to note is that i needed to remove my second server from the server group. Citrix doesnt support running mixed versions on StoreFront so that needs to be done prior to the upgrade as well. Was a good catch by support, I didnt notice that. Will do some additional testing with my storefront upgrade then move on to agents, ddc's, and pvs, etc. Will update with my findings on those. I'll compose a master list at the end of all caveats and things learned just in case anyone else runs into them.

  • Like 1
Link to comment
  • 0

And right away, running into issues lol. License server upgrade went fine, Storefront upgrade fails right out of the gate... getting the attached error. Have tried a number of things to no avail.


-Turned off antivirus

-Stopped Citrix services

-Ran installer as admin

-Deleted StoreFront Install directory from program data

-Verified no thumbs.db files exist

-Attempted to modify ProtocolTransitionService but it doesnt exist (at least it doesnt appear to on my version)

-Verified the os is supported - Windows Server 2012 R2 Standard


I have a case opened with Citrix currently. Will post my solution as well as any other issues i run into in case anyone else runs into the same.



Screen Shot 2020-04-15 at 10.31.32 AM.png

Link to comment
  • 0



I've done multiple upgrades for for customers, and if anything were to go wrong, it would always be the StoreFront server upgrade :-(

Depending on how complex the configuration is on the StoreFront server(s), and how customised the server is, sometimes is's just quicker to uninstall the old StoreFront server and install the new version as a clean install.


If you can post the contents of the txt file shown in the picture above...




Ken Z

Link to comment
  • 0

Thanks for reaching out Ken! I can definitely relate, I've seen the same here in past upgrades. Attached is one of the log file versions... I've been doing a lot of trial and error with frequent reverting of snapshots so i'm not a hundred percent which attempt this was. But this is also what i had uploaded to my case with Citrix.


Link to comment
  • 0

Hi M


looking at your log file, there are two errors that i would look at...


Line 663 .NET Framework 4.7.1 errored.  Can you confirm that that version 4.7.1 of .NET Framework is successfully installed

multiple lines with "Process completed with error code 0x00000643" during the StoreFront upgrade


There is a Citrix article about the second (StoreFront) errors.... https://support.citrix.com/article/CTX238205 

This suggests what was already mentioned; uninstall StoreFront, delete any folders left behind, then perform a clean install.


I should mention that Hex 643 is Decimal 1603, and if you google for StoreFront error code 1603 you'll get other causes of StoreFront failing to upgrade, such as SCOM management agents, etc. For example, in this article https://blog.ollischer.com/citrix-storefront-direct-upgrade-from-v3-0-0-45-to-v3-5-0-23-fails-with-error-code-1603-fatal-error-during-installation the problem turned out to be Microsoft Visual C++ redistributables.




Ken Z

Link to comment
  • 0

I think .NET gets installed as a pre-req. Then when the installation had failed i had repeated the install. I'm "assuming" it installed correctly, but if its listed there in the log, then i should go back and double check. Maybe i can just manually install it ahead of time so that its already present. I'll give that a go.


I may have to go the route of the re-install like you mentioned... was hopping to avoid it with a clean upgrade but i may not be able to. Will do some more testing this week.


Thanks for taking a look!



Link to comment
  • 0

Just as a follow up, so far it appears pre-staging with .NET 4.7.1 didnt seem to make a difference. I was able to successfully re-install though... so thats one approach that should work when it comes time for production. Still have the case opened to analyze the failure though, would just be nice to figure out what part the upgrade doesnt like. Will continue to update with my findings as i move onto upgrading the other components.

Link to comment
  • 0

Sorry for the delay, It's been a little while since i've been able to get back to this. I've been spending some time troubleshooting a WEM installation and have been involved in some other time consuming projects. After resolving the support case, i did attempt an in-place upgrade (with StoreFront) a few more times, to see if adding in the additional exclusions would help. The products (Sophos and Citrix) just didnt seem to play well together. So a re-install with antivirus temporarily removed really was the quicker approach for me. Because of the time difference it looks like CU1 has also been released for XD 7 1912. So everything i had previously upgraded had to have that applied. I have made some additional progress with the other upgrades:


PVS from 7.15 CU2 upgraded to 7 1912 CU1 seemed to go fine. Only thing i would note is after the .NET 4.7.1 pre-req there was a reboot required and a dialogue box gets displayed too quick to really see it because the system is being rebooted. But I believe it was just another dialogue to reference that a reboot was needed. 


XD 7.15 CU2 to 7 1912 CU1 also seemed to go fine (surprisingly). I was expecting a hiccup there as i've seen issues in the past once it got the point where the DB needed to be upgraded.

Though from past experience, i made sure both DDC's were upgraded prior to the DB upgrade.


I have to finish with my agent upgrades and then i will schedule production upgrades. Still need to do UPM as well.


So far the main thing i would recommend is to make sure you have your VM snapshots and the databases backed up prior to the upgrade. Those definitely came in handy when i ran into issues and/or wanted to repeat test scenarios.


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...