There are quite a few blog posts about the benefits and drawbacks of either using:
Manually enter controller location(s)
… or:
Select from Active Directory
when planning a Citrix XenDesktop 5.5 environment.
While both sides of the argument have valid points, I personally prefer using Active Directory to publish DDC information because:
- It lowers the possibility of making a typo such as last week when one of my clients asked me why his virtual desktops weren’t registering and when I checked his ListOfDDCs registry keys, he had entered the XenApp servers FQDN. What most people don’t know is that when you hit the Check button, it just checks to see if the names resolve via DNS and not whether it’s actually a DDC.
- Making changes to the list of DDCs would seem to be a lot simpler than managing settings that are stored on the virtual desktop’s registry.
With that being said, I understand that virtual desktops are spawned from master images and changing the master image isn’t usually that big of a deal but as the virtual desktop environment gets bigger, refreshing images means you need to stagger the reboots or you’ll find yourself creating boot storms. In any case, if you would like to configure for DDC discovery through Active Directory see the following instructions.
First, you can find the documentation for controller discovery at the following Citrix product documentation: http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-about-broker-discovery-rho.html
Most Citrix administrations will be familiar with the following registry key, ListOfDDCs, that stores the list of DDCs:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VirtualDesktopAgent
This will change once you configure for Active Directory Discovery so proceed with locating the Active Directory OU containing your XenDesktop server(s) objects and write down the DN (distinguished name) of the OU:
OU=XenDesktop,OU=Citrix_servers,OU=someOU,OU=Servers,DC=someDomain,DC=someTLD
Start up PowerShell on your DDC, change the directory to:
C:\Program Files\Citrix\Broker\Service\Setup Scripts\
… then execute the following PowerShell script with the additional switch and DN of the OU with your XenDesktop server computer objects:
.\Set-ADControllerDiscovery.ps1 -on -existingOUDn "OU=XenDesktop,OU=Citrix_servers,OU=someOU,OU=Servers,DC=someDomain,DC=someTLD"
Once the PowerShell cmdlet successfully completes, proceed with restarting the Citrix Broker Service:
Proceed with refreshing the OU containing your Citrix XenDesktop servers and you’ll see a new Active Directory Security Group created:
There are actually more objects contained in the OU and if you’d like to review them, proceed with turning on the Advanced Features in Active Directory Users and Computers and review objects in the OU again:
Notice how the following 2 items were created:
Farm SCP <— serviceConnectionPoint
RegistrationServices <— Container
With the DDCs now published in Active Directory, proceed with logging onto your VDA with a domain account (local administrator won’t work) and run the Virtual Desktop Agent install. Once you get to the Controller Location menu, you should now be able to select the Select from Active Directory radio button to choose the DDCs you just published in AD:
Proceed with the install and once completed, navigate back to the following registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VirtualDesktopAgent
… and you’ll now see the following:
Notice how the ListOfDDCs registry string has not been replaced with FarmGUID:
If you’re wondering where this FarmGUID value comes from, you can find it here in the Configuration node of your Citrix Desktop Studio:
Fairly simple to do but as always, make sure you test the changes on a few desktop pools before you perform mass rollout.
No comments:
Post a Comment