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.