Configuring Duo Security MFA for Horizon Unified Access Gateway

Note: After publishing, I decided to rework this blog post a bit to separate the AD-integrated Duo configuration from the Duo-only configuration.  This should make the post easier to follow.

In my last post, I went through the steps for deploying a Horizon Access Point/Unified Access Gateway using the PowerShell deployment script.  That post walked through the basic deployment steps.

The Unified Access Gateway supports multiple options for two-factor authentication, and many real-world deployments will use some form of two-factor when granting users access to their desktops and applications remotely.  The Unified Access Gateway supports the following two-factor authentication technologies:

  • RSA Secur-ID
  • RADIUS
  • Certificate Based/Smart-Cards

Because I’m doing this in a lab environment, I decided to use a RADIUS-based technology for this post.  I’ve been using Duo Security for a while because they support RADIUS, have a mobile app, and have a free tier.  Duo also supports VMware Horizon, although they do not currently have any documentation on integrating with the Access Point/Unified Access Gateway.

Duo Security for Multi-factor Authentication

Duo Security is a cloud-based MFA provider.  Duo utilizes an on-premises Authentication Proxy to integrate with customer systems.  In addition to providing their own authentication source, they can also integrate into existing Active Directory environments or RADIUS servers.

When using Active Directory as the authentication source, Duo will utilize the same username and password as the user’s AD account.  It will validate these against Active Directory before prompting the user for their second authentication factor.

Understanding Unified Access Gateway Authentication Path

Before I configure the Unified Access Gateway for two-factor authentication with Duo, let’s walk through how the appliance handles authentication for Horizon environments and how it compares to the Security Server.  There are some key differences between how these two technologies work.

When the Security Server was the only option, two-factor authentication was enabled on the Connection Servers.  When users signed in remotely, the security server would proxy all authentication traffic back to the connection server that it was paired with.  The user would first be prompted for their username and their one-time password, and if that validated successfully, they would be prompted to log in with their Active Directory credentials.  The reliance on connection servers meant that two sets of connection servers needed to be maintained – one internal facing without multi-factor authentication configured and one external facing with multi-factor configured.

Note: When using Duo in this setup, I can configure Duo to use the same initial credentials as the user’s AD account and then present the user with options for how they want to validate their identity – a phone call, push to a mobile device, or passcode.  I will discuss that configuration below.

The Unified Access Gateway setup is, in some ways, similar to the old Security Server/Connection Server setup.  If 2FA is used, the user is prompted for the one-time password first, and if that is successful, the user is prompted for their Active Directory credentials.  But there are two key differences here.  First, the Unified Access Gateway is not tied to a specific Connection Server, and it can be pointed at a load-balanced pool of connection servers.  The other difference is 2FA is validated in the DMZ by the appliance, so 2FA does not need to be configured on the Connection Servers.

Horizon has a couple of multi-factor authentication options that we need to know about when doing the initial configuration.  These two settings are:

  • Enforce 2-factor and Windows user name matching (matchWindowsUserName in UAG) – enabled when the MFA and Windows user names match.
  • Use the same username and password for RADIUS and Windows authentication (WindowsSSOEnabled in UAG) – Used when the RADIUS server and Windows have the same password.  When this setting is enabled, the domain sign-on prompt is skipped.

If my two-factor authentication system supports Active Directory authentication, I can use my Windows Username and Password to be authenticated against it and then receive a challenge for a one-time password (or device push).  If this second factor of authentication is successful, I will be automatically signed into Horizon.

Configuring Duo

The Duo environment needs to be configured before Horizon MFA can be set up.  Duo requires an on-premises authentication proxy.  This proxy acts as a RADIUS server, and it can run on Windows or Linux.  The steps for installing the Duo authentication proxy are beyond the scope of this article.

Once the authentication proxy is installed, it needs to be configured.  Duo has a number of options for configuration, and it’s important to review the documentation.  I’ll highlight a few of these options below.

The first thing we need to configure is the Duo client.  The client determines what type of primary authentication is performed.  Duo supports three methods:

  • ad_client: Duo uses Active Directory for primary authentication.  Users sign in with their Active Directory username and password.
  • radius_client: Duo uses the specified RADIUS server, such as Microsoft NPS or Cisco ACS, for primary authentication.
  • duo_only_client: Duo does not perform primary authentication.  The authentication proxy only performs secondary authentication, and primary authentication is handled by the configured system.

I don’t have a RADIUS server configured in my lab, so I did testing with both the ad_client and the duo_only_client. I prefer a single sign-on solution in my lab, so this setup will be configured with the ad_client.

The authentication proxy configuration is contained in the authproxy.cfg file located in C:\Program Files (x86)\Duo Security Authentication Proxy\conf.  Open this file in a text editor and add the following lines:

[ad_client]
host=DC.IP.0.1
host_2=DC.IP.0.2
service_account_username=serviceaccount
service_account_password=serviceaccountpassword
search_dn=DC=domain,DC=com

Duo includes a number of options for configuring an Active Directory client, including encrypted passwords, LDAPS support, and other security features.  The configuration above is a simple configuration meant for a lab or PoC environment.

Before the RADIUS server settings can be configured, a new application needs to be created in the Duo Administration Console.  The steps for this are:

1. Log into the Duo Admin Console.

2. Click Applications

3. Click Protect an Application

4. Scroll down to VMware View and select “Protect this Application.”

5. Copy the Integration Key, Secret Key, and API Hostname.

6. Change the username normalization option to “Simple.”

7. Click “Save Changes.”

The next step is to configure the authentication proxy as a RADIUS service.  Duo also has a number of options for this.  These determine how Duo interacts with the client service.  These options include:

  • RADIUS_Auto: The user’s authentication factor, and the device that receives the factor, is automatically selected by Duo.
  • RADIUS_Challenge: The user receives a textual challenge after primary authentication is complete.   The user then selects the authentication factor and device that it is received on.
  • RADIUS_Duo_Only: The RADIUS service does not handle primary authentication, and the user’s passcode or factor choice is used as the RADIUS password.

Duo also has multiple types of authentication factors.  These options are:

  • Passcode: A time-based one-time password that is generated by the mobile app.
  • Push: A challenge is pushed to the user’s mobile device with the Duo mobile app installed.  The user approves the access request to continue sign-in.
  • Phone Call: Users can opt to receive a phone call with their one-time passcode.
  • SMS: Users can opt to receive a text message with their one-time passcode.

RADIUS_Challenge will be used for this setup.  In my testing, the combination of an ad_client and RADIUS_Auto meant that my second authentication factor was a push to the mobile app.  In most cases, this was fine, but in situations where my laptop was online but my phone was not (such as on an airplane), meant that I was unable to access the environment.  The other option is to use RADIUS_Duo_Only with the Duo_Only_Client, but I wanted a single sign-on experience.

The RADIUS server configuration for the Horizon Unified Access Gateway is:

[radius_server_challenge]
ikey=[random key generated by the Duo Admin Console]
skey=[random key generated by the Duo Admin Console]
api_host=api-xxxx.duosecurity.com [generated by the Duo Admin Console]
failmode=secure
client=ad_client
radius_ip_1=IP Address or Range
radius_secret_1=RadiusSecret
port=1812
prompt_format=short

The above configuration is set to fail secure.  This means that if the Duo service is not available, users will be unable to log in.  The other option that was selected was a short prompt format.  This displays a simple text message with the options that are available and prompts the user to select one.

Save the authproxy.cfg file and restart the Duo Authentication Proxy service for the new settings to take effect.

The next step is to configure the Unified Access Gateway to use RADIUS.  The following lines need to be added to the [Horizon] section:

authMethods=radius-auth

matchWindowsUserName=true

windowsSSOEnabled=true

A new section needs to be added to handle the RADIUS configuration.  The following lines need to be added to create the RADIUS section and configure the RADIUS client on the Unified Access Gateway.  If more than one RADIUS server exists in the environment, you can add an _2 to the end of hostname and auth_port.

[RADIUSAuth]

hostName=IP.to.RADIUS.Server [IP of the primary RADIUS server]

authType=PAP

authPort=1812

radiusDisplayHint=XXX Token

Save the UAG configuration file and deploy, or redeploy, your Unified Access Gateway.  When the deployment completes, and you log in externally, you should see the following screens:

image

image

Duo-Only Authentication

So what if I don’t want an AD-integrated single sign-on experience?  What if I just want users to enter a code before signing in with their AD credentials.  Duo supports that configuration as well.  There are a couple of differences compared to the configuration for the AD-enabled Duo environment.

The first change is in the Duo authentication proxy config file.  No AD client configuration is required.  Instead of an [ad_client] section, a single line entry of [duo_only_client] is required.  The RADIUS Server configuration can also mostly stay the same.  The only required changes are to change the client from ad_client to duo_only_client and the section name from [radius_server_challenge] to [radius_server_duo_only].

The Access Point configuration will change.  The following configuration items should be used instead:

authMethods=radius-auth && sp-auth

matchWindowsUserName=true

windowsSSOEnabled=false

 

Horizon 7.0 Part 13 – Deploying The Horizon Access Point

In the last part of this series, I walked through the different remote access options for a Horizon 7 environment.  In this post, I’ll cover how to install and configure an Access Point appliance for a Horizon environment.

Note: The Access Point appliance has been renamed to the Unified Access Gateway as of Horizon 7.1.  This post began before the product was renamed, and the old naming convention will be used.

Before we go into deploying the appliance, let’s dive into what the appliance does and how it’s built.

As I said in the previous post, the Access Point is a purpose built virtual appliance that is designed to be the remote access component for VMware Horizon, VMware Identity Manager, and Airwatch.  The appliance is hardened for deployment in a DMZ scenario, and it is designed to only pass authorized traffic from authenticated users into a secure network.  In some ways, the Access Point is designed to replace VPNs, but it doesn’t provide full access to an internal network like a VPN would.

When deploying an Access Point, I highly recommend using the PowerShell Deployment Script.  This script was written by Mark Benson, the lead developer of the Access Point.  The script uses an INI configuration file that can be customized for each appliance that is deployed.  I like the PowerShell script over deploying the appliance through vCenter because the appliance is ready to use on first boot, it allows administrators to track all configurations in a source control system such as Github or Bitbucket Server, and this provides both documentation for the configuration and change tracking.  It also makes it easy to redeploy or upgrade the access point because I rerun the script with my config file and the new OVA file.

The PowerShell script requires the OVF Tool to be installed on the server or desktop where the PowerShell script will be executed.  The latest version of the OVF Tool can be downloaded from the My VMware site.  PowerCLI is not required when deploying the Access Point as OVF Tool will be deploying the Access Point and injecting the configuration.

The steps for deploying the Access Point are:

1. Download the PowerShell deployment script for the version of the Access Point you will be deploying.  You can download the script from here.

2.  Right click on the downloaded zip file and select Properties.

3. Click Unblock.  This step is required because the file was downloaded from the Internet, and is untrusted by default, and this can prevent the script from executing.

4. Extract the contents of the downloaded ZIP file to a folder on the system where the deployment script will be run.  The ZIP file contains the apdeploy.ps1 script file and five INI template files.  As of January 2017, four of the template files are example configurations for Horizon, and one is a sample configuration for vIDM. 

When deploying the access points for Horizon, I recommend starting with the AP2-Advanced.ini template.  This template provides the most options for configuring Horizon remote access and networking.  Once you have the AP deployed successfully, I recommend copying the relevant portions of the SecurID or RADIUS auth templates into your working AP template.  This allows you to test remote access and your DMZ networking and routing before adding in MFA.

5. Before we start filling out the template for our first access point, there are some things we’ll need to do to ensure a successful deployment. These steps are:

A. Ensure that the OVF Tool is installed on your deployment machine.

B. Locate the Access Point’s OVA file and record the full file path.  The OVA file can be placed on a network share.

C. We will need a copy of the certificate, including any intermediate and root CA certificates, and the private key in PEM format.  The certificate files should be concatenated so that the certificate and any CA certificates in the chain are in one file, and the private key should not have a password on it.  Place these files into a folder on the local or network folder and record the full path.

D. We need to create the path to the vSphere resources that OVF Tool will use when deploying the appliance.  This path looks like: vi://user@PASSWORD:vcenter.fqdn.orIP/DataCenter Name/host/Host or Cluster Name/

Do not replace the uppercase PASSWORD with any value.  This is an OVF Tool variable that prompts the user for a password before deploying the appliance.  OVF Tool is case sensitive, so make sure that the datacenter name and host or cluster names are entered as they are displayed in vCenter.

E. Generate the passwords that  you will use for the appliance Root and Admin passwords.

F. Get the SSL Thumbprint for the certificate on your Connection Server or load balancer that is in front of the connection servers.

6. Fill out the template file.  The file has comments for documentation, so it should be pretty easy to fill out.  There are a couple of things that I’ve noticed when deploying the access point using this method.  You need to have a valid port group for all three networks, even if you are only using the OneNic deployment option. 

7. Save your INI file as <APName>.ini in the same directory as the deployment scripts.

8. Open PowerShell and change to the directory where the deployment scripts are stored.

9. Run the deployment script.  The syntax is .\APDeploy.ps1 –inifile <apname>.ini

10. Enter the appliance root password twice.

11.  Enter the admin password twice.  This password is optional, however, if one is not configured, the REST API and Admin interface will not be available.

12.  If RADIUS is configured in the INI file, you will be prompted for the RADIUS shared secret.

13. After the script opens the OVA and validates the manifest, it will prompt you for the password for accessing vCenter.  Enter it here.

14. If an access point with the same name is already deployed, it will be powered off and deleted.

15. The appliance OVA will be deployed.  When the deployment is complete, the appliance will be powered on and get an IP address from DHCP.

16. The appliance configuration defined in the INI file will be injected into the appliance.  It may take a few minutes for configuration to be completed.

image 

Testing the Access Point

Once the appliance has finished it’s deployment and self-configuration, it needs to be tested to ensure that it is operating properly. The best way that I’ve found for doing this is to use a mobile device, such as a smartphone or cellular-enabled tablet, to access the environment using the Horizon mobile app.  If everything is working properly, you should be prompted to sign in, and desktop pool connections should be successful.

If you are not able to sign in, or you can sign in but not connect to a desktop pool, the first thing to check is your firewall rules.  Validate that TCP and UDP ports 443 and 4172 are open between the Internet and your Access Point.  You may also want to check your network routes in your configuration file.  If your desktops live in a different subnet than your access points and/or your connection servers, you may need to statically define your routes.  An example of a route configuration may look like the following:

routes1 = 192.168.2.0/24 192.168.1.1,192.168.3.0/24 192.168.1.1

If you need to make a routing change, the best way to handle it is to update the ini file and then redeploy the appliance.

My Windows 10 Template Build Process

I’ve been spending a lot of time working with Windows 10 in the lab lately, and one of the big struggles I’ve faced was building a solid template that I could reuse.  The reason I’ve had trouble with this is due to changes that Microsoft made in Windows 10 that essentially break the process that worked with previous versions of Windows.  The biggest changes include Modern UI applications and changes to how default applications are handled.

Modern UI apps are problematic for many reasons.  First, some of the original core Windows applications have been replaced by Modern UI applications, so while it is possible to remove them, you lose significant functionality that may not be replaced by 3rd Party applications.  In order to keep these applications up-to-date, the Windows Store needs to be available on the desktop.  That also means that the Store can’t be disabled unless you want to run outdated Modern UI applications.  Second, Modern UI apps tend to break Sysprep if any user profiles exist on the system outside of the built-in Administrator. 

Default applications are another tricky area.  In previous versions of Windows, a web browser or document viewer could set itself, or prompt the user to set it, as the default application for certain file types or URLs.  So if you installed Adobe Reader, it could set itself up as the default application for PDF programs.  This does not necessarily appear to be the case in Windows 10 – some applications that manage common file types have a system default that applies to all users.  This is mainly true for URLs and PDF files, and they default to Microsoft Edge.  While I can change this on a per-user basis, I may want to enforce certain corporate application standards within my image.

I’ve been spending a lot of time building Windows 10 desktop templates in my lab, and I’ve been looking at a lot of Windows 10 build guides.  All of the ones I’ve seen treat a Windows 10 build like a Windows 7 build with some minor changes, but none of them address the issues that I’ve experienced in my lab.

To get around issues with Modern UI applications, managing and/or cleaning up user accounts on the system before sysprepping my template, and dealing with application defaults, I decided to put together a different method for building my Windows 10 VDI image to address the issues I’ve faced and to reduce the number of manual steps that I have to take when creating and/or updating the template.  The main thing that I do differently is the use of Sysprep Audit Mode.  Audit mode allows an administrator to bypass the OOBE and log into the desktop as a local administrator with network access to customize the desktop environment, and the system remains in Audit Mode until Sysprep is run again.  While in Audit Mode, I cannot join the computer to the domain.  However, this is not a deal breaker as I can access my file shares without being joined to the domain.

When building this template, I don’t do a defrag or run the VMware OS Optimization tool as this template is the grandparent VM.  I will deploy my production parent VMs from this template and optimize them before deploying my instant clone or full clone pools.  I also don’t feel that defrag is needed with disposable VMs running on modern storage solutions.

My steps for building a Windows 10 virtual desktop template are:

1. Create the VM in vCenter.  Select the VMXNet3 network card as the network device and configure the VM to boot directly into the BIOS.  Also be sure to attach the Windows 10 ISO to the virtual machine.

2. Power the VM on.

3. Open the Console or use the remote console to access the VM.

4. Disable the Floppy drive and the Serial, Parallel, and Floppy Controllers in the BIOS.  Press F10 to save the settings and reboot.

5. Boot into the Windows Installation disk.

6. When you reach the first screen of the Windows installer, press Shift-F10 to open a command prompt.

7. Type diskpart to launch the disk partition utility.  We’ll use this to custom create our partition.  By default, the Windows installer creates a partition table that includes 100MB reserved space for Bitlocker.  Bitlocker isn’t supported in VDI, so we will manually create our partition.  The steps to do that are:

  • Type Select Disk 0
  • Type Create Partition Primary
  • Type Exit twice

8. Install Windows 10 using the default options.

9. When the system boots the Out-of-Box-Experience (Windows Welcome/Set up New Account), press Control-Shift-F3 to boot into Sysprep Audit Mode.

10. Install VMware Tools and reboot.

11.  Install the Horizon agent and reboot.  Note: You may need to connect to a network file share to access installers.  When doing so, sign in as Domain\User when prompted.  Do not join the system to the domain while in Audit Mode.

12. Install any applications and/or updates that you want to have in the template.  Reboot as often as required as the servers will boot into Audit Mode.

13.  Remove any Modern UI Apps that you don’t want to provision as part of the template.  I remove all except for Photos (haven’t found a good free alternative), Calculator (Windows 10 Calculator is actually pretty good), and Store (might need it depending on my use case/to keep the other two updated).  You actually need to deprovision it twice – once for the administrator account and once at the system level to remove the AppX Package.  The steps for this are:

  • Open PowerShell as an Administrator.
  • Run the following command to deprovision AppX Packages for all users: Get-AppXPackage  -allusers| Where {($_.name –notlike “*Photos*”) –and ($_.name –notlike “*Calculator*”) –and ($_.name –notlike “*Store*”)} | Remove-AppXPackage
  • Run the following command to uninstall unneeded AppX Packages: Get-AppXProvisionedPackage –online | Where {($_.name –notlike “*Photos*”) –and ($_.name –notlike “*Calculator*”) –and ($_.name –notlike “*Store*”)} | Remove-AppXProvisionedPackage –online

14.  Configure the application defaults for your administrator account.  This can be done in Settings –> System –> Default Apps.

15. Now we’re going to replace the default application associations.  Windows stores these in an XML file, and these associations are installed for each new user that logs into the system.  This file is called DefaultOEMAssociations.xml, and it is located in C:\Windows\System32.  The steps for this are:

  • Back up the C:\Windows\System32\DefaultOEMAssociations.xml file.
  • Open PowerShell as an Administrator
  • Run the following command to export your Administrator account default app associations:dism /online /Export-DefaultAppAssociations:”%userprofile%\Desktop\NewDefaultAppAssociations.xml”
  • Run the following command to import your new default app associations: dism /online /Import-DefaultAppAssociations:”%userprofile%\Desktop\NewDefaultAppAssociations.xml”

16. Reboot the system.

17. After the system reboots, the sysprep window will pop up.  Select “Out-of-Box Experience,” “Generalize,” and Shut Down.  Click OK to run sysprep.

18. After the VM shuts down, convert it to a template and deploy a test VM.  The VM should boot to the Out-of-Box-Experience.  You can also use a customization spec when deploying templates from the VM, and while it will boot to the Out-of-Box-Experience, the customization will still run.

So these are the basic steps that I do when building my Windows 10 template for VMware.  If you have any questions, please get my on Twitter at @seanpmassey.

Horizon 7.1–Together We’re Just in Time

If you couldn’t tell by the title of this post, new product announcement time.  Last year at this time, VMware announced App Volumes 3.0, Horizon 7.0, and a number of enhancements including Smart Policies and Instant Clones.  This year, Horizon 7.1 brings a brand new set of improvements that build on the features that were released with Horizon 7.0, including some long awaited features around vGPU, instant clones, and Blast Extreme.

The Just-in-Time Management Platform

The Just-in-Time Management Platform, or JMP (pronounced “jump”) is VMware’s next generation desktop and application delivery platform.  JMP is built on VMware’s instant clone technology for fast provisioning, real-time application delivery provided by App Volumes, and contextual policy and user environment management by UEM.  JMP provides both traditional desktops with just-in-time instant clone desktops and published applications with just-in-time RDSH servers for published applications.

Wait…what?

You heard that right.  Instant clone technology has been extended, and it can now be used to provision RDSH server farms. Like Instant Clone desktop pools, instant clone RDSH farms can be elastic and scale near-instantaneously to provide capacity as it is required.  Like instant clone desktop pools, instant clone RDSH farms can provide rolling updates for zero downtime image updates.  VMware is also adding the ability to schedule recurring maintenance of RDSH pools into Horizon Administrator to ensure that the servers are periodically refreshed.

Joining the new Just-in-Time Apps feature is a new Horizon SKU called Horizon Apps.  This SKU provides an RDSH-only focused SKU that includes Instant Clones, Published Apps, App Volumes, UEM, and vSphere.  This new SKU fills a hole in the Horizon product lineup and provides a direct competitor to Citrix XenApp.

We Got the BEAT – Blast Extreme Adaptive Transport

We got the beat…we got the beat…

Sorry, got a little carried away there. 

VMware continues to improve the Blast protocol, and Horizon 7.1 contains the latest enhancements to the protocol – Blast Extreme Adaptive Transport, or BEAT for short.  BEAT is designed to provide a great user experience on multiple network types while adapting to changing network conditions including varying network speeds and severe packet loss. 

VMware was able to achieve these results by adding adaptive bit rates and forward error correction to the protocol as well as adding additional optimizations to better handle network latency and packet loss.  As a result of these improvements, VMware was able to significantly reduce out-of-the-box bandwidth utilization, improve user experience on high latency links, and improve file transfer times from the endpoint to the virtual desktop when using Client Drive Redirection.

Horizon Cloud

Ok…it’s not a good fit.  But it’s hard to find a good 80’s song about clouds. 

Horizon Cloud is the next-generation version of Horizon Air.  Unlike Horizon Air, which was hosted in vCloud Air, Horizon Cloud is hosted in IBM SoftLayer, and it will feature the Horizon Just-in-Time Management Platform.  This enables VMware to provide features that weren’t available in vCloud Air including GPU support, published applications, and utilizing vIDM as a portal for accessing virtual desktops and applications.

Horizon Cloud will also feature an on-premises solution combining hyper-converged infrastructure with a cloud control plane.  This offering will serve as the next generation Horizon Air Hybrid Mode.

Horizon Cloud will utilize one license for both the cloud-hosted and on-premises offering, and these licenses will be available in both named user and concurrent user options.

Other Enhancements

Like any Horizon release, there will be a multitude of enhancements.  A few of the other new enhancements that I’ve learned about are:

  • Instant Clone Desktop support for vGPU – Horizon 7.1 will allow you to run 3D workloads on Instant Clone Desktops
  • Multi-VLAN support for Instant Clones – Feature-parity with Linked-Clone desktops
  • Being able to manage multiple VLANs within Horizon Administrator – no need for a PowerShell script

Horizon 7.0 Part 12–Understanding Horizon Remote Access

When you decouple the user from the physical hardware that sits on their desk, you provide new opportunities to change the way they work because they are no longer tethered to their desk. If you can provide secure remote access to their desktop, they are no longer tied to their VPN connection or corporate laptop.

Horizon View provides a secure method for granting users access to their desktops from anywhere with an Internet connection on any device without needing a VPN connection.  Now that a desktop pool has been set up and desktops are provisioned, it’s time to set up that remote access.

The Security Server

The View Security Server is VMware’s original method of addressing remote access.  This component of the Horizon View environment contains a subset of the Connection Server components, and it is designed to sit in a DMZ and act as a gateway for Horizon View Clients.  It’s essentially a reverse proxy for your View environment.

Each Security Server that is deployed needs a corresponding Connection Server, and they are paired during the installation process.  Because the Security Server is an optional component, each Connection Server is not required to have one, and a Connection Server cannot be paired to more than one Security Server.

Each Security Server also needs a static IP address.  If it is externally facing, it will need to have a publicly addressable static IP.  This IP address does not need to be configured on the server’s network card as both Static 1:1 NAT and PAT work with Horizon View.

Since the Security Server is built on a subset of Connection Server components, it requires a Windows Server-based operating system.  This may require putting Windows servers into a DMZ network, and this can present some security and management challenges.

Security Server Alternatives

There are two alternatives for providing remote access to Horizon environments if you don’t want to place Windows servers into a DMZ environment.  These two alternatives are the Horizon Access Point, a hardened purpose-built remote access appliance for Horizon and Airwatch, and the F5 Access Policy Manager for Horizon. 

The Horizon Access Point was officially released for Horizon environments with Horizon 6.2.2, and it has received new features and improvements with every major and minor Horizon release since.  In addition to being a Security Server replacement, it can also act as a reverse proxy for VIDM and as endpoint for Airwatch Tunnels to connect on-premises services with a cloud-hosted Airwatch environment.  The Access Point is designed to be disposable.  When the Access Point needs an upgrade, settings change (such as a certificate replacement), or breaks, the appliance is meant to be discarded and a new one deployed in its place.  The Access Point also has no management interface.  It does have a REST API that can be used to view configuration details and monitor the number of connections that are connecting through the Access Point.

The F5 Access Policy Manager is a feature of the F5 Application Delivery Controller.  Access Policy Manager provides context-aware secure remote access to applications and other resources.  One of the feature of APM is a Horizon Proxy.  The Horizon Proxy can authenticate users to the Horizon environment and handle both PCoIP and Blast connections.  F5 APM is configured using a Horizon iApp Rule – a template with all of the F5 rules required for Horizon and a graphical interface for configuring it to your particular environment.  The APM feature is licensed separately from other F5 features, and there is an additional cost for F5 APM licensing.

The table below outlines the features of the Security Server, Access Point, and F5 APM.

 

Security Server

Access Point F5 Access Policy Module
Platform Windows Server Virtual Appliance Physical or virtual Appliance
Protocol Support PCoIP, Blast Extreme PCoIP, Blast Extreme PCoIP, Blast Extreme
Interaction with Horizon Paired with Connection Servers HTTPS connection to load-balanced Connection Servers HTTPS connection to pool of connection servers
Two-Factor Auth Support Handled by Connection Servers RSA, Radius-Based RSA, Radius-Based
Deployment Method Manual Scripted GUI-based

Security Server Firewall Ports

In order to enable remote access, a few ports need to be opened on any firewalls that sit between the network where the Security Server has been deployed and the Internet.  If the server is deployed into a  DMZ, the firewall will also need to allow traffic between the Security Server and the Connection Server.

The rules that are required on the front-end, Internet-facing firewall are:

  • HTTP – TCP 80 In
  • HTTPS – TCP 443 In
  • HTTPS – UDP 443 In (for Blast Extreme UDP Connections)
  • HTTPS – TCP 8443 both directions (if Blast is used with the Security Server)
  • PCoIP – TCP 4172 In, UDP 4172 both directions

Backend firewall rules between the remote access solution and the Horizon Connection Servers and desktops depends on the remote access solution being configured.  The following table outlines the ports that need to be opened between the DMZ and internal networks.

Port Protocol Zone Notes
443 TCP HTTPS DMZ –Connection Servers Access Point only
4172 TCP/UDP PCoIP DMZ to Virtual Desktop Subnets  
22443 TCP/UDP Blast DMZ to Virtual Desktop Subnets  
9427 TCP Client Drive Redirection/MMR DMZ to Virtual Desktop Subnets  
500 UDP IPSec DMZ to Connection Servers Security Server Only
4500 UDP NAT-T ISAKMP DMZ to Connection Servers Security Server Only

If you are deploying your Security Servers in a DMZ configuration with a back-end firewall, you need to configure your firewall to allow IPSEC traffic to the Connection Servers.  These rules depend on whether network address translation is used between the DMZ and Internal network.  For more information on the rules that need to be enabled, please see this VMware KB article.

Note: If you’re using application-aware firewalls like Palo Alto Networks devices, make sure that any application protocols required by Horizon View aren’t blocked between the DMZ and Internal network.  Also, updates to the application signatures or the PCoIP protocol may impact users’ access to virtual desktops.

So Which Should I Use?

The million dollar question when deploying a brand new Horizon environment is: which remote access method should I use?  The answer is “whichever one fits your needs the best.”  When designing remote access solutions for Horizon, it is important to understand the tradeoffs of using the different options and to evaluate options during the pilot phase of the project.

If possible, I would recommend staying away from the Security Server now that there are other options for remote access.  I don’t recommend this for many clients because the Access Point has feature parity with the Security Server, and it avoids the security and management hassles of deploying Windows Servers into an organization’s DMZ network.

Horizon 7 and App Volumes 2.x Updates

VMware has been committed to adding new features with every Horizon Suite point update, and the latest updates, announced yesterday, are no exception.

The Horizon 7.0.3 update, in conjunction with vSphere 6.5, adds several long-awaited features (announcement blog)(release notes).  These are:

  • Expanded Support for Windows 10
  • H.264 multimonitor support for Windows and Linux
  • A Universal Windows Platform Horizon Client for Blast Extreme
  • Linux Enhancements, including
    • Audio Input support
    • Ubuntu 16.04 Support
    • Clipboard Redirection for all supported versions
    • vGPU support for NVIDIA M6 GPUs for Red Hat Enterprise Linux desktops
  • Support for Windows Server 2016 Remote Desktop Session Hosts and single-use desktops

Two major vSphere 6.5 enhancements that impact Horizon were also highly touted yesterday.  The first is access to the Horizon API in PowerCLI 6.5.  This was released last week with vSphere 6.5, and both Alan Renouf and Thomas Brown have blog posts on how to access the API.   There is also a Github repository with examples on how to use the API. This has been a long awaited, and oft-requested, feature enhancement for Horizon.  While there has been a View PowerCLI module that’s been included since View 4.5, it was very limited and hadn’t been updated with the new features added to Horizon.  The new API access is very raw, and there are currently only two cmdlets, and these are used for connecting to and disconnecting from the API.  However, I expect significant additions to this in future versions of PowerCLI.

The second big announcement is HA support for vGPU-enabled desktops in vSphere 6.5.  This is a huge announcement for customers that require vGPU for 3D workloads.  In previous versions of vSphere, if a host failed, vGPU-enabled desktops would not restart on another host.  This now provides some method of fault tolerance for these VMs.  vMotion is still not supported, and this is a much harder problem to tackle.

Also included with Horizon 7.0.3 is Access Point 2.8 and vRealize Operations for Horizon 6.4 (release notes).  vRealize Operations for Horizon includes several new features including:

  • Support for monitoring Horizon Access Point – including Access Point health and connection information
  • App Volumes support – monitoring which AppStacks are attached to a user session and how long they took to attach
  • New Widgets and reports on application usages in virtual desktop sessions
  • Support for monitoring Cloud Pod Architecture

App Volumes 2.12 was also released yesterday, and it brings significant improvements to the current branch of the application layering software. (Release notes)(Announcement Blog)

The new features in App Volumes are:

  • Logon Enhancements
  • Support for multiple domain controllers and multiple Active Directory forests and domains
  • Communications between App Volumes Manager and agent now default to HTTPS
  • Certification Validation required for communications between vCenter and App Volumes Manager
  • Support for Office 365 (2016) as an App Stack
  • Support for Windows 10 Anniversary Update (AKA Build 1607)

There are also a couple of new Tech Preview features that can be enabled in the latest version.  These features are:

Horizon 7.0 Part 11–Desktop Pools

If you have ever worked with SCCM, you may have used Collections to group desktops together for application deployments or patch management. Collections provide a way to group users and computers for organization and resource management.

Desktop pools are a similar concept in Horizon. They are a logical grouping of virtual machines that users can access, and these groupings control specific settings about the pool. This includes how the desktops are provisioned and named, protocols that are available for connectivity, and what physical infrastructure they are deployed on. 

Horizon has a few different types of desktop pools.  Each pool handles desktops in different ways, and they each have different purposes.  The type of pool that you select will be determined by a number of factors including the use case, the storage infrastructure and application requirements.

The type of desktop pools are:

  • Full Clone Pools – Each virtual desktop is a full virtual machine cloned from a template in vCenter.  The virtual machines require a desktop management tool for post-deployment management.  VMs are customized using existing Guest Customization Specifications. These desktops usually persist after the user logs out.
  • Linked Clone Pools – Each virtual desktop is based on a parent VM snapshot and shares its disk with the parent virtual machine.  Changes to the linked clone are written to a delta disk.  The virtual machines are managed by View Composer.   Linked Clone desktops can be Floating or Dedicated assignment, and they can be configured to be refreshed (or rolled back to a known good snapshot) or deleted on logoff.
  • Instant Clone Pools – Each virtual desktop is based on a parent VM snapshot. The snapshot is cloned to a VM that is deployed to each host, powered up, and then stunned. All guest VMs are then “forked” from this VM and quickly customized. Guest VMs share virtual disks and initial memory maps with the parent VMs.  VMs are managed by vCenter and a “next generation” Composer that is built into the Connection Servers. There are limitations to Instant Clone desktops including a cap of 2000 desktops per vCenter, no support for GPUs, and can only be used in floating assignment pools.
  • Manual Pools – The machines that make up the manual pool consist of virtual and/or physical machines that have had the View Agent installed.  These machines are not managed by Horizon.
  • Remote Desktop Session Host Pool – The machines that make up these pools are Windows Servers with the Remote Desktop Session Host Role installed.  They can be provisioned as linked clones or manually, and they are used for published desktops and published applications.

There is one other choice that needs to be selected when creating a desktop pool, and that is the desktop assignment type.  There are two desktop assignment types:

  • Floating Assignment – Desktops are assigned to users at login and are returned to the pool of available desktops when the user signs out.
  • Dedicated Assignment – Desktops are assigned to a user, and the user gets the same desktop at each login.  Desktops can be assigned automatically at first login or manually by an administrator.

For this walkthrough, I will be doing an Automatic Floating Assignment Linked-Clone desktop pool, otherwise known as a Non-Persistent Linked Clone Pool.  This type of desktop pool utilizes View Composer and

1. Log into the Horizon 7 Administrator.  Under Catalog, select Desktop Pools.

image

2.  Click Add to add a new pool.

2

3. Select the Pool Type that you want to create.  For this, we’ll select Automated Pool and click Next.

3

4.  Select whether you want to have Floating or Dedicated Desktops.  For this walkthrough, we’ll select Floating and click Next.

4

Note: The Enable Automatic Assignment option is only available if you select Dedicated. If this option is selected, View automatically assigns a desktop to a use when they log in to dedicated pool for the first time.

5. Choose the type of virtual machines that will be deployed in the environment. For this walkthrough, select View Composer Linked Clones and click Next.

5

6. Each desktop pool needs an ID and a Display Name.  The ID field is the official name of the pool, and it cannot contain any spaces.  The Display Name is the “friendly” name that users will see when they select a desktop pool to log into.  You can also add a description to the pool.

6

7. The next screen after setting the pool name is for the pool settings.  There are a lot of options here, that control how the pool will behave.  Some of the options are:

  • If the pool is enabled
  • Default power state of desktops
  • Display protocols
  • Adobe Flash settings

7

8

9

8. The next screen will allow you to configure the provisioning settings for the pool.  This screen allows you to control provisioning behavior, computer names, and the number of desktops provisioned in the pool.

10

9. The next screen allows you to set up a special non-persistent disk for disposable files.  Disposable files are classified as temporary files and page files.  If a disposable disk is used, these files will be redirected to here, and this disk is deleted whenever the VM is shut down.

Note: I don’t recommend the use of disposable file redirection.

This screen allows you to determine how the virtual desktop will handle these files.

11

10. Select the option to store Replicas on a separate datastore if you want to place them on a different storage tier.  Andre Leibovici has a good article on the benefits of placing Linked Clone replicas on a different datastore.

12

11. After you choose whether or not to place the Replica Disks on a separate datastore, you need to configure the pool’s vCenter settings.  This covers the Parent VM and the snapshot that the Linked Clones will be based on, the folder that they will be stored in within vCenter, and the cluster and datastores that will be used.

In order to configure each setting, you will need to click the Browse button on the right hand side of the screen.  Each step must be configured in order.

20

11-A. The first item that needs to be configured is the Parent VM that the Linked Clones will be based on.  Select the VM that you want to use and click OK.

13

11-B. The next step is to select the Parent VM snapshot that the Linked Clones will be based on.  Select the snapshot that you want to use and click OK.

14

11-C. After you have selected a Parent VM and a snapshot, you need to configure the vCenter folder in the VMs and Templates view that the VMs will be placed in.  Select the folder and click OK.

15

11-D. The next step is to place the pool on a vSphere cluster.  The virtual machines that make up the desktop pool will be run on this cluster, and the remaining choices will be based on this selection.  Select the cluster that they should be run on and click OK.

16

11-E. The next step is to place the desktops into a Resource Pool.  In this example, I have not resource pools configured, so the desktops would be placed in the Cluster Root.

17

11-F. The final two steps of this section are to select the datastores where the Linked Clones and the Replicas will be stored.  Linked Clones can be stored on multiple datastores, so you can select multiple datastores in this section.  You can also configure View to allow the datastores to be overcommitted by changing the Storage Overcommit option on each datastore.

18

11-G. Replicas can only be stored on a single datastore.  Select the datastore that you want to store them on and click OK.

19

Note: After you have configured the Replica Datastore, you may receive the following warning about storing Replicas and Linked Clones on local datastores.  If you are using a SAN or a NAS and not storing any Replicas or Linked Clones on local datastores, you can ignore this message.

Warning after 18-19

12. The next screen is for configuring the advanced storage options.  The three options that can be configured on this screen are the View Storage Accelerator, disk space reclaimation and the option to use native NFS snapshots.

If you use View Storage Accelerator or disk space reclamation, you can configure blackout times where vCenter will not run these tasks as these tasks may generate a significant amount of storage IO. 

22

13. To set the blackout times for the pool, click the Add Button and select the days and times when you do not want these operations to run.  You can set multiple schedules.

21

14. After you have configured the advanced storage options, you need to configure the Guest Customization settings.  This screen allows you to select the domain and organizational unit for the desktops and whether Sysprep or Quickprep will be used to prepare the desktops.

24

15. Review the settings for the pool and verify that everything is correct.  Before you click Finish, check the Entitle Users checkbox in the upper right.  This will allow you to select the users and/or groups who have permission to log into the desktops.

If you need to make a change to the pool settings, the left-hand column contains links to each page in the wizard.

25

17. After you click Finish, you will need to grant access to the pool.  View allows you to entitle Active Directory users and groups.  Click Add to entitle users and groups.

27

18. Search for the user or group that you want to add to entitle.  If you are in a multi-domain environment, you can change domains by selecting the domain from the Domains box.  Click on the users or groups that you want to grant access to and click OK.

26

Note:  I recommend that you create Active Directory security groups and entitle those to desktop pools.  This makes it easier to manage a user’s pool assignments without having to log into View Administrator whenever you want to make a change.

19. You can check the status of your desktop pool creation in vCenter.  If this is a new pool, it will need to clone the VM into a Replica before it can create the Linked Clone desktops. 

28

Once the desktops have finished composing, you will be able to log into them through VMware Blast or the Horizon client. 

I realize that there are a lot of steps in the process of creating a desktop pool.  It doesn’t take nearly as long as it seems once you get the hang of it, and you will be able to fly through it pretty quickly.

Horizon 7.0 Part 10–Building Your Desktop Golden Images

A virtual desktop environment is nothing without virtual desktops.  Poorly performing virtual desktops and applications, or virtual desktops and remote desktop session hosts that aren’t configured properly for the applications that are being deployed, can turn users off to modern end user computing solutions and sink the project.

How you configure your desktop base image can depend on the type of desktop pools that you plan to deploy.  The type of desktop pools that you deploy can depend on the applications and how you intend to deploy them.  This part will cover how to configure a desktop base image for non-persistent desktop pools, and the next part in this series will cover how to set up both linked and instant clone desktop pools.

Before You Begin, Understand Your Applications

Before we begin talking about how to configure the desktop base image and setting up the desktop pools, its very important to understand the applications that you will be deploying to your virtual desktops.  The types of applications and how they can be deployed will determine the types of desktop pools that can be used.

A few factors to keep in mind are:

  • Application Delivery – How are the applications going to be delivered to the desktop or RDSH host?
  • User Installed Applications – Will users be able to install their own applications?  If so, how are applications managed on the desktop?
  • User Profiles – How are the user profiles and settings being managed?  Is there any application data or setting that you want to manage or make portable across platforms?
  • Licensing – How are the applications licensed?  Are the licenses locked to the computer in some way, such as by computer name or MAC address?  Is a hardware key required?
  • Hardware – Does the application require specific hardware in order to function, or does it have high resource requirements?  This is usually a consideration for high-end CAD or engineering applications that require a 3D card, but it could also apply to applications that need older hardware or access to a serial port.

Application management and delivery has changed significantly since I wrote the Horizon 6.0 series.  When that series was written, VMware had just purchased Cloud Volumes, and it hadn’t been added into the product suite.  Today, App Volumes is available in the Horizon Suite Enterprise SKU, and it provides application layering capabilities in Horizon.  Application layering allows administrators to place applications into virtual disk files that get attached at logon, and this allows you to create a single master golden image that has applications added when the user logs in.  If you don’t have the Horizon Suite Enterprise SKU, there are a few other players in the application layering space such as Liquidware Labs FlexApp and Unidesk, and these tools also provide the ability to abstract your applications from the underlying operating system.

Application layering isn’t the only delivery mechanism.  App Virtualization, using tools like ThinApp, Microsoft AppV, or Turbo, is one option for providing isolated applications.  Reverse layering has all applications installed into the golden template, and applications are exposed on a per-user basis. This is the concept behind tools like FSLogix.  Publishing applications to virtual desktops using XenApp or Horizon Published Applications is an option that places the applications on a centralized server, or you could just install some or all of your applications into the golden image and manage them with tools like Altiris or SCCM.

All of these options are valid ways to deliver applications to virtual desktops, and you need to decide on which methods you will use when designing your desktop golden images and desktop pools.  There may not be a single solution for delivering all of your applications, and you may need to rely on multiple methods to meet the needs of your users.

Supported Desktop Operating Systems

Horizon 7.0 supports desktops running Windows and Linux.  The versions of Windows that are supported for full clone and linked clone desktops are:

  • Windows 10 Enterprise (including the Long Term Servicing Branch and Anniversary Update in Horizon 7.0.2)
  • Windows 8.1 Enterprise or Professional
  • Windows 8 Enterprise or Professional
  • Windows 7 SP1 Enterprise or Professional
  • Windows Server 2008 R2 (RDSH and Server-based Desktop)
  • Windows Server 2012 R2 (RDSH and Server-based Desktop)

In order to run desktops on Windows Server-based OSes, you need to enable the “Enable Windows Server desktops” setting under View Configuration –> Global Settings and install the Desktop Experience feature after installing the OS.  There are some benefits to using Windows Server for your desktop OS including avoiding the Microsoft VDA tax on desktop VDI.  The choice to use a server OS vs. a desktop OS must be weighed carefully, however, as this can impact management and application compatibility.

Instant clone desktops are supported on the following operating systems:

  • Windows 10 Enterprise
  • Windows 7 SP1 Enterprise or Professional

The Horizon Linux agent is supported on the following 64-bit versions:

  • Ubuntu 14.04 (note: VMware recommends disabling Compviz due to performance issues)
  • Ubuntu 12.04
  • RHEL and CentOS 6.6
  • RHEL and CentOS 7.2
  • NeoKylin 6 Update 1
  • SLES 11 SP3/SP4
  • SLES 12 SP1

The Linux component supports both full clone and linked clone desktops in Horizon 7.0.1.  However, there are a number of additional requirements for Linux desktops, so I would recommend reading the Setting Up Horizon 7 Version 7.0.1 for Linux Desktops guide.

For this part, we’re going to assume that we’re building a template running a desktop version of Windows.  This will be more of a high-level overview of creating a desktop template for Horizon, and I won’t be doing a step-by-step walkthrough of any of the steps for this section.  Once the desktop image is set up, I’ll cover some of the ways to optimize the desktop templates.

Configure the VM

Building a desktop VM isn’t much different than building a server VM.  The basic process is create the VM, configure the hardware, install the operating system, and then install your applications.  Although there are a few additional steps, building a desktop VM doesn’t deviate from this.

You should base the number of vCPUs and the amount of RAM assigned to your virtual desktops on the requirements for of the applications that you plan to run and fine tune based on user performance and resource utilization.   Horizon doesn’t allow you to set the CPU and RAM allocation when deploying desktop pools, so these need to be set on the template itself.

The recommended hardware for a virtual desktop is:

  • SCSI Controller – LSI SAS
  • Hard Disk – At least 40GB Thin Provisioned
  • NIC – VMXNET3
  • Remove Floppy Drive, and disable parallel and serial ports in BIOS
  • Remove the CD-ROM drive if you do not have an alternative method for installing Windows.

Note: You cannot remove the CD-ROM drive until after Windows has been installed if you are installing from an ISO.

BIOS Settings
BIOS screen for disabling Serial and Parallel ports and floppy controller

You’ll notice that I didn’t put minimums for vCPUs and RAM.  Sizing these really depends on the requirements of your user’s applications.  I’ve had Windows 7 64-bit desktops deployed with as little as 1GB of RAM for general office workers up to 4GB of RAM for users running the Adobe Suite.  Generally speaking, customers are deploying knowledge or task worker desktops with at least 2 vCPUs and between 2-4 GB of RAM, however the actual sizing depends on your applications.

Install Windows

After you have created a VM and configured the VM’s settings, you need to install Windows.  Again, it’s not much different than installing Windows Server into a VM or installing a fresh copy of Windows onto physical hardware.  You can install Windows using the ISO of the disk or by using the Microsoft Deployment Toolkit and PXE boot to push down an image that you’ve already created.

When installing Windows for your desktop template, you’ll want to make sure that the default 100 MB system partition is not created.  This partition is used by Windows to store the files used for Bitlocker.  Since Bitlocker is not supported on virtual machines by either Microsoft or VMware, there is no reason to create this partition.  This will require bypassing the installer and manually partitioning the boot drive.  The steps for doing this when installing from the DVD/ISO are:

1. Boot the computer to the installer
2. Press Shift-F10 to bring up the command prompt
3. Type DiskPart
4. Type Select Disk 0
5. Type Create Partition Primary
6. Type Exit twice.

diskpart

Once you’ve set up the partition, you can install Windows normally.  If you’re using something like the Microsoft Deployment Toolkit, you will need to configure your answer file to set up the proper hard drive partition configuration.

Install VMware Tools and Join the Template to a Domain

After you have installed Windows, you will need to install the VMware tools package.  The tools package is required to install the View Agent.  VMware Tools also includes the VMXNET3 driver, and your template will not have network access until this is installed.   The typical installation is generally all that you will need unless you’re using Guest Introspection as part of  NSX or your antivirus solution.

After you have installed VMware Tools and rebooted the template, you should join it to your Active Directory domain.  The template doesn’t need to be joined to a domain, but it makes it easier to manage and install software from network shares.  I’ve also heard that there are some best practices around removing the computer from the domain before deploying desktop pools.  This is an optional task, and it’s not required.  I’ve never removed the machines from the domain before provisioning, and I haven’t experienced any issues.

Install The Horizon Agent

After you have installed the VMware tools package and joined your computer to the domain, you will need to install the VMware Horizon Agent.  There are a number of new features in the Horizon 7 Agent install, and not all features are enabled by default.  Be careful when enabling or disabling features as this can have security implications.

One thing to note about the Horizon 7 agent is that there is a Composer component and an Instant Clones component.  These items cannot be installed together.  A desktop template can only be used for Linked Clones or Instant Clones.

Installing Applications on the Template

After you install the Horizon Agent, you can begin to install the applications that your users will need when they log into Horizon View.

With tools like Thinapp available to virtualize Windows applications or layering software like FlexApp, Unidesk and App Volumes, it is not necessary to install all of your applications in your template or to create templates for all of the different application combinations.  You can create a base template with your common applications that all users receive and then either virtualize or layer your other applications so they can be delivered on demand.

“Finalizing” the Image

Once you have the applications installed, it is time to finalize the image to prepare it for Horizon.  This step involves disabling unneeded services and making configuration settings changes to ensure a good user experience.   This may also involve running antivirus or other malware scans to ensure that only new or changed files are scanned after the image is deployed (Symantec…I’m looking at you for this one).

VMware has released a white paper that covers how to optimize a Windows-based virtual desktop or RDSH server.  Previous versions of this white paper have focused on making changes using a PowerShell or batch script.   VMware has also released a fling, the OS Optimization Tool, with a graphical interface that can simplify the optimization process.  Whenever possible, I recommend using the fling to optimize virtual desktop templates.  It not only provides an easy way to select which settings to apply, but it contains templates for different operating systems.  It also provides a way to log which changes are made and to roll back unwanted changes.

Prior to optimizing your desktops, I recommend taking a snapshot of the virtual machine.  This provides a quick way to roll back to a clean slate.  I recommend applying most of the defaults, but I also recommend reading through each change to understand what changes are being made.  I do not recommend disabling the Windows Firewall at all, and I don’t recommend disabling Windows Update as this can be controlled by Group Policy.

Before you shut the virtual machine down to snapshot it, verify that any services required for applications are enabled.  This includes the Windows Firewall service which is required for the Horizon Agent to function properly.

Shutdown and Snapshot

After you have your applications installed, you need to shut down your desktop template and take a snapshot of it.  If you are using linked clones, the linked clone replica will be based on the snapshot you select.

That’s a quick rundown of setting up a desktop template to be used with Horizon desktops.

In the next part of this series, I’ll cover how to create desktop pools.

Horizon 7.0 Part 9–Configuring Horizon for the First Time

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

Logging into the Horizon Administrator

Before anything can be configured, though, we need to first log into the Horizon Administrator management interface.  This management interface is based on the Adobe Flex platform, so Flash will need to be installed on any endpoints you use to administer the environment.

The web browsers that VMware currently supports, with Adobe Flash 10.1 or later are:

  • Internet Explorer 9-11
  • Firefox
  • Chrome
  • Safari 6
  • Microsoft Edge

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.

1. Login

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

2. License pt 1

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 desktops or published applications 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.

3. License pt 2

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.

4. License pt 3

Configuring Horizon for the First Time

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

1.   Expand View Configuration and select Servers.

3

2.  Select the vCenter Servers tab and select Add…

4

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.

6

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.

7

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.

8

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.

9

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.

11

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.

10

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.

12

10. Review the settings and click finish.

13

Configuring the Horizon Events Database

The last thing that we need to configure is the Horizon 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.

4. Event Configuration

2. In the Event Database section, click Edit.

5. View Events Database Section

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)

6. Edit Events Database Settings

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.

7a. Bad Username or Password

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.

7b. Success!

Horizon 7.0 Part 8 – Installing The First Connection Server

Connection Servers are one of the most important components in any Horizon environment, and they come in three flavors – the standard Connection Server, the Replica Connection Server, and the Security Server. 

You may have noticed that I listed two types of connection servers.  The Standard and Replica Connection Servers have the same feature set, and the only difference between the two is that the standard connection server is the first server installed in the pod.  Both connection server types handle multiple roles in the Horizon infrastructure.   They handle primary user authentication against Active Directory, management of desktop pools, provide a portal to access desktop pools and published applications, and broker connections to desktops, terminal servers, and applications.  The connection server’s analog in Citrix environments would be a combination of Storefront and the Delivery Controller.

The Security Server is a stripped down version of the regular Connection Server designed to provide secure remote access.  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.  Unlike previous versions of this walkthrough, I won’t be focusing on the Security Server in the remote access section as VMware now provides better tools.

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 at least 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-7.x.x-xxxxxxx.exe.

2. Click Next on the first screen to continue.

1

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

2

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

3

5. Select the type of Connection Server that you’ll be installing.  For this section, we’ll select the Horizon 7 Standard Server.  If you plan on allowing access to desktops through an HTML5 compatible web browser, select “Install HTML Access.”  Select the IP protocol that will be used to configure the Horizon environment.  Click Next to continue.

4

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.

5

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.

6

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.  The Windows Firewall should not be disabled even if Security Servers and IPSEC are not required.

8. The installer will prompt you to select the default Horizon 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.

7

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.

8

10. Click Install to begin the installation.

9

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

10

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 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 the next part.