Summary This article describes how to configure XenDesktop 5.x successfully to work in a complex Active Directory Environment. Note: This article is an update to the Knowledge Center article CTX122417 - Using XenDesktop with Multiple Active Directory Forests, which was originally documented for XenDesktop 4 and amended to include some options for XenDesktop 5. For XenDesktop 7.1 and newer versions, see Deploy XenDesktop in a multiple forest Active Directory environment.

Requirements The minimum requirement for XenDesktop to work successfully with Active Directory (AD) is that the domain controllers must run on a server whose operating system is Windows Server 2003 or later. This does not affect the domain functional level, which can still be Windows 2000 native or higher. Windows Server 2003 interim domain functional levels are not supported. If Read Only Controllers are introduced, then at least one writeable domain controller running Windows Server 2008 or Windows Server 2008 R2 will be required and is in the same domain as the Read Only Domain Controller. The Read Only Domain Controllers must be on a Windows Server 2008 and the domain functional levels must be Windows 2003 or higher and the forest function level must be Windows Server 2003 or higher.

Background In a complex AD environment, the scenario would usually mean that the Desktop Delivery Controller (DDC) would be in a different Forest or domain to where the Virtual Desktop Agent (VDA) might reside. This could also be true for users who connect to these Virtual Machines, would be in a different forest or domain to where the DDC and VDA machines might reside. Following are the examples of environments, which are considered as complex AD environment:

Multiple Forests with two-way or one-way trusts

Multiple Forests with Selective trusts

Single Forest with multiple domains See Knowledge Center article CTX122417 - Using XenDesktop with Multiple Active Directory Forests, for explanation on why XenDesktop relies on AD. The following environments assume that XenDesktop 5.x is installed on all DDCs and VDAs. This article is based on the registry based Controller Discovery – this is the recommended method for multiple forest registration.

Helpful Notes

The Netbios and Fully Quality Domain Name (FQDN) can be different: Example - The Netbios name could be BOB but the FQDN could be parent1.local or the Netbios name and FQDN can be the same: Example – Netbios name is parent and the FQDN would be parent.local. Note: Dots in Netbios names are not recommend. Appropriate user access permissions are given for successful machine creation. In a cross-forest setup, use Delegation Control Wizard to keep permissions to a minimum use. Permission must be given for the DDC Administrator to create machines in a different forest in a specific Organizational Unit (OU). The following minimum permission can be given for successful machine creation:

1. Open Active Directory Users and Computers Microsoft Management Console (MMC).

2. Right-click on your OU and select Delegate Control. 3. On the first screen, click Next. 4. In the Users & Groups screen, click Add and pick a user or group you

want to delegate rights to and click Next. The best practice is to assign a group rather than a single user, as it is easier to manage and to audit.

5. In the Tasks to Delegate screen, select Create a custom task to delegate and click Next.

6. In the Active Directory Object Type screen, select Only the following objects in folder and select Computer objects.

7. Select Create selected objects in this folder and click Next.

8. In the Permissions screen, select General and then select Read and

Write. 9. Click Next.

10. Click Finish to complete the delegation control.

Different types of Active Directory Setups

1 Simple Single Domain Deployment

The following diagram illustrates a XenDesktop deployment in a single Active Directory domain, where the DDCs, VDAs, and the Users are all in the same domain.

In this Single domain setup, all relevant components and objects are based in one single domain. Registration of VDAs with the DDC should be successful and no additional configuration, that is, the registry key changes are required. Following is a list to check if VDA is unable to register with the DDC: 1. Check Event Viewer for errors on both the DDC and the VDA. 2. Ensure that the firewall is open for port 80 between the VDA and the DDC. 3. Check that the FQDN (Fully Qualified Domain Name) of the DDC is correct in

the registry setting of the VDA machine. On the VDA, check the following Reg Key: Caution! This procedure requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Back up the registry before you edit it. HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\ and confirm the parameter ListOfDDCs had the correct FQDN. If using 64-bit Virtual Machine, the VDA Reg Key is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfDDCs

4. Ensure that the DNS settings are correct on VDA and DDC, and both the

computers can resolve each other by DNS name and reverse lookups. Use the XDPing tool, downloadable from the Knowledge Center article CTX123278 - XDPing Tool to further troubleshoot.

5. Check that the Time is in sync between the VDA and DDC are correct. 6. For further troubleshooting, see Troubleshooting Virtual Desktop Agent

Registration with Controllers in XenDesktop.

2 Single Forest with Multiple Domains or Single Forest with Multiple Domains with shortcut trusts

The following two diagrams illustrate a XenDesktop deployment in a single forest with multiple domains and a Single Forest with multiple domains with shortcut trusts - where the DDC, VDA, and Users are all are based in different domains. The following is the illustration for Multiple Domains:

The following is an illustration for Multiple Domains with short cut trusts:

Multiple Domains: DDC, Users, and VDA are based in various domains, by default, a bidirectional transitive trust relationship exists between all domains in a forest. Multiple Domains with short cut trusts: DDC, Users, and VDA are based in various domains but at two-way shortcut, trust has been manually created between the DDC domain and the VDA domain. Typically, shortcut trusts are used in a complex forest where it can take time to traverse between all domains for authentication. By adding a shortcut trusts, it shortens the trust path to improve the speed of user authentication. For successful registration of the VDA with the DDC, the following<following what?? >should be configured correctly. DNS Forward/Reverse Lookup Zones are in place and configured on the relevant DNS servers. For further troubleshooting of VDAs not registering, see Following is a list to check if VDA is unable to register with the DDC: mentioned in the “Simple Single Deployment” section.

3 Multiple Forests with 2 way or 1 way trusts (external trusts or forest trusts)

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment. This is where the DDC is in a different Active Directory forest and the end users and desktops can be either in the same forest or in a separate Active Directory forest. Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.

The preceding illustration shows two separate Active Directory forest with a two-way forest trust. DDC and Users are in the same forest (parent.local) but the VDAs are located in different forest (parent2.local). For successful VDA registration with the DDC, the following must be configured correctly: DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address. See Managing a Forward Lookup Zone for information on managing Lookup Zones. On the Desktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests: HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\SupportMultipleForest (REG_DWORD)

To enable VDAs located in separate forests; this value must be present and set to 1. After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect. On the Virtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest. For a 32-bit VDA HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\SupportMultipleForest (REG_DWORD) For a 64-bit VDA HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\VirtualDesktopAgent\SupportMultipleForest (REG_DWORD) To enable support for DDCs located in a separate forest; this value must be present and set to 1. Note: The next step<which is the next step referring here??> is only required if External Trusts are only being used. You must also edit the <ProgramFiles>\Citrix\Virtual Desktop Agent\WorkstationAgent.exe.config file as follows: Note: In the next edition of XenDesktop, the WorkstationAgent.exe.config file will be replaced with BrokerAgent.exe.config file, change the BrokerAgent.exe.config to make the amendments as mentioned: 1. Backup this file. 2. Open the file in a text editor, such as Notepad. 3. Search for the line containing the text allowNtlm=”false” and change

allowNtlm=”false” to allowNtlm=”true” and then save the file. 4. After changing the SupportMultipleForest value and editing the configuration

file, you must restart the Citrix Desktop Service for the change to have an effect.

5. If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different Netbios name to that of the Active

Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.

For a 32-bit VDA: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs For a 64-bit VDA: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfSIDs

The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC. To obtain the correct domain SID of the DDC, the domain SID can be found by using a tool such as ADExplorer from sysinternals or by using the XDPing tool. Note: You must restart the Citrix Desktop Service for the changes to have an effect.

4 Multiple Forests with One-Way Selective trusts

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment using One-way Selective Trusts. The DDC is in a different Active Directory forest and the end users and existing VDAs (created either manually or through an alternative method) are in a separate Active Directory forest. In a one-way selective trust, automatic creation of Virtual Machines through DDC will fail, because of authentication issues. For this example, the Netbios and FQDN are different in each Forest and domain. Note: For One-Way Selective trusts, both Forests must be in Win2003 Forest Functional Level or above.

Selective authentication is used in environments where users are explicitly granted/ allowed to authenticate to servers and resources on the trusting domain. This method gives domain administrators control on what rights users can be given to access services on the trusting domain. See Enable Selective Authentication over a Forest Trust for more information on Selective trusts. Configure the following for successful registration of the VDA with the DDC: 1. DNS for name and reverse lookups.

Depending on the approach taken, the use of DNS Forwarders and Conditional forwarders, Forward /Reverse lookup zones, and Stub zones are all acceptable for name lookup/resolution.

2. Create the Selective trust on the relevant Domain Controllers. 3. Follow steps provided in the Multiple Forests with trusts (External trusts -

NTLM or Forest trusts – Kerberos) section. 4. The existing VDAs must be granted authentication access to the DDC, which

can be done through Active Directory Computer and Users snapin. Note: VDAs can be added to a group to make management easier (granting rights).

5. In Active Directory Computers and Users, browse to the location of the DDCs. 6. Right-click on DDC and click Properties.

7. Click the Security tab. 8. Click Add and then click Locations to change the domain to where the VDAs

reside. 9. Select all the relevant VDA or Group and click OK. 10. Select the VDA’s or Group and give the rights – Read and Allowed to

authenticate, as displayed in the following screen shot:

11. On the DDC, create an Existing Catalog and create a relevant Assignment.

When done, the Virtual Machines should show in a Ready State, as displayed in the following screen shot:

For further troubleshooting of VDA not registering, see “Following is a list to check if VDA is unable to register with the DDC:”.

More Information Understanding Delegated Administration http://technet.microsoft.com/en-us/library/cc778807(v=ws.10).aspx

Understanding Active Directory Domain Services (AD DS) Functional Levels http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx Understanding Active Directory Forest Trusts http://technet.microsoft.com/en-us/library/cc755700(v=ws.10).aspx Understand Active Directory Selective Trusts http://technet.microsoft.com/en-us/library/cc794747(v=WS.10).aspx Prerequisites for Deploying a Read Only Domain Controllers http://technet.microsoft.com/library/cc731243(WS.10).aspx When to create a shortcut trust http://technet.microsoft.com/en-us/library/cc737939(v=ws.10) Managing a Forward Lookup Zone http://technet.microsoft.com/en-us/library/cc816891(v=ws.10).aspx Download XDPing Tool CTX123278 - XDPing Tool Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop CTX126992 - Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop 5.x

Disclaimer This Web site might contain links to Web sites controlled by parties other than Citrix. Citrix is not responsible for and does not endorse or accept any responsibility for the contents or use of these third party Web sites. Citrix is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement by Citrix of the linked Web site. It is your responsibility to take precautions to ensure that whatever you select for your use is free of viruses or other items of a destructive nature.