Now that the Connection Server and View Composer are installed, it’s time to configure the components to actually work together with vCenter to provision and manage desktop pools.

Logging into View Administrator

Before anything can be configured, though, we need to first log into Horizon View Administrator.  As I mentioned above, you will need to have Adobe Flash installed and enabled in your web browser.

The web browsers that VMware supports are:

• Internet Explorer 8 or later (on Windows 8, IE is only supported in Desktop Mode)
• FIrefox 6 or later

Although it is not officially supported, I have never had an issue with View Administrator when using Google Chrome.

To log in, take the following steps:

1. Open your web browser.

2. Navigate to https://<FQDN of connection server>/admin

3. Log in with the Administrator Account you designated (or with an account that is a member of the administrator group you selected) when you installed the Connection Server.

4. After you log in, you will be prompted for a View License key.

Note:  The license keys are retrieved from your MyVMware site.  If you do not input a license key, you will not be able to connect to View Desktops after they are provisioned.  You can add or change a license key later under View Configuration –> Product Licensing and Usage.

5. Click Edit License.  Paste your license key from the MyVMware site into the license key box and click OK.

6. After your license key is installed, the Licensing area will show when your license expires and the features that are licensed in your deployment.

Configuring View for the First Time

Once you’ve logged in and configured your license, you can start setting up the Horizon View environment.  In this step, the Connection Server will be configured to talk to vCenter and View Composer.

1.   Expand View Configuration and select Servers.

2.  Select the vCenter Servers tab and select Add…

3, Enter your vCenter server information.  The service account that you use in this section should be the vCenter Service Account that you created in Part 6.

Note: If you are using vCenter 5.5 or later, the username should be entered in User Principal Name format – username@fqdn.

4. If you have not updated the certificates on your vCenter Server, you will receive an Invalid Certificate Warning.  Click View Certificate to view and accept the certificate.

5.  Select the View Composer option that you plan to use with this vCenter.  The options are:

A. Do not use View Composer – View Composer and Linked Clones will not be available for desktop pools that use this vCenter.

B. View Composer is co-installed with vCenter Server – View Composer is installed on the vCenter Server, and the vCenter Server credentials entered on the previous screen will be used for connecting.  This option is only available with the Windows vCenter Server.

C. Standalone View Composer Server – View Composer is installed on a standalone Windows Server, and credentials will be required to connect to the Composer instance.  This option will work with both the Windows vCenter Server and the vCenter Server virtual appliance.

Note: The account credentials used to connect to the View Composer server must have local administrator rights on the machine where Composer is installed.  If they account does not have local administrator rights, you will get an error that you cannot connect.

6. If Composer is using an untrusted SSL certificate, you will receive a prompt that the certificate is invalid.  Click View Certificate and then accept.

For more information on installing a trusted certificate on your Composer server, please see Part 5.

7. The next step is to set up the Active Directory domains that Composer will connect to when provisioning desktops.  Click Add to add a new domain.

8. Enter the domain name, user account with rights to Active Directory, and the password and click OK.  The user account used for this step should be the account that was set up in Part 6.

Once all the domains have been added, click Next to continue.

9. The next step is to configure the advanced storage settings used by Horizon.  The two options to select on this screen are:

• Reclaim VM Disk Space – Allows Horizon to reclaim disk space allocated to linked-clone virtual machines.
• Enable View Storage Accelerator – View Storage Accelerator is a RAMDISK cache that can be used to offload some storage requests to the local system.  Regenerating the cache can impact IO operations on the storage array, and maintenance blackout windows can be configured to avoid a long train of witnesses.  The max cache size is 2GB.

After you have made your selections, click Next to continue.

10. Review the settings and click finish.

Configuring the Horizon View Events Database

The last thing that we need to configure is the Horizon View Events Database.  As the name implies, the Events Database is a repository for events that happen with the View environment.  Some examples of events that are recorded include logon and logoff activity and Composer errors.

Part 6 described the steps for creating the database and the database user account.

1. In the View Configuration section, select Event Configuration.

2. In the Event Database section, click Edit.

3. Enter the following information to set up the connection:

• Database Server (if not installed to the default instance, enter as servername\instance)
• Database Type
• Port
• Database name
• Username
• Password
• Table Prefix (not needed unless you have multiple Connection Server environments that use the same events database – IE large “pod” environments)

Note: The only SQL Server instance that uses port 1433 is the default instance.  Named instances use dynamic port assignment that assigns a random port number to the service upon startup.  If the Events database is installed to a named instance, it will need to have a static port number.  You can set up SQL Server to listen on a static port by using this TechNet article.  For the above example, I assigned the port 1433 to the Composer instance since I will not have a named instance on that server.

If you do not configure a static port assignment and try to connect to a named instance on port 1433, you may receive the error below.

5. If setup is successful, you should see a screen similar to the one below.  At this point, you can change your event retention settings by editing the event settings.

Lsat weekend, I upgraded my Horizon View environment to Horizon 6.0.1.  I wanted to do this upgrade to take a look at the expanded printing support that VMware added in this minor release.

The major improvement included in the Horizon 6.0.1 release is support for virtual printing and location-based printing for Windows Server 2008 R2-based desktops and RDSH-hosted published applications. 

The upgrade isn’t too difficult, and prior to starting it, you should review the compatibility matrix and read the release notes and the directions for patching Horizon 6.

My home lab environment were I performed the upgrade only has one Connection Server and one Security Server.  The steps may be different if you have multiple Connection and Security Servers.

Prerequisites

Horizon 6.0.1 has all of the same prerequisites as Horizon 6.0 as well as support for vSphere 5.5 Update 2.

Upgrade Order

The order for upgrading the Horizon components is:

1. Composer
2. Connection Servers
3. Security Servers
4. Agents
5. Clients

Prior to upgrading the Horizon server-side components, you should take a snapshot of the server and perform a database backup.

Upgrading Horizon Composer

The first component that needs to be upgraded is Composer.  Prior to upgrading Composer, you will need to take a snapshot of the server and do a database backup.

The upgrade is essentially installing the new version over the old version.  During the upgrade process, you will be prompted for the name of the ODBC DSN connection, database username, and password that were used during the first install.  If you’re using a custom SSL certificate, you’ll need to select it when asked about certificates.

Upgrading the Horizon Connection Server

Once Composer has been upgraded, the next component that needs to be upgraded is the Connection Server.  The steps for this upgrade are fairly simple.

1. Snapshot the Connection Server
2. Run the Installer
3. Click next all the way through to complete the upgrade

Although it is not required, I prefer to reboot the server after the upgrade completes.

Upgrading the Horizon Security Server

The documentation doesn’t mention much about patching Security Servers, so I treated it the same as doing an upgrade.  The process for upgrading a Security Server are much more involved than the process for upgrading a Connection Server, and there are a few extra steps that need to be taken to successfully complete the upgrade. 

Prior to upgrading Horizon, you will need to log into log into View Administrator and complete two tasks in the server section.  The first task is to set a pairing password that will be used when pairing the Security Server to a Connection Server.  The installer will ask for one when you do the upgrade.  This can be set under View Configuration –> Servers –> Connection Servers by highlighting the Connection Server that the Security Server is paired with and selecting More Commands –> Specify Security Server Pairing Password.

The other task that needs to be done before the upgrade is installed is to reset the IPSEC tunneling information.  VMware recommends using IPSEC for all communications between the Connection Server and Security Server.  The IPSEC security settings can be reset by going to View Configuration –> Servers –> Security Servers , selecting the Security Server, and going to More Commands –> Prepare to Upgrade or Reinstallation…

Once you’ve completed these two steps, you will need to log into the Security Server and run the installation package.  When you run the installer, you will be asked for the Connection Server that you’re pairing with and the pairing password.  You will also need to reconfirm the URLs and IPs that the security server uses.  You do not need to remove the existing Security Server before installing the upgrade – you can install it right on top of the existing Security Server instance.

Although it is not required, I prefer to reboot the server after the upgrade completes.

Horizon Agent Upgrade

Once all the server components have been upgraded, the Horizon Agent will need to be upgraded on all full clone desktops and templates, linked clone master images, and RDS servers. 

If you plan to do an upgrade of your ESXi hosts, there is a preferred upgrade order for VMware Tools and the Horizon Agent.  VMware Tools should be upgraded before the Horizon Agent.  If it is not done in that order, the VMware tools install will replace some drivers that the Horizon Agent installs, and you will have to reinstall or repair the Horizon Agent.

Horizon Client

The Horizon Client is usually the last item that gets updated in the environment.  The latest client should be downloaded from the VMware site or from the mobile device app store.

Clients aren’t necessarily tied to a specific version of Horizon.  The latest client can usually be used with an older version of Horizon.  The reverse isn’t always true, and improvements to the PCoIP protocol or other features may not be available when using an older client after an upgrade.

Connection Servers are one of the most important components in a Horizon View environment.  Connection Servers come in three flavors – the standard Connection Server, the Replica Connection Server, and the Security Server – and handle multiple roles including user Authentication against Active Directory, pool management and brokering connections desktops, terminal servers, and applications.

There is almost no difference between the standard Connection Server and a Replica Connection Server.  The Standard and Replica Connection Servers have the same feature set.  The only difference between the two is that the standard connection server is the first server in the pod.

The Security Server is a stripped down version of the regular Connection Server.  It is designed to operate in a DMZ network and tunnel connections back to the Connection server, and it must be paired with a specific Connection Server in order for the installation to complete successfully.  I’ll cover the process of setting up a Security Server in another post.

Installing the First Connection Server

Before you can begin installing the Horizon View, you will need to have a server prepared that meets the minimum requirements for the Horizon View Connection Server instance.  The basic requirements, which are described in Part 2, are a server running Windows Server 2008 R2 or Server 2012 R2 with 2 CPUs and at least 4GB of RAM.

Note:  If you are going have more than 50 virtual desktop sessions on a Connection Server, it should be provisioned with 10GB of RAM.

Once the server is provisioned, and the Connection Server installer has been copied over, the steps for configuring the first Connection Server are:

1. Launch the Connection Server installation wizard by double-clicking on VMware-viewconnectionserver-x86_64-6.x.x-xxxxxxx.exe.

2. Click Next on the first screen to continue.

3.  Accept the license agreement and click Next to continue.

4.  If required, change the location where the Connection Server files will be installed and click Next.

5. Select the type of Connection Server that you’ll be installing.  For this section, we’ll select the View Standard Server.  If you plan on using Horizon View Blast to access desktops, select “Install HTML Access.”  Click Next to continue.

6. Enter a strong password for data recovery.  This will be used if you need to restore the Connection Server’s LDAP database from backup.  Make sure you store this password in a secure place.  You can also enter a password reminder or hint, but this is not required.

7. Horizon View requires a number of ports to be opened on the local Windows Server firewall, and the installer will prompt you to configure these ports as part of the installation.  Select the “Configure Windows Firewall Automatically” to have this done as part of the installation.

Note: Disabling the Windows Firewall is not recommended.  If you plan to use Security Servers to provide remote access, the Windows Firewall must be enabled on the Connection Servers to use IPSEC to secure communications between the Connection Server and the Security Server.

8. The installer will prompt you to select the default Horizon View environment administrator.  The options that can be selected are the local server Administrator group, which will grant administrator privileges to all local admins on the server, or to select a specific domain user or group.  The option you select will depend on your environment, your security policies, and/or other requirements.

If you plan to use a specific domain user or group, select the “Authorize a specific domain user or domain group” option and enter the user or group name in the “domainname\usergroupname” format.

Note: If you plan to use a custom domain group as the default Horizon View administrator group, make sure you create it and allow it to replicate before you start the installation. 

9.  Chose whether you want to participate in the User Experience Improvement program.  If you do not wish to participate, just click Next to continue.

10. Click Install to begin the installation.

11. The installer will install and configure the application and any additional windows roles or features that are needed to support Horizon View. 

12. Once the install completes, click Finish.  You may be prompted to reboot the server after the installation completes.

Now that the Connection Server and Composer are installed, it’s time to begin configuring the Horizon View application so the Connection Server can talk to both vCenter and Composer as well as setting up any required license keys and the events database.  Those steps will be covered in Part 9.

Back in Part 4, I mentioned that Horizon View required up to a few service accounts to function properly.  One of these accounts is for accessing vCenter to provision and manage the virtual machines that users will connect to.  The other service account is for View Composer and will manage the accounts within Active Directory.  This account is not required if you are not planning to use View Composer and Linked Clones within your environment.

In addition to these two service accounts, two database accounts may need to be created for the Horizon View Composer database and the Horizon View Events Database.

It’s important to build these accounts with the principle of least privileged access in mind.  These accounts should not have more rights than they would need.  So while the easy way out would be to give these accounts vCenter Administrator, Domain Administrator, and SQL Server or Oracle SysAdmin rights, it would not be a good idea as these accounts could potentially be compromised.

vCenter Service Account

The first account that needs to be created is a service account that View will use for accessing 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.

There are a couple of different ways to configure your Horizon View environment, sp 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 x of the Horizon View 6.0  Installation Guide for more details on the permissions that need to be assigned to the service account.

A new role will need to be created within vCenter in order to assign the appropriate permissions.  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:

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.

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:

1. Select vCenter
2. Select vCenter Servers under Inventory Lists
3. Select the vCenter that you wish to grant permissions on
4. Click on the Manage Tab
5. Click Permissions
6. Click the Green Plus Sign to add a new permission
7. Select the role for View Composer
8. Add the Domain User who should be assigned the role
9. Click OK.

View Events Database Account

The Events Database is a repository for events that happen with the View environment.  Some examples of events that are recorded include logon and logoff activity and Composer errors.

The Events Database requires a Microsoft SQL Server or Oracle database server, and it should be installed on an existing production database server.  There are two parts to configuring the events database.  The first part, creating the database and the database user, needs to be done in SQL Server Management Studio before the event database can be configured in View Administrator.  The steps for configuring Horizon View to use the Events database will happen in another post.

To set up the database, follow these steps:

1. Open SQL Server Management Studio and log in with an account that has permissions to create users and databases.

2. Expand Security –> Logins.

3. Right-click on Logins and Select New Login…

4. Enter the SQL Login Name and Password and then click OK.

5. Expand Databases.

6. Right-click on Databases and select New Database.

7. Enter the database name.  Select the database user that you created above as the database owner.  Click OK to create the database.

Note: SQL Server named instances are configured to use dynamic ports.  This means that SQL Server will use a new port every time the server is restarted.  The events database does not support dynamic ports, so a static port will need to be configured and the SQL instance restarted prior to configuring the events database in View.  For instructions on how to configure a static ports in SQL Server, please see this article.

View Composer Service Accounts

The last two accounts that need to be set up are for Horizon View Composer.  These accounts are only required if you plan on using Composer and linked clone desktops.

Depending on your configuration, Composer may require two service accounts.  These accounts are:

1. An Active Directory User Account – This service account is used by View for accessing Composer.  This account requires local administrator rights on the Composer server and rights to create computer objects in Active Directory.

2. A Horizon View Composer Database User – This service account is a local SQL Server user account and is required if the SQL Server database is located on a remote server.  If SQL Server is installed on the Composer Server, Windows authentication can be used.

Configuring the Composer Service Account

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.

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.

Configuring the Composer Database and Database Service Account

Like the Event database above, Composer requires its own database.  This database is used to keep track of linked clones, replicas, and pending recompose operations.

The steps below will walk through setting up the Composer database.  If your Composer database is located on a separate server, you will have to use SQL authentication, and the steps for creating the SQL user are included.

Note: If your Composer database is located on the same server as the Composer service, you can use Windows Authentication for accessing the database.

1. Log into your database server and open SQL Server Management Studio.

2. Log in as a user with administrator rights on SQL Server.

3. Create a new SQL Login by expanding Security –> Logins.  Right click on Logins and select New Login.

4. Enter a login name such as viewComposerDB or viewComposerUser, select SQL Server Authentication, and enter a password twice.  You may also need to disable Enforce Password Expiration or Enforce Password Policy depending on your environment.  Click OK to create the account.  Note: Check with your DBA on password policy settings.

5. After the SQL login is created, you need to create an empty database.  To create the database, right click on the database folder and select New Database.

6. In the database name field, enter a name such as viewComposer.  This will be the name of the database.  To select an owner for the database, click on the … button and search for the database user account you created above.  Click OK to create the database.

You will have a blank database that you can use for View Composer after you click OK.

Configuring Composer to use this database will be covered during the Composer installation.

This wraps up all of the prerequisites for the environment.  In the next couple of sections, I will be covering the installation and configuration of Horizon View.

SSL certificates are an important part of all Horizon View environments .  They’re used to secure communications from client to server as well as between the various servers in the environment.  Improperly configured or maintained certificate authorities can bring an environment to it’s knees – if a connection server cannot verify the authenticity of a certificate – such as an expired revocation list from an offline root CA, it will stop any communications with the impacted host.

If you read my previous series on View 5.3, the post about SSL certificates was the last regular post in the series, and it came after the other components were installed and configured.  In an production environment, you would most likely install the SSL certificates before installing the Horizon View components.

Most of the certificates that you will need for your environment will need to be minted off of an internal certificate authority.  If you are using a security server to provide external access, you will need to acquire a certificate from a public certificate authority.  If you’re building a test lab or don’t have the budget for a valid certificate, you can use a free certificate authority such as StartSSL.

Prerequisites

Before you can begin creating certificates for your environment, you will need to have a certificate authority infrastructure set up.  Microsoft has a great 2-Tier PKI walkthrough on TechNet. 

Note: If you use the walkthrough to set up your PKI environment., you will need to alter the configuration file to remove the  AlternateSignatureAlgorithm=1 line.  This feature does not appear to be supported on vCenter  and can cause errors when importing certificates.

Once your environment is set up, you will want to create a template for all certificates used by VMware products.  Derek Seaman has a good walkthrough on creating a custom VMware certificate template.

Note: Although a custom template isn’t required, I like to create one per Derek’s instructions so all VMware products are using the same template.

Creating The Certificate Request

Horizon View 6.0 handles certificates the same way as Horizon View 5.3.  Certificates are stored in the Windows certificate store, so the best way of generating certificate requests is to use the certreq.exe certificate tool.  This tool can also be used to submit the request to a local certificate authority and accept and install a certificate after it has been issued.

Certreq.exe can use a custom INF file to create the certificate request.  This INF file contains all of the parameters that the certificate request requires, including the subject, the certificate’s friendly name, if the private key can be exported, and any subject alternate names that the certificate requires.

If you plan to use Subject Alternate Names on your certificates, I highly recommend reviewing this article from Microsoft.  It goes over how to create a certificate request file for SAN certificates.

A  certificate request inf file that you can use as a template is below.  To use this template, copy and save the text below into a text file, change the file to match your environment, and save it as a .inf file.

;----------------- request.inf -----------------
[Version]

Signature="$Windows NT$"

[NewRequest]

Subject = "CN=<Server Name>, OU=<Department>, O=<Company>, L=<City>, S=<State>, C=<Country>" ; replace attribues in this line using example below
KeySpec = 1
KeyLength = 2048
; Can be 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
FriendlyName = "vdm"
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

[Extensions]

2.5.29.17 = "{text}"
_continue_ = "dns=<DNS Short Name>&"
_continue_ = "dns=<Server FQDN>&"
_continue_ = "dns=<Alternate DNS Name>&"

[RequestAttributes]

CertificateTemplate = VMware-SSL

;-----------------------------------------------

Note: When creating a certificate, the state or province should not be abbreviated.  For instance, if you are in Wisconsin, the full state names should be used in place of the 2 letter state postal abbreviation.

Note:  Country names should be abbreviated using the ISO 3166 2-character country codes.

The command the generate the certificate request is:

certreq.exe –New <request.inf> <certificaterequest.req>

Submitting the Certificate Request

Once you have a certificate request, it needs to be submitted to the certificate authority.  The process for doing this can vary greatly depending on the environment and/or the third-party certificate provider that you use. 

If your environment allows it, you can use the certreq.exe tool to submit the request and retrieve the newly minted certificate.  The command for doing this is:

certreq –submit -config “<ServerName\CAName>” “<CertificateRequest.req>” “<CertificateResponse.cer>“

If you use this method to submit a certificate, you will need to know the server name and the CA’s canonical name in order to submit the certificate request.

Accepting the Certificate

Once the certificate has been generated, it needs to be imported into the server.  The import command is:

certreq.exe –accept “<CertificateResponse.cer>“

This will import the generated certificate into the Windows Certificate Store.

Using the Certificates

Now that we have these freshly minted certificates, we need to put them to work in the View environment.  There are a couple of ways to go about doing this.

1. If you haven’t installed the Horizon View components on the server yet, you will get the option to select your certificate during the installation process.  You don’t need to do anything special to set the certificate up.

2. If you have installed the Horizon View components, and you are using a self-signed certificate or a certificate signed from a different CA, you will need to change the friendly name of the old certificate and restart the Connection Server or Security Server services.

Horizon View requires the certificate to have a friendly name value of vdm.  The template that is posted above sets the friendly name of the new certificate to vdm automatically, but this will conflict with any existing certificates. 

Friendly Name

The steps for changing the friendly name are:

1. Go to Start –> Run and enter MMC.exe
2. Go to File –> Add/Remove Snap-in
3. Select Certificates and click Add
4. Select Computer Account and click Finish
5. Click OK
6. Right click on the old certificate and select Properties
7. On the General tab, delete the value in the Friendly Name field, or change it to vdm_old
8. Click OK
9. Restart the View service on the server

Certificates and Horizon View Composer

Unfortunately, Horizon View Composer uses a different method of managing certificates.  Although the certificates are still stored in the Windows Certificate store, the process of replacing Composer certificates is a little more involved than just changing the friendly name.

The process for replacing or updating the Composer certificate requires a command prompt and the SVIConfig tool.  SVIConfig is the Composer command line tool.  If you’ve ever had to remove a missing or damaged desktop from your View environment, you’ve used this tool.

The process for replacing the Composer certificate is:

1. Open a command prompt as Administrator on the Composer server
2. Change directory to your VMware View Composer installation directory
   Note: The default installation directory is C:\Program Files (x86)\VMware\VMware View Composer
3. Run the following command: sviconfig.exe –operation=replacecertificate –delete=false
4. Select the correct certificate from the list of certificates in the Windows Certificate Store
5. Restart the Composer Service

A Successful certificate swap

At this point, all of your certificates should be installed.  If you open up the View Administrator web page, the dashboard should have all green lights.  If you do not see all green lights, you may need to check the health of your certificate environment to ensure that the Horizon View servers can check the validity of all certificates and that a CRL hasn’t expired.

If you are using a certificate signed on an internal CA for servers that your end users connect to, you will need to deploy your root and intermediate certificates to each computer.  This can be done through Group Policy for Windows computers or by publishing the certificates in the Active Directory certificate store.  If you’re using Teradici PCoIP Zero Clients, you can deploy the certificates as part of a policy with the management VM.  If you don’t deploy the root and intermediate certificates, users will not be able to connect without disabling certificate checking in the Horizon View client.

Whether it is Horizon View, XenDesktop, or some other package, the implementation of a virtual desktop environment requires a significant time investment during the design phase.  If care isn’t taken, the wrong design could be put into production, and the costs of fixing it could easily outweigh the benefits of implementing a virtual desktop solution.

So before we move into installing the actual components for a Horizon View environment, we’ll spend the next two posts on design considerations.  This post, Part 3, will discuss design considerations for the Horizon View virtual desktops, and Part 4 will discuss design considerations for Active Directory.

Virtual desktop environments are all about the end user and what they need.  So before you go shopping for storage arrays and servers, you need to start looking at your desktops.

There are three types of desktops in Horizon View 6:

• Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
• Linked Clone Desktop – A linked clone is a desktop that shares its virtual disks with a central replica desktop, and any changes are written to its own delta disk.  Linked clones can be recomposed when the base template is updated or refreshed to a known good state at periodic intervals.  This feature requires Horizon View Composer.
• Remote Desktop Session Host Pools – Horizon View has supported Windows Terminal Services for multiuser session support in a limited capacity.  Horizon 6 has enhanced the RDSH features to include PCoIP support and application remoting.  When RDSH desktops and/or application remoting are used, multiple users are logged into servers that host user sessions.  This feature requires Windows Server 2008 R2 or Server 2012 R2 with the RDSH features enabled.

There are two desktop assignment types for desktop pools:

• Dedicated Assignment – users are assigned to a particular desktop during their first login, and they will be logged into this desktop on all subsequent logins.
• Floating Assignment – users are temporarily assigned to a desktop on each login.  On logout, the desktop will be available for other users to log into.  A user may not get the same desktop on each login.

Unless you have some overriding constraints or requirements imposed upon your virtual desktop project, the desktop design choices that you make will influence and/or drive your subsequent purchases.   For instance, if you’re building virtual desktops to support CAD users, blade servers aren’t an option because high-end graphics cards will be needed, and if you want/need full clone desktops, you won’t invest in a storage array that doesn’t offer deduplication.

There are a couple of areas that need to be considered when designing the virtual desktops:

• Horizon View Configuration Maximums –  There isn’t an official VMware document that outlines the official configuration maximums for a Horizon View environment.  However, Ray Heffer has that information available on his blog.
• Applications – What applications are installed on the end-user desktops?  Who uses them?  Do any of the applications have any special hardware or licensing requirements?  Are there any restrictions on who can access or use corporate applications or where they can be accessed from?
• Management Tools – What desktop management tools exist in the environment?  The lack of a management tool to deploy applications like SCCM or Altiris will make it harder to manage full clone desktops.
• Physical Desktop Performance – When sizing out the virtual desktops that make up the desktop pools, it’s important to know  how physical desktops are utilizing the resources they have.  This is important for two reasons – it ensures that the virtual desktops are not being overprovisioned with CPU or RAM and that proper reservations and limits are set on the resource pools that the virtual desktops are assigned to.
• Company Culture – Are users granted admin rights and able to install their own software without asking IT?  Are computers locked down and all applications white-listed?  Or is it somewhere in the middle? Do users already have experience with remote solutions such as Microsoft RDSH desktops or Citrix?  These are important considerations to keep in mind because environments where users have free run of their company computers may reject a centrally managed VDI environment or increase the workload for the IT staff, and staff who have no experience using Citrix or RDSH may have a hard time adjusting to their desktop being remote.
• Use Case – How are the virtual desktops going to be used?  What problems are they going to solve for the business and the employees?
• User Profile Data – User specific session settings need to be preserved, especially if you are using non-persistent desktops or RDSH pools.  Microsoft, VMware, and other partners like Liquidware Labs provide tools for profile management.  If persistent desktops are deployed, user data may remain on the virtual machine, and a backup plan will need to be put in place to protect this data.
• Antivirus and Security – Users will be accessing the Internet from their virtual desktops, so they need to be secured from the myriad of threats out there.  When selecting an antivirus solution for virtual desktops, you need to understand the impact that it will have on I/O when it updates and scans.  You may also want to look at hypervisor-level security solutions using vShield Endpoint.

Once you have answers to these questions, you’ll be able to put together a design document with the following items:

• Number of linked clone base images and/or full clone templates
• Number and type of desktop pools
• Number of desktops per pool
• Number of Connection and Security Servers needed

If you’re following the methodology that VMware uses in their design exams, your desktop design document should provide you with your conceptual and logical designs.

Once you have a desktop design document,  you’ll be able to start the infrastructure design.  This phase would cover the physical hardware to run the virtual desktop environment, the network layer, storage fabric, and other infrastructure services such as antivirus.

The desktop design document will have a heavy influence on the decisions that are made when selecting components to implement Horizon View 6.  The components that are selected need to support and enable the type of desktop environment that you want to run.

In part four, we will cover Active Directory design for Horizon View environments.

In order to deliver virtual desktops to end users, a Horizon View environment requires multiple components working together in concert.  Most of the components that Horizon View relies upon are VMware products, but some of the components, such as the database and Active Directory, are 3rd-party products.

What components does a Horizon View environment need, and what are the system requirements for these components? 

The Basics

The smallest Horizon View environment only requires four components to serve virtual desktops to end users: ESXi, vCenter, a View Connection Server, and Active Directory.  The hardware for this type of environment doesn’t need to be anything special, and one server with direct attached storage and enough RAM could support a few users.

All View environments, from the simple one above to a complex multi-site Cloud Pod environment, are built on this foundation.  The core of this foundation is the View Connection Server.

Connection Servers are the broker for the environment.  They handle desktop provisioning and user authentication and access.  There are two types of Connection Servers – Standard Connection Servers and Replica Connection Servers.  Both types of Connection Servers have the same feature set, and the only difference between the two is that the standard server is the first connection server in the environment.

Connection Servers can also manage access to multiuser desktops and published applications on Remote Desktop Session Host servers.

The requirements for a Connection Server are:

• 2 CPU
• Minimum 4GB RAM, 10GB recommended if 50 or more users are connecting
• Windows Server 2008 R2 or Windows Server 2012 R2
• Joined to an Active Directory domain

Aside from the latest version of the View Connection Server, the requirements are:

ESXi – ESXi is required for hosting the virtual machine The versions of ESXi that are supported by Horizon View 6 can be found in the VMware compatibility matrix.  All versions of ESXi 5.1 and ESXi 5.5 Update 1 are supported, but ESXi 5.5 without Update 1 is not supported.

vCenter Server – The versions of vCenter that are supported by Horizon View 6 can be found in the VMware compatibility matrix.  All versions of vCenter 5.1 and vCenter 5.5 Update 1 are supported, but vCenter 5.5 without Update 1 is not supported.  The vCenter Server Appliance and the Windows vCenter Server application are supported.

Active Directory – An Active Directory environment is required to handle user authentication to virtual desktops, and Group Policy is used to configure a number of user profile, virtual desktop and PCoIP settings.  The Server 2008 domain functional level and above are supported.

Advanced Features

Horizon View has a lot of features, and many of those features require additional components to take advantage of them.  These components add options like secure remote access, profile management, and linked-clone desktops.

Secure Remote Access – Remote access to virtual desktops and published applications is handled by the View Security Server.  The Security Server is designed to sit in the DMZ and relay or proxy connections to the Connection Server that it is paired with.  Security Servers do not need to be joined to a domain, and they have the same system requirements as a Connection Server.

Linked-Clone Desktops – Linked Clones are virtual machines that share a set of parent disks.  They are ideal for some virtual desktop environments because they can provide a large number of desktops without having to invest in new storage technologies, and they can reduce the amount of work that IT needs to do to maintain the environment.  Linked Clones are enabled by View Composer.

The requirements for View Composer are:

• 2 CPUs
• 4 GB RAM, 8GB required for deployments of 50 or more desktops
• Windows Server 2008 R2 or Server 2012 R2
• Database server – supported databases include Oracle and Microsoft SQL Server.  Please check the compatibility matrix for specific versions and service packs.

Persona Management – A user’s settings need to roam with them when they are in an environment with non-persistent desktops.  Persona Management is VMware’s answer to that by storing the full user profile in a central network location and loading it when the user logs in.  In some ways, it is like Roaming Profiles on steroids, and it works with Folder Redirection.

Networking

Horizon View requires a number of different ports to be opened in the Windows firewall as well as the firewalls between untrusted and trusted zones in the network.   Rather than write a long table with all of these ports like I intended, I’ll link to a nice graphic put together by VMware that maps it all out.

The original image, along with a detailed explanation of the map, can be found in Ray Heffer’s post on the VMware Blog site.

Back in April, VMware announced Horizon View 6.0 during a special End-User Computing webinar.  The announcement heralded some major feature additions to the desktop virtualization suite including Remote Desktop Session Host support for application publishing and support for multi-datacenter environments with the Cloud Pod Architecture.

This release has been eagerly awaited, and it finally was released to general availability on June 19th.  It is now available for download on VMware’s website.

The Series

Like my last series on View 5.3, this series will cover the installation of the Horizon View components and related infrastructure.  The topics will be similar to the last series, and I will be creating a landing page for all posts in this series.

What’s New

VMware promised a lot of changes and improvements with Horizon View 6, and they’ve delivered.  There are a number of features that the community has been asking for, and a few less popular options have been removed from the product.

Some of the new features are:

• Remote Desktop Session Host Support – Horizon View 6 now supports multiuser sessions on Remote Desktop Session Host servers using PCoIP
• Application Publishing – The expanded support for RDSH also allows for application publishing from RDSH servers.  This feature was missing from previous versions of the Horizon Suite and frequently requested.
• Cloud Pod Architecture – Larger environments with multiple datacenters had to manage the View environment in each datacenter separately.  Cloud Pod architecture allows administrators to manage up to 20,000 desktops in four pods in two datacenters as one environment.
• Full Server 2012 R2 Support for all View Server Components
• Remote Experience Agent is now integrated into the Horizon View desktop agent and does not require a separate installer
• Feature Pack 1 is now fully integrated into the View Server installer and does not require a separate installer.
• Space Reclamation supported on Windows 8 and Windows 8.1 Linked Clone Desktops
• Persona Management supported on Windows 8.1 and Server 2008 R2 desktops. Note: Persona Management is not supported on multiuser RDSH sessions
• Blast can now support up to 800 connections per Connection Server/Security Server combination.

One of the biggest changes, though, is a feature that is not included in Horizon View 6.  VMware has ended support for Local Mode desktops,  and this feature was not included with this release.  VMware will be utilizing Mirage to provide similar capabilities as local mode going forward.

If you’re interested in learning more about the additions and changes to Horizon View 6, you can check out the Release Notes here.

The next couple of posts in this series will review the architecture of Horizon View 6 and the components that are in the environment.