Horizon 8.0 Part 4: Active Directory Design Considerations

Traditionally, virtual desktops run Windows, and the servers that provide the virtual desktop infrastructure services also run on Windows.  Because of the heavy reliance on Windows, Active Directory plays a huge role in Horizon environments.  Even Linux desktops can be configured for Active Directory and utilize the Horizon user’s AD credentials for Single Sign-On.

When you’re planning a new Horizon deployment, or re-architecting an existing deployment, the design of your Active Directory environment is a critical element that needs to be considered.  How you organize your virtual desktops, templates, and security groups impacts Group Policy, helpdesk delegation rights, and Horizon Instant Clones and RDSH.

Some Active Directory objects need to be configured before any Horizon components are installed.  Some of these objects require special configuration either in Active Directory or inside vCenter.  The Active Directory objects that need to be set up are:

• An organizational unit structure for Horizon Desktops and desktop templates
• Basic Group Policy Objects for the different organizational units
• An organization unit for Microsoft RDS servers if published apps or RDSH-desktops are deployed
• In large environments with multiple sites and/or trusted domains, ensure that sites and services are set up properly to enable Horizon to properly locate domain controllers

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon desktop pools.  This can be useful for organizing those groups and/or delegating access to Help Desk or other staff who don’t need Account Operator or Domain Administrator rights.

Horizon and Active Directory

Before I talk about creating Organizational Unit structures and Group Policy, I want to start with Active Directory architecture and how Horizon utilizes Active Directory.  I recently wrote about that here, so I won’t go too deep into that topic.  But I will recap a few things to keep in mind.

Horizon utilizes the DCLocator function that is built into the Windows Server NetLogon process.  This process utilizes DNS to identify server locator records that correspond to the Active Directory site the server is located in.

Sites and Services need to be set up properly in multisite environments.  This means that you need to create sites in AD Sites and Services, ensure that your subnets are mapped to the proper sites, and create site links for your replication topology so that Horizon can locate the closest domain controllers.

There are additional considerations around site naming when working in a multi-forest environment where domains are connected by a trust.

To learn more about Horizon and Active Directory, please see my deep dive post on the topic here.

Creating an Organizational Unit Structure for Horizon Desktops

One of the first things that we need to plan and prepare before deploying desktops is an Active Directory organizational unit structure for Horizon desktops.  This OU structure will hold all of the desktops created and used by Horizon.

A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the Horizon Instant Clone Administrator service account.

Before I go into a method of organizing Active Directory, I want to make one thing clear.  There is no one way to organize Active Directory for Horizon.  These are guidelines that I like to follow because this organization makes sense to me.  These guidelines should be modified to fit your environment and your business and technical requirements.  There are a few things I highly recommend, though:

• A dedicated Organizational Unit tree for Virtual Deskops
• A dedicated Organizational Unit tree for RDSH Servers
• Creating new Group Policy Objects for virtual desktops and RDSH Servers instead of applying your standard desktop/server GPOs to these objects

My preferred organizational method looks like this:

View Desktops is a top-level OU (ie – one that sites in the root of the domain).  I like to set up this OU for two reasons.  One is that is completely segregates my VDI desktops from my non-VDI desktops and servers.  The other is that it gives me one place to apply group policy that should apply to all VDI desktops.

I create three child OUs under the View Desktops OU to separate persistent desktops, non-persistent desktops, and desktop templates.  This allows me to apply different group policies to the different types of desktops.  For instance, you may want to disable Windows Updates and use Dynamic Environment Manager on non-persistent desktops but allow Windows Updates on the desktop templates or Persistent Desktops.

You don’t need to create all three OUs.  If your environment consists entirely of Persistent desktops, you don’t need an OU for non-persistent desktops.  The opposite is true as well.  You may also choose to create more OUs depending on your organization.  For instance, you may create OUs based business groups, regions or geography, or other ways.

Finally, I tend to create use-case specific OUs for pools that require additional Group Policy options above and beyond the top-level. These grandchild OUs are completely optional.  If there is no need to set any custom policy for a specific use case, then they don’t need to be created.  However, if a grandchild OU is needed, then an entire pool will need to be created as desktop pools are assigned to OUs.  Adding additional pools can add management overhead to a VDI environment.

I’ve found that there is less of a need for these use-case specific OUs as I’ve learned more about modern UEM tools like Dynamic Environment Manager.  These tools can be a scalpel that allow administrators to dynamically apply context-aware policies and settings to specific users or groups without having to create additional pools or OUs for Group Policy configurations.

Creating an Organizational Unit for RDS Servers

RDSH servers need to be handled differently than virtual desktops.  They’re managed differently than your virtual desktops..

If application remoting or multi-user desktops are going to be deployed, an organizational unit for RDS servers should be created.  This can be a child OU of a server organizational unit, but it may not be the best place.

If full clone or manually provisioned RDSH servers are being used, you may want to consider creating a maintenance OU.  RDSH servers are often heavily locked down to block Windows Updates, software installers, and access to administrative tools and the command prompt through Group Policy.  A maintenance OU would be an OU where these policies are not enforced, allowing admins access to these tools after a reboot to perform maintenance tasks.

One key thing to keep in mind is that server GPOs can be restrictive in some organizations, and they may conflict with applications or process that run in the RDSH server.  If RDSH is new to your environment, it’s important that the security and server teams understand that even though these are virtual machines running a server OS, they are being used like desktops to run applications.  Less restrictive server policies may be required.

Horizon Group Policy Objects

Horizon contains a number of custom group policy objects that can be used for configuring the Horizon agent features and optimizing the PCoIP and Blast protocols. The templates are available in the Horizon Extras bundle on My VMware.

The templates are distributed in ADMX format, and they can be placed in the Group Policy Central Store.

Horizon Service Accounts

Horizon requires a service account for accessing vCenter to provision new virtual machines.  If Instant Clones are used, a second service account will be needed to create computer accounts in Active Directory for managing computer accounts for the clones.  I will cover setting up those account in a future section.

In the next section, I’ll cover SSL certificates for Horizon servers.