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.