So you have your connection server freshly installed and need to get some basic configuration into it. There are a number of things we need to do before actually deploying desktops and applications and these are.
1/ Connect a vCenter server
2/ Configure View administrators
3/ Configure global policies
Connect a vCenter server
Initially we need to connect a vCenter server to the connection servers so we can deploy desktops utilising either full clones or linked clone technology. In order to do this you will need to do the following.
From the View administration console expand the View Configuration node on the left and click the Servers subnode.
Ensure you have the vCenter servers tab selected and click the Add button.
Enter the address for your vCenter server and also enter your vCenter service account details. You can also change the advanced settings if you wish to allow more concurrent options if your vCenter has been sized accordingly however to begin with I would leave those at the default settings. Click next, if you get a warning about the vCenter server certificate then click View Certificate and then click Accept (and smack yourself on the knuckles for not changing the default vCenter certificate).
Next you will be presented with the composer configuration screen which will allow the use of linked clones to create quicker and more storage efficiant desktops. If you have configured Composer you will have either installed it on its own server or more than likely installed it on the same server as vCentre. If you have not installed Composer you will not be able to utilise linked clones and must select do not use View Composer or go back a few steps and install composer ( Link HERE).
The next screen will allow composer to add newly created desktops into active directory so again a sufficient service account with at least create computer objects, delete computer objects and write all permissions will be required. Click the add button and specify the domain and account details you will use then click OK and finally Next(again because I’m doing this in a lab I’m using my administrator account).
The final screen for configuration is around disk space reclaimation and also storage acceleration. Storage acceleration utilises local storage on each host and copies commonly used blocks into the host which reduces the strain on centralised storage devices and minimises the impact of periods of high utilisation such as boot storms etc. The maximum size of the storage acceleration area is 2GB for each hosts, This is configurable per host so one host might have the full 2GB and another might only utilise 512MB (although in this day and age 2GB is such a nominal amount I would not expect to see this set at a lower amount in production). Disk space reclaimation is used to shrink disk files where for example a deleted file would have once been. By default both these options are ticked so generally just leave them at their defaults and click Next.
The final screen is the ready to complete screen where a summary of your configuration is displayed. Ensure that you are happy with the settings and click Finish.
Once the vCenter wizard has completed you will see your vCenter server listed with ticks by the items you have configured.
Configuring View Administrators
Configuring the correct level of access to the View admin area is critical to minimise downtime and unexpected events (you don’t want an over enthusiastic help desk bod accidentally deleting a pool). Helpfully View comes with quite a few administrative roles that will fit most requirements, if however they do not custom roles can be created to suit for needs. For this blog post I’m going to assign two roles to two different AD groups. Firstly a full admin group and then a read only group which will allow help desk to view the configuration and pools but will not allow them to change anything.
Firstly goto the View Configuration node and select Administrators.
Click Add User or Group and select Add again from the next screen. From within the Find User or Group window type the user/group name required into the Name/User name field and click Find. Then click the desired user or group and hit OK.
Your selection will now be displayed within the Add Administrator Or Permission box and click Next.
Now you must select a pre-defined role that the user or group will be a member of this will define what permissions the user or group will have over the View deployment. As I’ve selected domain admins I’ll select the Administrators Role which will allow full access to the environment.
Finally you will need to select the access group that the User/Group Role should have access too. An access group defines which desktop pool or application catalogue the user/group role will have that level of access too. By default the Root access group exists which allows access to all desktops and applications catalogues. In most cases the default Root access group will be sufficient so tick the root group and click Finish.
You will now be taken back to the View administration console where a summary of your administrators configuration will be displayed.
Configuring global policies
Policies can be defined per pool or application catalogue allowing for a different experienced based upon the use case for each pool. However its always a good idea to configure global policies which will apply when a desktop pool or app catalogue has no specific policies set. This ensures that each pool will have a similar experience unless purposefully changed at the desktop level.
Click on the Policies node and then select Global Policies, then click the Edit Policies button.
Set the policies accordingly such as the MMR policies which will specify if media with specific Microsoft codecs is passed directly down to the client for processing. This will result in less processing on the hosting side and a better media experience for the user. The USB access will dictate if USB devices attached to client devices will be passed through to the virtual desktop. This by default is set to allow but I would prefer to Deny this ability and allow it for certain pools which contain trusted or power users.
PCoIP hardware acceleration is utilised with compatible hardware acceleration card is present within the ESXi host (such as an APEX card) This policy is either allowed or denied and then a priority is set to define what level of graphics acceleration is required upon the desktops. This policy can be set per pool as well so if you have an acceleration card within a host you are likely to override this setting on a per pool basis.
Once you have configured these global policies click OK.
Once these items have been configured you will have all the basic infrastructure laid out and can begin to plan for the deployment of desktops and applications.
Author: Dale Scriven
