Are your VMware, Citrix and AD teams talking? They should be.

So here are some quick lessons I learned recently in some of the Citrix Provisioning XenDesktop vSphere environments I have been working in.   The typical solution consists of Citrix Provisioning Services streaming down a XenDesktop brokered OS to a vCenter managed vSphere Virtual Machine.  Lots of ties and connections to different systems and management consoles and different Admin groups sometimes.

The first time, I was working with the VMware servers and during some housekeeping, I decided to remove a HOST from vCenter and add it back in under a different cluster.  The VMs on the box all remained up and on and weren’t changed.  What I forget about was the XenDesktop management interface that was linked to the VMs via vCenter to facilitate power operations.  When the host and it’s machines were added back into vCenter, XenDesktop could no longer recognize them.  The associate between Virtual Machine and Active Directory computer account was broken and had to painstakingly be reestablished.  Woops. 

The next time around, I was working with the Provisioning Services console and due to some flaky behavior, decided to recreate some AD accounts for the XenDesktops.  Again, forgetting about the management in XenDesktop, I had broken all of the connections between Virtual Machine and AD Computer account.  This time, the Virtual Machine column was intact but the AD column just had old unresolvable SIDs in it.  Back to the console to reestablish all of the connections again.

In environments where Active Directory, XenDesktops and VMware are handled by different teams, it is prudent to try to get on the same page.  With all the connections and dependencies, seemingly innocent actions in one environment could create disastrous results in another.