Upgrading your Citrix XenDesktop DDC Failure. [SOLVED]
Here is a quick Citrix XenDesktop writeup from my colleague Rajen Das.
Ran into an interesting one the other day while upgrading XenDesktop 7.11 to XenDesktop 7.15 LTSR and moving the databases (two separate instances)
The farm consists of two-DDCs. Both DDCs had an equal number of registered devices. I started with the DDC #2 for no particular reason. The upgrade failed at the “Post Configuration” state. I rebooted the server, but by then the damage was done. Luckily, I had taken a snapshot of the DDCs and the full backup of the DBs.
I reverted the changes and tried it again. This time, however, I was holding my lucky ball, Wilson. But it failed at the same spot. Without wasting any more time, I decided to call Citrix. I later realized that was a waste of time. I repeated the same steps for them only to come to the same conclusion. They collected the logs and wanted 48 hours to review.
I reverted everything again. This time, I tried the DDC #1 first. Voila! It upgraded without a hitch.
Then I started digging into why that was the case. I noticed DDC #1 was doing all the heavy lifting while DDC #2 only managed one of the host connections.
Get-BrokerController
ActiveSiteServices: ControllerReaper ControllerNameCacheRefresh Licensing BrokerReaper RegistrationHardening WorkerNameCacheRefresh AccountNameCacheRefresh PowerPolicy GroupUsage AddressNameResolver RebootScheduleManager RebootCycleManager ScopeNamesRefresh FeatureChecks RemotePC IdleSessionManager LeaseReaper OperationalEventsService vSphere [vSphere Connection Name Redacted] ConfigurationExport LicenseTypeChanged
Lesson learned: Identity which DDC is Primary. If the services are distributed equally, shut down all but one DDCs until only becomes the primary site-service. Now, you should able to upgrade or migrate your databases.
