First step we have to do to prepare Active Directory for an Horizon View deployment is to create a new organizational unit structure for all our virtual desktops. This new separate OU structure is important because you probably want to apply different group policies to your Horizon View desktops than your regular desktops. There are also specific permissions that you will need to delegate to the View Composer service account.
There’re a lot of ways that you can set up an Active Directory OU structure for Horizon View. One structure I recently created for a customer is the following:
View is just a top-level OU. I prefer to setup this OU for two reasons: first, this completely segregates my virtual desktops from my physical desktops and servers. Second, it gives me one place to apply group policy that should apply to all View desktops (such as disabling non-essential services, turning off screen savers, etc).
I also created three child OUs under the View Desktops OU: t his 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.
Horizon View Group Policy Objects
Horizon View contains a number of custom group policy objects that can be used for configuring features like Persona Management and optimizing the PCoIP protocol. The number of Group Policy objects has been increased in Horizon View 6, and the number of templates has increased as well.
Most of the Group Policy templates are available as ADM files. There are a number of drawbacks to ADM files in modern AD environments. The main one is that you cannot store the Group Policy files in the Central Store. If you plan on using the Group Policy templates, it’s a good idea to convert them into the ADMX format.
The first service account we will create is the one used by View to access the vCenter. Horizon View uses this account for provisioning and power operations. The service account should be a standard Active Directory domain user account without any additional administrator-level rights on the domain or on the vCenter server.
Since we will use View Composer, I will set up the vCenter Service Account with the permissions required to use View Composer.
Note: If you are not using View Composer different permissions will be required in vCenter. Refer to Horizon View 6.0 Installation Guide for more details on the permissions that need to be assigned to the service account.
In order to assign the appropriate permissions, we need to create a new role in vCenter. To create a new role in the vCenter Web Client, go to Administration –> Roles. Then click on the green plus sign.
The permissions that need to be assigned to our new role are the following:
Low Level File Operations
|Virtual Machine||Configuration –> All Items
Inventory –> All Items
Snapshot Management –> All Items
Read Customization Spec
Clone Virtual Machine
Allow Disk Access
|Resource||Assign Virtual Machine to Resource Pool
Migrate Powered-Off Virtual Machine
Act As vCenter *
Advanced Settings *
* Act as vCenter and Host Advanced Settings are only needed if View Storage Accelerator are used.
Now ,we need to assign permissions for our service account to the vCenter root. To do this, go 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.
The second account we are going to setup will be used by View Composer. This account can be created as a standard domain user. This account should not have domain administrator, it only needs a set of permissions on the OU (or OUs) where the View Desktops are being stored. If you use the structure like the one I previously described, you only need to delegate permissions on the top-level OU and permission inheritance, if turned on, will apply them to any child 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 these:
- Create Computer Objects
- Delete Computer Objects
- Write All Properties
- Reset Password
The account will also need to be granted local administrator rights on the Composer server. If the account is not a local administrator, you will not be able to configure Composer from within the View Administrator.