Browse All Articles
> Upgrade from Citrix XenDesktop/XenApp 7.1 to 7.6
I performed the upgrade from Citrix XenDesktop/XenApp 7.1 to version 7.6 in my test environment and it's not as easy as the Citrix doc would lead you to believe. There are several incorrect steps in their document and several steps missing. There also appear to be some bugs in the upgrade code. Below is what worked for my environment. Hope this helps.
Upgrading the Controller works fine, it reboots and then completes whatever post-install stuff it wants to do. After that, launching Studio for the first time offers the mandatory upgrade of the database.
It fails with "The service instance is already registered with the Configuration Service".
This forum post refers to the exact problem but the workaround may not be supported by Citrix.
Correction: At the end of the support call, Citrix endorsed this solution. http://discussions.citrix.com/topic/356640-site-upgrade-xendesktop-75-to-76-error-id-xddsc266bbdf/
I would just remove the broker service entries rather than all entries: "Get-ConfigRegisteredServiceInstance -ServiceType "Broker" | Unregister-ConfigRegisteredServiceInstance". You can then call "Get-BrokerServiceInstance | Register-ConfigServiceInstance" on each controller. This would target the conflicting service instances and leave the others in place.
Support had us run and we saw all the zero's with "ServiceInstanceUid".
Doing so recalled a value for the "ServiceInstanceUid" before but in this failed state it reports all zeros.
Support then had us run just the REGISTER part of the PowerShell w/o doing the UN-REGISTER but it failed.
We then got approval to proceed with the exact syntax mentioned in the forum post and it worked.
This time opening Studio never mentioned anything about upgrading the database so presumably it actually finished before the error condition earlier. It went straight to SITE UPGRADE option.
We used Get-BrokerDBConnection
to validate the database was upgraded.
We then clicked on the Upgrade remaining controller’s task and realized it wasn't actually going to upgrade it. It tells us to go upgrade it ourselves and then come back to register it. According to step 7 in eDocs, it alludes to "pushing" an upgrade from Controller 1 to other controllers, but that isn't true.
You must manually upgrade additional controllers, then come back to Controller 1 and register them with this button.
Below are the incorrect steps from the how-to upgrade section of eDocs. http://support.citrix.com/proddocs/topic/xenapp-xendesktop-76/xad-upgrade.html
7. From the newly upgraded Studio, select Citrix Studio site-name in the navigation pane. Select the Common Tasks tab. Select Upgrade remaining Delivery Controllers.
8. After completing the upgrade and confirming completion, close and then reopen Studio.
9. In the Site Configuration section of the Common Tasks page, select Perform registration.
Registering the Controllers makes them available to the Site. We manually upgraded the second Controller and then rebooted it. After logging in it continued the install and did the post-reboot config stuff. Then afterwards, the second Controller was registered automatically and the button disappeared (so we thought – See the end of this doc where we found out otherwise). So steps 7 and 8 seem irrelevant but 9 did in fact need completed later.
We hit the TEST SITE button and it took several minutes
Clicked on LICENSING inside CONFIGURATION node in Studio and it never enumerated anything. We attempted to open Studio on the second Controller and it never opened either. We rebooted the second controller in an attempt to give it a clean slate.
We validated the XML port and STA ID did NOT change post upgrade.
We rebooted Controller #2 and then opened Studio. This time it opened but this message was presented to us.
After rebooting Controller #1 Studio opened. At this point the "Register upgraded Delivery Controllers" button came back.
That registration completed and we were able to now open Studio on Controller #2 but it still gave the error. We rebooted Controller #2 one more time to check afterwards. Once we rebooted everything was working. Success!!
Licensing information was enumerating in the console of Controller #1 and looked fine.
Hosting information was showing the following error on Controller #1 but it was determined to be a pre-existing issue.