Microsoft Active Directory is the backbone of almost every enterprise network. It is also a very complex system, and large, multi-site organizations can have incredibly complex environments that stretch across multiple Active Directory forests.

I was recently on a support escalation with one of our service provider partners. The escalation revolved around integrating Horizon into a complex Active Directory environment that involved multiple Active Directory forests connected over a trust. While both Horizon and Active Directory were working properly, the design of these particular Active Directory environments caused issues that manifested in Horizon and other applications.

Active Directory

Before talking about how Horizon utilizes Active Directory, I want to do a little level setting. I won’t go into a full overview of Active Directory. This is a very large topic that can, and has, fill books, and Microsoft has some very good documentation on their public documentation site.

One Active Directory design concept that is important for Horizon deployments, especially large deployments where resource forests may be used, is Sites. Active Directory Sites are part of the logical representation of the physical network. They map physical IP space to logical network locations, and they serve multiple purposes in an Active Directory environment. One key role that sites fill is helping clients locate the closest computer that is providing a service. This includes domain controllers.

Windows has a built-in process for locating domain controllers. This process is part of the NetLogon service. During startup, the computer’s NetLogon service detects the site that the computer is located in. The site name is stored in the registry. During logon, NetLogon will use the site name to query for DNS SRV records to locate the domain controller for that site. This process is outlined in this Microsoft blog post. It gets more complicated when you have multiple forests as the site lookup is based on the domain membership of the computer, not the user.

How Horizon Interacts with Active Directory

So what does this have to do with Horizon and how it interacts with Active Directory?

When you set up a new Horizon pod, you’re not required to do any Active Directory setup. The Horizon Connection Server services run in the context of the local system account, and they utilize built-in processes to identify the domain.

The Windows NetLogon service includes processes to retrieve information about the local Active Directory environment, and there are Win32 APIs to allow applications to trigger this process. Horizon utilizes these APIs to discover the local domain and any trusted domains. The Windows DC Locator process will identify the closest domain controller to the site, and any queries against the domain will be targeted to that domain controller using the system’s Active Directory account. (Note: Write Operations, such as creating computer accounts for Instant Clones, will use not use the computer account credentials.)

If the Connection Server is not able to determine the site that it is in, then it will use any domain controller that is returned when querying DNS, and the DC Locator process will continue to query for domain controllers on a regular basis.

When it comes to integrating with Active Directory, Horizon isn’t doing anything special. We’re just building on top of what Microsoft has in Windows Server.

Troubleshooting

If AD sites are not set up properly, you may see performance issues, especially in network scenarios where Horizon cannot reach the domain controller that DNS is pointing them to.

These issues can include Active Directory user and group search results taking a long time to return, issues with user authentication, and issues with computer accounts for provisioned machines. This may also impact user login experience and site-aware services like file shares fronted by DFS Namespaces. These issues are mainly seen in large Active Directory environments with many sites, or in environments with trusts between forests, where sites are not properly set up or maintained.

So how do you troubleshoot Horizon issues with Active Directory? This Microsoft blog post provides a good starting point. You will need to use NetLogon debugging and the nltest command line tool to see what Active Directory site your servers are a member of and what domain controllers are being resolved when the DC Locator process runs.

This can get a little more complicated in cloud deployments, large enterprises or service provider scenarios where resource forests are being used. Site names become very important in these scenarios as the computer will use the local domain site name when searching for domain controllers across trusts. Fixing Active Directory issues in these environments may require site topology changes.

Best Practices

Horizon utilizes native Windows features when integrating with Active Directory. It’s important to have a solid Active Directory architecture and site topology to ensure good performance and user experience. This means having sites defined and subnets assigned to the correct site.

A well-defined site topology becomes very important in environments where a resource forest, connected to the on-premises Active Directory environment with a trust, will be used as the site names must match in both Active Directory environments for the DC Locator process to work properly. Active Directory design needs to be a part of the Horizon design process to avoid issues after deployment.