There are a lot of questions about how-to register the VDA to the desired DDC or DDC’s. Citrix has its own Policies. And those policies are configurable in the Active Directory and in the Desktop Studio. Which is leading? And what are those settings? Must I use Active Directory Discovery (FarmGUID) or Registry Discovery (ListOfDDCs)?

 

The Setup:

My setup is simple:

  • 2x a XenDesktop Controller (XenDesktop and XenDesktop2);
  • 1x a Windows7 machine;
  • The XenDesktop Controllers are hosting there own XenDesktop farm.

The VDA Installation:

The VDA installation asks the controller location:

clip_image002[7]

  • Manually enter controller location;
    • This is know as the Registry Discovery. On the client there will be a list with the DDC’s;
  • Select from Active Directory;
    • This is know as the Active Directory Discovery. On the client there will be a FarmGUID. In the AD there is a relation between the FarmGUID and the DDC’s;
  • Configure at a later time;
    • This is most the most flexible way. On the client there is no list, or what so ever, with DDC’s to contact.

In all the examples below, I have chosen: Configure at a later time. So I have to do it manually.

 

Registry Discovery:

When Registry Discovery is used. The following registry key (Type RES_SZ) is added to the client:

  • 32Bit: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs
  • 64Bit: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfDDCs

The data in the key is the FQDN of the DDC’s to use. For instance:

  • XenDesktop.JeroenTielen.Local (Use the first DDC);
  • XenDesktop2.JeroenTielen.Local (Use the second DDC);
  • XenDesktop.JeroenTielen.Local XenDesktop2.JeroenTielen.Local (It will randomly select a DDC and uses another until a successful connection is established).

When this registry key is in place and the “Citrix Desktop Service” service is restarted, the Desktop is successful  registered.

clip_image004

To make this more dynamically/flexible. This key can be deployed by a Group Policy using Preferences.

clip_image006

This method is easy to implement. When a VDA is moved between Organizational Units the policy on the specific OU will instruct the VDA to the correct DDC.

Note: When a Citrix Policy is configured in the Desktop Studio, instructing the VDA to contact a specific DDC, this interfere with the GPO. This Citrix Policy is kept on the client. When changing OU/GPO this setting will always kicks in. Delete the file: “C:\Program Files\Citrix\Virtual Desktop Agent\Policy\FAMachinePolicyRules.xml” and reboot the VDA will solve the problem. When using a GPO for Registry discovery, don’t set a Citrix Policy in the Desktop Studio.

 

Active Directory Discovery:

To enable Active Directory Discovery you first need to start a PowerShell script on 1 DDC in the Farm. This script is located in the following directory: “C:\Program Files\Citrix\Broker\Service\Setup Scripts” and is named: “Set-ADControllerDiscovery.ps1”

In this example I’m going to use the same OU as where my computer accounts exists:

.\Set-ADControllerDiscovery.ps1  -on –existingOuDn “OU=Win7, OU=Test, DC=JeroenTielen, DC=local”

clip_image008

This will add DDC information into the specified OU. Within this information there is a group named: “Controllers”. All DDC’s computer accounts are placed into this group. Making it easy to change DDC’s. (Just add the correct DDC into the group.)

clip_image010

Before you continue, restart on all DDC’s the “Citrix Broker Service” service.

In the results of the PowerShell script, there is a line saying:

  • Important: You must make sure that your VDAs are using the correct OU (e.g. set  HKLM\SOFTWARE\Citrix\VirtualDesktopAgent\FarmGUID to “ID”).

The following registry key (Type RES_SZ) must be added to the client:

  • 32Bit: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\FarmGUID
  • 64Bit: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\VirtualDesktopAgent\FarmGUID

The data in the key is the “ID” found in the result of the PowerShell script. In my case:

  • 51C37CDF-3CA7-4237-B2A5-7803138DBC5C

clip_image012

When this registry key is in place and the “Citrix Desktop Service” service is restarted, the Desktop is successful registered.

To make this more dynamically/flexible. This key can be deployed by a Group Policy using Preferences.

clip_image014

This method is easy to implement. When a VDA is moved between Organizational Units the policy on the specific OU will instruct the VDA to the correct DDC.

Note: When a Citrix Policy is configured in the Desktop Studio, instructing the VDA to contact a specific DDC, this interfere with the GPO. This Citrix Policy is kept on the client. When changing OU/GPO this setting will always kicks in. Delete the file: “C:\Program Files\Citrix\Virtual Desktop Agent\Policy\FAMachinePolicyRules.xml” and reboot the VDA will solve the problem. When using a GPO for Active Directory discovery, don’t set a Citrix Policy in the Desktop Studio.

 

Citrix Active Directory Policy

If you install GPMC on a DDC or install Desktop Studio and GPMC on a management workstation. You can create a Citrix Policy direct on a specific OU. This will direct the VDA to register itself with the specified DDC’s.

clip_image016

This policy is only viewable on a machine where the desktop studio is installed.

clip_image018

Citrix Policy

Within the Citrix policies in the Desktop Studio. There is an option to configure the controller. This policy will overrule all settings above. But keep in mind. To apply this policy the VDA must first register with the DDC. So first you need to use some methods above and then a Citrix Policy to overrule that setting. Not ideal 😉

Hopefully this post will clear up any questions about howto register a VDA with a DDC or DDC’s.


5 Comments

Jeroen de R · January 23, 2014 at 16:27

Thanks for your great explanation. I solved a strange registration issue by removing FAMachinePolicyRules.xml. This was the fix for us!

Boris Groenhout · May 15, 2014 at 14:12

additionally ….

In Citrix XenDesktop 7.x there has been a change that DNS alias isn’t allowed anymore. See article http://support.citrix.com/article/CTX137960 for more information.
The CNAME lookups have been disabled to enforce a tighter security model in XenDesktop 7.

CNAME can be re-enabled by the following registry setting:

32-bit and 64-bit:

Registry Key: HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent
Name: UseCnameLookup
Type: REG_DWORD
Value: 1
(1 = enabled)

For a proper registration of the workplace the following registry setting has to be added to the client also:

32-bit:
Registry Key: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgent
Name: ListOfDDCs
Type: REG_SZ
Value: deliverycontrollerA deliverycontrollerB

64-bit:
Registry Key: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgent
Name: ListOfDDCs
Type: REG_SZ
Value: deliverycontrollerA deliverycontrollerB

After adjustment the registration in XenDesktop works fine 😉

In total my reg-file looks like:

Windows Registry Editor Version 5.00
; Fix to register VDA on XenDesktop 7.5
; http://support.citrix.com/article/CTX137960

[HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent]
“UseCnameLookup”=dword:00000001
“ListOfDDCs”=”deliverycontrollerA.domain.org deliverycontrollerA.domain.org”

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixVirtualDesktopAgent]
“UseCnameLookup”=dword:00000001
“ListOfDDCs”=”deliverycontrollerA.domain.org deliverycontrollerA.domain.org”

Remark:
On 64-bit environments in XenDesktop 5.6, the setting ListOfDDCs was needed in HKEY_LOCAL_MACHINESOFTWAREWow6432Node…

On 64-bit environments in XenDesktop 7.5, the setting ListOfDDCs and UseCnameLookup is only needed in HKEY_LOCAL_MACHINESOFTWARE…
The Wow6432Node supplement seems no longer to be necessary in a XenDesktop 7.5 environment. To be sure I add them under both.

Bonus:

Sometimes the logon to a XenDesktop 7.x published desktop may take long and a black screen may be visualized.
The causes are not very clear but article http://support.citrix.com/article/CTX135782 describes the steps required to modify a registry setting on a XenApp server that will help you reduce logon times. This setting is also useful in a XenDesktop environment.

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixLogon
Name: DisableStatus
Type: REG_DWORD
Value: 00000001

In total my reg-file looks like:

Windows Registry Editor Version 5.00
; Fix Slow logon and black screen on XenDesktop 7.x ; http://support.citrix.com/article/CTX135782

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixLogon]
“DisableStatus”=dword:00000001

Matin · October 28, 2014 at 10:23

Had the same problem!! Thank you very much, geat hint!

cubeover · May 22, 2016 at 05:56

One more way is to do it via GUI, when you only have few machines. Go to Programs and Features, select Citrix Virtual Delivery Agent 7.x, click Change. In the dialog that opens, choose Customize Delivery Agent Options, then type the Controller Address as FQDN, click Test. If tested OK, click Add. Click Next, choose port (80 or 443 depending on your VDC setup), then Reconfigure.
After reconfigure screen, be mindful of the “Restart machine” checkbox in the lower left. Otherwise, click Finish.
The best part is that you get to TEST it before you apply it.

Agen Tangkas88 · October 2, 2016 at 20:02

http://m11bola.com MAKELAR Taruhan Judi Online ATAU
MASTER Agen telak4d BOLA SBOBET ONLINE, CASINO 338A SBOBET ONLINE Terbesar Dan Terpercaya INDONESIA

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: