The only desktops that are supported for virtual desktops in Horizon View 5.3 are Windows-based. This includes the latest versions of the Windows Desktop operating system and Windows Server running Windows Terminal Server or as a desktop. Because Windows desktops are the core of Horizon View, Active Directory is used to handle authentication into the View environment.
As I mentioned in my last post, an Active Directory environment is a requirement. Per the documentation, Server 2003 and Server 2008/R2 Active Directory environments are supported. The documentation doesn’t go into any details as to whether Windows Server 2012 domain controllers are unsupported or if the Server 2012 domain and forest functional levels are unsupported.
Edit 3/26/2014: VMware has updated the release notes for Horizon View 5.3 to clarify support, and the 2012 Domain/Forest functional levels are not supported. 2012 domain controllers are supported. h/t rboyett
Some Active Directory objects need to be configured before any Horizon View 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 View Desktops
- A service account for View Composer
- A service account that View will use to access vCenter
Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon View 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.
Creating An Organizational Unit for Horizon View Desktops
The first think that we need to do to prepare Active Directory for a Horizon View deployment is to create an organizational unit structure for Horizon View desktops. This OU structure will hold all of the desktops created and used by Horizon View. A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon View desktops than you would your regular desktops. There are also specific permissions that you will need to delegate to the View Composer service account.
There are a lot of ways that you can set up an Active Directory OU structure for Horizon View. 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 such as disabling non-essential services, turning off screen savers, or setting the inactivity timeout to lock the machine.
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 Persona Management on non-persistent desktops but allow Windows Updates on the desktop templates.
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.
Finally, I tend to create department or location OUs underneath the persistent or non-persistent OUs if I have locations that require special Group Policy settings in addition to the default settings. One example where I used this was in a previous job that HEAVILY used Microsoft Access databases at one site. Microsoft Access includes a security groups option that uses a centrally stored database file to manage access to databases. This can be configured with group policy, and since other locations used Access without the security groups configured, applying that policy to all desktops would have broken any Access databases that the other locations used.
These grandchild OUs are completely optional. If there is no need to set any custom policy for a location or a department, 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.
Creating a View Composer Service Account
There are two service accounts that need to be created in Active Directory to support a Horizon View deployment. The first is the account that will be used by View Composer. This account can be created as a standard domain user. This account should not have domain administrator or account operator rights – it only needs a select group of permissions on the OU (or OUs) where the View Desktops are being stored.
After this account has been created, you need to delegate permissions to it on the OU (or OUs) where your VDI desktops will be placed. If you use the structure like the one I outlined above, you only need to delegate permissions on the top-level OU and permission inheritance, if turned on, will apply them to any child or grandchild objects beneath it.
Note: If inheritance is not turned on, you will need to check the Apply to All Child Objects checkbox before applying the permissions.
The permissions that need to be delegated on the OU are:
- Create Computer Objects
- Delete Computer Objects
- Write All Properties
- Reset Password
Note: Although granting this account Domain Administrator or Account Operator permissions may seem like an easy way to grant it the permissions it needs, it will grant a number of other permissions that are not needed and could pose a security risk if that account is compromised. Only the required permissions should be granted in a production environment.
Creating a vCenter Server Service Account
The second Active Directory account that needs to be created is a service account that will be used by Horizon View to access vCenter. Because Horizon View has a number of different configurations, the actual rights required by vCenter will vary. I will be using View Composer in this series, so I will be setting up the vCenter Service Account with the permissions required to use View Composer.
Note: If you are not using View Composer, or you plan to use View Composer and Local Mode, different permissions will be required in vCenter. Please see Chapter 8 of the Horizon View 5.2 Installation Guide for more details on the permissions that need to be assigned to the service account.
The user account that is created for accessing vCenter Server should be a standard domain user account. Unlike the View Composer, it shouldn’t have any rights to administer objects in the domain as the permissions that this account needs will be assigned within vCenter.
To create a new role in the vCenter Web Client, you need to go to Administration –> Roles from the main page. This will bring up the roles page, and we can create a new role from here by clicking on the green plus sign.
The permissions that need to be assigned to our new role are:
Edit June 16th, 2014 – The Datastore permissions were missing from the list of permissions needed for the vCenter Service Account. They have now been added in.
|
Privilege Group |
Privilege |
| Datastore | Allocate Space Browse Datastore Low Level File Operations |
| Folder | Create Folder Delete Folder |
| Virtual Machine | Configuration –> All Items Inventory –> All Items Snapshot Management Note 2–> All Items Interaction: Power On Power Off Reset Suspend Provisioning: Customizing Deploy Template Read Customization Spec Clone Virtual Machine Allow Disk Access |
| Resource | Assign Virtual Machine to Resource Pool Migrate Powered-Off Virtual Machine |
| Global | Enable Methods Disable Methods System Tag Act As vCenter Note 1 |
| Network | All |
| Host | Configuration: Advanced Settings Note 1 |
Note 1: Act as vCenter and Host Advanced Settings are only needed if View Storage Accelerator are used. If these features are not used, these permissions are not required.
Note 2: The documentation says to grant all permissions to State under virtual machine. However, in vCenter 5.1 and later, there does not appear to be an item called State. The state item existed in earlier versions of vCenter and was renamed to Snapshot Management. For more information, please see this post by Terence Luk.
After the role has been created, we will need to assign permissions for our vCenter Server service account to the vCenter root. To do this from the roles screen, you will need to go back to the vCenter Web Client Home screen and take the following steps:
- Select vCenter
- Select vCenter Servers under Inventory Lists
- Select the vCenter that you wish to grant permissions on
- Click on the Manage Tab
- Click Permissions
- Click the Green Plus Sign to add a new permission
- Select the role for View Composer
- Add the Domain User who should be assigned the role
- Click OK.
This wraps up the preparation work for configuring Active Directory and vCenter to support a Horizon View deployment. Now we can start installing the components for a Horizon View environment beginning with View Composer.
The Virtual Horizon 
You must be logged in to post a comment.