VMWare

Horizon View 6.0 Part 5–SSL Certificates

/ seanpmassey / 1 Comment

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. 

1
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

2

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

3

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.

Horizon View 6.0 Part 4–Active Directory Configuration

/ seanpmassey / 1 Comment

When you build a Horizon View environment, the virtual desktops that users connect to run Windows.  The servers that provide the virtual desktop infrastructure services run on Windows.  So, as you can imagine, Active Directory plays a huge role in Horizon View.

When you’re planning a Horizon View deployment, or rearchitecting an existing deployment, the design of your Active Directory environment is a critical element that needs to be considered.  How you organize your virtual desktops, templates, and security groups impacts Group Policy, helpdesk delegation rights, and View Composer.

Some Active Directory objects need to be configured before any Horizon View components are installed.  Some of these objects require special configuration either in Active Directory or inside vCenter.  The Active Directory objects that need to be set up are:

  • An organizational unit structure for Horizon View Desktops
  • Basic Group Policy Objects for the different organizational units
  • An organization unit for Microsoft RDS servers if application remoting is used

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon View desktop pools.  This can be useful for organizing those groups and/or delegating access to Help Desk or other staff who don’t need Account Operator or Domain Administrator rights.

Creating An Organizational Unit for Horizon View Desktops

The first think that we need to do to prepare Active Directory for a Horizon View deployment is to create an organizational unit structure for Horizon View desktops.  This OU structure will hold all of the desktops created and used by Horizon View.  A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon View desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the View Composer service account.

There are a lot of ways that you can set up an Active Directory OU structure for Horizon View.  My preferred organizational method looks like this:

2013-12-28_21-55-14

View Desktops is a top-level OU (ie – one that sites in the root of the domain).  I like to set up this OU for two reasons.  One is that is completely segregates my VDI desktops from my non-VDI desktops and servers.  The other is that it gives me one place to apply group policy that should apply to all VDI desktops such as disabling non-essential services, turning off screen savers, or setting the inactivity timeout to lock the machine.

I create three child OUs under the View Desktops OU to separate persistent desktops, non-persistent desktops, and desktop templates.  This allows me to apply different group policies to the different types of desktops.  For instance, you may want to disable Windows Updates and use Persona Management on non-persistent desktops but allow Windows Updates on the desktop templates.

You don’t need to create all three OUs.  If your environment consists entirely of Persistent desktops, you don’t need an OU for non-persistent desktops.  The opposite is true as well.

Finally, I tend to create department or location OUs underneath the persistent or non-persistent OUs if I have locations that require special Group Policy settings in addition to the default settings.  One example where I used this was in a previous job that HEAVILY used Microsoft Access databases at one site.  Microsoft Access includes a security groups option that uses a centrally stored database file to manage access to databases.  This can be configured with group policy, and since other locations used Access without the security groups configured, applying that policy to all desktops would have broken any Access databases that the other locations used.

These grandchild OUs are completely optional.  If there is no need to set any custom policy for a location or a department, then they don’t need to be created.  However, if a grandchild OU is needed, then an entire pool will need to be created as desktop pools are assigned to OUs.  Adding additional pools can add management overhead to a VDI environment.

Creating an Organizational Unit for RDS Servers

Horizon View 6.0 added PCoIP support for multi-user desktops running on Windows Server with the Remote Desktop Session Host role.  These new abilities also added support for remote application publishing.

RDS servers need to be handled differently than virtual desktops.  They’re managed differently than your virtual desktops, and some features such as Persona Management are not available to RDS servers.

If application remoting or multi-user desktops are going to be deployed, an organizational unit for RDS servers should be created underneath your base servers organizational unit. 

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.

Unfortunately, most of the Group Policy templates are distributed as ADM files.  There are a number of drawbacks to ADM files in modern Active Directory 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.  I had previously written about converting the View Group Policy templates into the ADMX format and the reasons for converting here.

Horizon View Service Accounts

Horizon View requires a service account for accessing vCenter to provision new virtual machines.  If View Composer is used, a second service account will be needed to create computer accounts in Active Directory for linked clones.  I will cover setting up those account in a future section.

In the next section, I’ll cover SSL certificates for Horizon View servers.

Horizon View 6.0 Part 3–Desktop Design Considerations

/ seanpmassey / 4 Comments

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.

Horizon View 6.0 Part 2 – Prerequisites and System Requirements

/ seanpmassey / 3 Comments

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
Note: The requirements for the View Security Server are the same as the requirements for View Connection Server minus being 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.

Horizon View 6.0 Part 1–What’s New and Improved

/ seanpmassey / 3 Comments

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.

Exam Experience Recap – VCAP Desktop Administrator

/ seanpmassey / 1 Comment

On Tuesday, May 20th, I sat for the VCAP Desktop Administrator Exam in Milwaukee.  The exam covers a broad range of topics on Horizon View, Persona Management, and other related infrastructure components such as Group Policy.  Although I don’t work with View on a daily basis anymore, I wanted to sit for this exam as $work will be starting a Horizon View implementation this summer.

I received the official score report on Thursday night, and I did not pass.  I scored a 278 out of 500.

My exam experience mirrors Jason Shiplett’s first attempt.  I ran into an issue early in the exam that cost me time – time that I could have used to complete a few of the questions that I had in progress when the exam ended.

I didn’t prep as well as I should have before this exam.  I read through the blueprint, and I reviewed Chris Beckett’s VCAP DTA study guides.  Despite these two resources and a lot of hands-on experience with View, I went into the exam with some huge gaps in my knowledge in areas of the product suite that I hadn’t worked with in my lab or a production environment.

Unfortunately, the agreement that I had with my wife was that I would only get one crack at the exam before VMworld, and I will need to wait until August before I can take it again.  That will give me a little more time, though, to work on the areas where I need improvement.

Keys to the Exam

1. Time Management is critical. You have a very short time to complete the 23 questions on the exam.  Spending too much time on one area will hurt you.  You may also need to bounce around between questions.  I tried to use the materials my testing center provided to keep track of where I was.

2. If there is a task that you don’t know how to do, skip it and come back to it later.  You’ll lose too much time if you’re searching the documentation.

3. Hands-on Experience is a Must.  This is a practical exam, and you’re tested on successfully completing tasks.  You won’t be able to pass this exam if you don’t actually put View in a lab and try to work through the blueprint.

4. Read the blueprint and Chris Beckett’s notes that I linked to above.

Horizon View 5.3 Appendix F: Monitoring the View Event Database

/ seanpmassey / 1 Comment

One of the nice features of Horizon View 5.3 is the Events Database.  When its configured, the Events Database will collect and store any events from the Horizon View environment.

Unfortunately, VMware never built any notification tools into View to alert administrators when errors occurred and were recorded in the Events database.  There have been workarounds to this using PowerShell or SQL Mail to send database alerts, but this requires a scheduled task or SQL Agent job to ensure that it runs on a regular basis.

There is another option that can be used for Event database alerting.  Chris Halstead (Twitter: @chrisdhalstead) developed a tool called the Horizon View Event Notifier that recently became a VMware Fling. 

The Horizon View Event Notifier is a simple little application that is very easy to set up.  It’s so easy, in fact, that it doesn’t even have an installer – you just create a folder for the application and drag the executable and the config file into a folder and double-click to launch it.

Unfortunately, this simplicity carries a heavy price.  The Event Notifier cannot be run as a scheduled task or service.  It must run interactively, and if the server running the application is rebooted, an administrator will need to log in, restart the application, and then lock the computer or disconnect their session without logging out.  Chris has stated that this is one of the things he hopes to address in the next version of the program.

Configuring the Horizon View Event Notifier

After you’ve finished installing the Event Notifier, it’s time to start configuring it. 

1.  Click the settings tab.

1

2. Fill in the Name, DB Server, Database, Username and password fields.  If you have multiple View pods storing information in the same events database, you may need to enter your table prefix in the Table Prefix field. 

If you are connecting to a SQL Server instance, enter servername\instancename in the DB Server field.

2

3. Click Test Connection to verify that the Event Notifier Application can log into the database.

4. Click Save Changes to save the database information to the config file.

5. Select the type of events that you want to receive email alerts on and then click Save Changes.

3

6. Enter your email server, port number, sender address, and recipient address.

Note: The application does not appear to support email servers that require authentication, such as Gmail, at this time. 

4

7. Click Send Test Email to verify that email alerts work.

8. Click Save changes.

9. Click Start to have the application start monitoring your View Events database.

Note: The application will need to be launched and the start button clicked every time the computer is rebooted.

Do I Need It?

If you don’t have any other form of alerting configured for Horizon View Events, this program will help you maintain a healthy View environment.  It’s saved my bacon a few times when a recompose operation failed and left a pool unusable.  If I this tool hadn’t been in place, I would have had a flock of angry users with no desktops. 

Horizon View 5.3 Appendix E: Converting The View Group Policy Templates to ADMX

/ seanpmassey / 2 Comments

VMware View includes a set of Group Policy templates that can be used to centrally manage settings for View desktops and servers.   These templates are required for fine tuning the behavior of a Horizon View environment and the PCoIP and Blast protocols that are used when connecting to desktops.

Brian Suhr recently wrote a great article on how to deploy the Group Policy templates on Petri. 

There is one main drawback to the Group Policy templates that are included with Horizon View – they’re ADM files.  Prior to Windows Server 2008, Group Policy templates were deployed using ADM files.  If a non-standard ADM file was used as part of a Group Policy Object, that ADM file would be included with the group policy object when it is saved onto the domain Sysvol.  This leads to Sysvol bloat and can have a negative impact on Active Directory Replication.

Microsoft addressed this issue with updates to Group Policy in Windows Server 2008.  Server 2008 allowed Administrators to create a network-based “central store” where the new Group Policy template files are stored.  These templates could then be referenced by any workstation or server that was Vista/Server 2008 or newer when authoring or editing Group Policy without having to install them.

Converting the View ADM Files to ADMX

I haven’t found many tools that convert ADM files to ADMX files.  Microsoft has released a free conversion tool, but it didn’t convert the View ADM files properly, and a number of GPO settings did not work after using this tool.

The only other ADM converter tool that I was able to find was Syspro’s ADM Template Editor.  This $60 tool can edit existing ADM templates or convert them to ADMX files.  A 30-day free trial of the ADM Template Editor is available.

The first thing that you will need to do is download, install, and register ADM Template Editor.  Once you have done this, you can start converting the ADM files.

The steps for converting ADM files to ADMX files using the ADM Template Editor are:

1.   Copy the View ADM files to the server or workstation where ADM Template Editor is installed.  On a default installation of View, the ADM files are located in C:\Program Files\VMware\VMware View\Server\Extras\Group Policy on any Connection Server.

Group Policy Files Location

2.  Open ADM Template Editor.

3. To configure ADM Template editor to save new ADMX files directly into your Group Policy Central Store, go to Setup –> General Setup and enter the path to your Group Policy Central Store into the ADMX directory field. 

ADM Convert Pre-Step

Note: If your Active Directory Administrator has not set up a Group Policy Central Store, please refer them to this article.

4. Go to File –> Add Existing ADM file…

ADM Convert 2

5.  Select the ADM files you want to load and click Open.

ADM Convert 3

5.  Go to File –> Convert ADM to ADMX

ADM Convert 4

6.  Select the ADM file(s) you want to convert and click Convert.

ADM Convert 5

7.  The next screen allows you to change metadata before converting the ADM file.   Make any changes as required and then click OK.

ADM Convert 6

8. Go to File –> Save Files.

ADM Convert 7

9. Click Save As

ADM Convert 8

10. Save the files into a directory where you will be able to find them easily.

ADM Convert 9

11. Open the directory where you saved the ADMX files.  Copy the ADMX files and the language folder to your Group Policy Central Store.

Note: The converted Group Policy templates will not be available at remote Active Directory sites until replication occurs.

12. When you create a new Group Policy object, the converted ADMX templates should be available under Administrative Templates.

ADM Convert 11

Horizon 6 and Profile Management? It’s Not the Big Deal That Some Are Making It Out To be…

/ seanpmassey / 2 Comments

When VMware announced Horizon 6 last month, there was a lot of excitement because the Horizon Suite was finally beefing up their Remote Desktop Session Host component to support PCoIP and application publishing.  Shortly after that announcement, word leaked out that Persona Management would not be available for RDSH sessions and published applications.

There seems to be this big misconception that without Persona Management, there will be no way to manage user settings, and companies that wish to overcome this shortcoming will need to utilize a 3rd party product for profile management.  A lot of that misconception revolves around the idea that there should only be one user profile and set of applications settings that apply to the user regardless of what platform the user logs in on.

Disclosure: Horizon 6 is still in beta.  I am not a member of the beta testing team, and I have not used Horizon 6.

There are two arguments being made about the lack of unified profile management in Horizon 6.  The first argument is that without some sort of profile management, users won’t be able to save their application settings.  The article quotes a systems administrator who says, “If you rely on linked clones and want to use [RDSH] published apps, it won’t remember your settings.”

This is not correct.  When setting up an application publishing environment using RDSH, a separate user profile is created for each user on the server, or servers, where the applications are hosted.  That user profile is separate from the user profile that is used when logging into the desktop.  In order to ensure that those settings follow the user if they log into a different server, technologies like roaming profiles and folder redirection are used to store user settings in a central network location.

This ability isn’t an add-on feature, and the ability to do roaming profiles and folder redirection are included with Active Directory as options that can be configured using Group Policy.  Active Directory is a requirement for Horizon environments, so the ability to save and roam settings exists without having to invest in additional products.

The other argument revolves around the idea of a “single, unitary profile” that will be used in both RDSH sessions for application publishing and virtual desktops.  There are a couple of reasons why that this should not be considered a holdup for deploying Horizon 6:

  1. Microsoft’s best practices for roaming profiles (2003 version, 2008 R2 version, RDS Blog) do not recommend using the same profile across multiple platforms, and Microsoft recommends using a different roaming profile for each RDSH farm or platform.
  2. Citrix’s best practices for User Profile Manager, the application that the article above references as providing a single profile across application publishing and virtual desktops, do not recommend using the same profile for multiple platforms or across different versions of Windows.

There are a couple of reasons for this.  The main reason is that there are settings in desktop profiles that don’t apply to servers and vice versa or across different generations of Windows.  There is also the possibility of corruption if a profile is used in multiple places at the same time, and one server can easily overwrite changes to the profile.

Although there may be some cases where application settings may need to roam between an RDSH session and a virtual desktop session, I haven’t encountered any cases where that would be important.  That doesn’t mean those cases don’t exist, but I don’t see a scenario where this would hold up adopting a platform like the article above suggests.

Horizon View 5.3 Part 15 – Horizon View, SSL, and You

/ seanpmassey

Although they may be confusing and require a lot of extra work to set up, SSL certificate play a key role in any VMware environment.  The purpose of the certificates is to secure communications between the clients and the servers as well as between the servers themselves.

Certificates are needed on all of the major components of Horizon View and vCenter.  The certificates that are installed on vCenter Server, Composer, and the Connection Servers can come from an internal certificate authority.  If you are running Security Servers, or if you have a Bring-Your-Own—Beer Device environment, you’ll need to look at purchasing certificates from a public certificate authority.

Setting up a certificate authority is beyond the scope of this article.  If you are interested in learning more about setting up your own public key infrastructure, I’ll refer you to Derek Seaman, the VMware Community’s own SSL guy.  He recently released a three-part series about setting up a two-tier public key infrastructure on Windows Server 2012 R2.  I’ve also found this instruction set to be a good guide for setting up a public key infrastructure on Windows Server 2008 R2.

Improved Certificate Handling

Managing SSL certificates was a pain if you’ve worked with previous versions of Horizon View.  In previous versions, the certificates had be placed into a Java keystore file.  This changed with View 5.1, and the certificates are now stored in the Windows Certificate Store.  This has greatly improved the process for managing certificates.

Where to Get Certificates

Certificates can be minted on internal certificate authorities or public certificate authorities.  An internal certificate authority exists inside your environment and is something that you manage.  Certificates from these authorities won’t be trusted unless you deploy the root and intermediate certificates to the clients that are connecting.

The certificates used on a security server should be obtained from a commercial certificate vendor such as Thawte, GoDaddy, or Comodo.  One option that I like to use in my lab, and that I’ve used in the past when I didn’t have a budget for SSL certificates is StartSSL.  They provide free basic SSL certificates.

Generating Certificate Requests for Horizon View Servers

VMware’s methods for generating certificates for Horizon View is different than vCenter.  When setting up certificate requests for vCenter, you need to use OpenSSL to generate the requests.  Unlike vCenter, Horizon View uses the built-in Windows certificate tools are used to generate the certificate requests. VMware has a good PDF document that walks through generating certificates for Horizon View.  An online version of this article also exists.

Before we can generate a certificate for each server, we need to set up two things.  The first is a certificate template that can be used to issue certificates in our public key infrastructure.  I’m not an expert on public key infrastructure, so I’ll defer to the expert again.

The other thing that we need to create is a CSR configuration file.  This file will be used with certreq.exe to create the certificate signing request.  The template for this file, which is included in the VMware guide, is below.

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

Signature="$Windows NT$"

[NewRequest]

Subject = "CN=View_Server_FQDN, OU=Organizational_Unit_Name, O=Organization_Name, L=City_Name, S=State_Name, C=Country_Name" ; replace attributes 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

[RequestAttributes]

; SAN="dns=FQDN_you_require&dns=other_FQDN_you_require" 
;-----------------------------------------------

The subject line contains some fields that we need to fill in with information from our environment.  These fields are:

  • CN=server_fqdn: This part of the Subject string should contain the fully qualified domain name that users will use when connecting to the server. An example for an internal, non-Internet facing server is internalbroker.internaldomain.local.  An internet-facing server should use the web address such as view.externaldomain.com
  • OU=organizational unit: I normally fill in the responsible department, so it would be IT.
  • O=Organization: The name of your company
  • L=City: The city your office is based in
  • S=State: The name of the State that you’re located in.  You should spell out the name of the state since some CAs will not accept abbreviated names.
  • C=Country: The two-letter ISO country code.  The United States, for example, is US.

A CSR configuration file will need to be created for each server with a Horizon View Component installed.  vCenter will also need certificates, but there are different procedures for creating and installing vCenter certificates depending on whether you are using the Windows application or the vCenter appliance.

Creating the certificate signing request requires the certreq.exe command line tool.   These steps will need to be performed on each connection server, security server, and  The steps for generating the request are:

  1. Open a command prompt as an Administrator on your View server. Note: This command should be run from the server where you want the certificate to reside.  It can be done from another machine, but it makes it more complicated.
  2. Navigate to the folder where you stored the request.inf file.
  3. Run the following command: certreq.exe –new request.inf server_name_certreq.txt

After the certificate request has been created, it needs to be submitted to the certificate authority in order to have the SSL certificate generated.  The actual process for submitting the CSR is beyond the scope of this article since this process can vary in each environment and with each commercial vendor.

Importing the Certificate

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

certreq.exe –accept certname.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. 

1
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

2

Certificates and 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

3

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 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.  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 do this, users will not be able to connect without disabling certificate checking in the client.