Month: June 2016

Horizon 7.0 Part 5–SSL Certificates

/ seanpmassey

SSL certificates are an important part of all Horizon 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, communications between servers will break down.  This also impacts client connectivity – by default, the Horizon client will not connect to Connection Servers, Security Servers, or Access Points unless users change the SSL settings.

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 commercial certificate from one of the major certificate providers, you can use a free certificate authority such as StartSSL or a low-cost certificate provider such as NameCheap. 

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.  If you are unable to do this, you can use the web certificate template for all Horizon certificates.

Creating The Certificate Request

Horizon 7.0 handles certificates on the Windows Server-based components the same way as Horizon 6.x and Horizon 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 Horizon environment.  There are a couple of ways to go about doing this.

1. If you haven’t installed the Horizon Connection Server 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 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 requires the Connection Server 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 Horizon service on the server

2

Certificates and Horizon Composer

Unfortunately, Horizon 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 Horizon 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 Horizon 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 Horizon 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 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 client.

Access Point Certificates

Unlike Connection Servers and Composer, Horizon Access Point does not run on Windows.  It is a Linux-based virtual appliance, and it requires a different certificate management technique.  The certificate request and private key file for the Access Point should be generated with OpenSSL, and the certificate chain needs to be concatenated into a single file.  The certificate is also installed during, or shortly after, deployment using Chris Halstead’s fling or the appliance REST API. 

Because this is an optional component, I won’t go into too much detail on creating and deploying certificates for the Access Point in this section.  I will cover that in more detail in the section on deploying the Access Point appliance later in the series.

Introducing StacksWare

/ seanpmassey

Who uses this application?  How often are they using it?  Are we getting business value out of the licensing we purchased?  Is our licensing right-sized for our usage or environment?  How do we effectively track application usage in the era of non-persistent virtual desktops with per-user application layers?

These are common questions that the business asks when planning for an end-user computing environment, when planning to add licenses, or when maintenance and support are up for renewal.  They aren’t easy questions to answer either, and while IT can usually see where applications are installed, it’s not always easy to see who is using them and  how often they are being used.

The non-persistent virtual desktop world also has it’s own challenges.  The information required to effectively troubleshoot problems and issues is lost the minute the user logs out of the desktop.

Most tools that cover the application licensing compliance and monitoring space are difficult to set up and use.

I ran into StacksWare in the emerging vendors section at last year’s VMworld, and their goal is to address these challenges.  Their goal is to provide an easy-to-use tool that provides real-time insight into the   The company  was started as a research project at Stanford University that was sponsored by Sanjay Poonen of VMware, and it has received $2 million in venture capital funding from Greylock and Lightspeed.

StacksWare is a cloud-based application that uses an on-premises virtual appliance to track endpoints, users, and applications.  The on-premises portion integrates with vSphere and Active Directory to retrieve information about the environment, and data is presented in a cloud-based web interface.

It offers an HTML5 interface with graphs that update in real-time.  The interface is both fast and attractive, and it does not offer a lot of clutter or distraction.  It’s very well organized as well, and the layout makes it easy to find the information that you’re looking for quickly.

image

Caption: The StacksWare main menu located on the left side of the interface.

image

Caption: Application statistics for a user account in my lab.

image

Caption: Application list and usage statistics.

StacksWare can track both individual application usage and application suite usage.  So rather than having to compile the list of users who are using Word, Excel, and PowerPoint individually, you can track usage by the version of the Microsoft Office Suite that you have installed.  You can also assign license counts, licensing type, and costs associated with licensing.  StacksWare can track this information and generate licensing reports that can be used for compliance or budgetary planning.

image

Caption: The license management screen

One thing I like about StacksWare’s on-premises appliance is that it is built on Docker.  Upgrading the code on the local appliance is as simple as rebooting it, and it will download and install any updated containers as part of the bootup process.  This simplifies the updating process and ensures that customers get access to the latest code without any major hassles.

One other nice feature of StacksWare is the ability to track sessions and activity within sessions.  StacksWare can show me what applications I’m launching and when I am launching them in my VDI session. 

image

Caption: Application details for a user session.

For more information on StacksWare, you can check out their website at www.stacksware.com.  You can also see some of their newer features in action over at this YouTube video.  StacksWare will also be at BriForum and VMworld this year, and you can check them out in the vendor solutions area.

Full-Stack Engineering Starts With A Full-Stack Education

/ seanpmassey

A few weeks ago, my colleague Eric Shanks wrote a good piece called “So You Wanna Be  A Full Stack Engineer…”  In the post, Eric talks about some the things you can expect when you get into a full-stack engineering role. 

You may be wondering what exactly a full-stack engineer is.  It’s definitely a hot buzzword.  But what does someone in a full-stack engineering role do?  What skills do they need to have? 

The closest definition I can find for someone who isn’t strictly a developer is “an engineer who is responsible for an entire application stack including databases, application servers, and hardware.”  This is an overly broad definition, and it may include things like load balancers, networking, and storage.  It can also include software development.  The specifics of the role will vary by environment – one company’s full-stack engineer may be more of an architect while another may have a hands-on role in managing all aspects of an application or environment.  The size and scope of the environment play a role too – a sysadmin or developer in a smaller company may be a full-stack engineer by default because the team is small.

However that role shakes out, Eric’s post gives a good idea of what someone in a full-stack role can expect.

Sounds fun, doesn’t it?  But how do you get there? 

In order to be a successful full-stack engineer, you need to get a full-stack education.  A full-stack education is a broad, but shallow, education in multiple areas of IT.    Someone in a full-stack engineering role needs to be able to communicate effectively with subject-matter experts in their environments, and that requires knowing the fundamentals of each area and how to identify, isolate, and troubleshoot issues. 

A full-stack engineer would be expected to have some knowledge of the following areas:

  • Virtualization: Understanding the concepts of a hypervisor, how it interacts with networking and storage, and how to troubleshoot using some basic tools for the platform
  • Storage: Understanding the basic storage concepts for local and remote (SAN/NAS) storage and how it integrates with the environment.  How to troubleshoot basic storage issues.
  • Network: Understand the fundamentals of TCP/IP, how the network interacts with the environment,and the components that exist on the network.  How to identify different types of networking issues using various built-in tools like ping, traceroute, and telnet.
    Networking, in particular, is a very broad topic that has many different layers where problems can occur.  Large enterprise networks can also be very complex when VLANs, routing, load balancers and firewalls are considered.  A full-stack engineer wouldn’t need to be an expert on all of the different technologies that make up the network, but one should have enough networking experience to identify and isolate where potential problems can occur so they can communicate with the various networking subject matter experts to resolve the issue.
  • Databases: Understand how the selected database technology works, how to query the database, and how troubleshoot performance issues using built-in or 3rd-party database tools.  The database skillset can be domain-specific as there are different types of databases (SQL vs. No-SQL vs. Column-Based vs. Proprietary), differences in the query languages between SQL database vendors (Oracle, MS SQL Server, and PostgreSQL) and how the applications interact with the database.
  • Application Servers: Understand how to deploy, configure, and troubleshoot the application servers.  Two of the most important things to note are the location of log files and how it interacts with the database (ie – can the application automatically reconnect to the database or does it need to be restarted). This can also include a middleware tier that sits between the application servers  The skills required for managing the middleware tier will greatly depend on the application, the underlying operating system, and how it is designed. 
  • Operating Systems: Understand the basics of the operating system, where to find the logs, and how to measure performance of the system.
  • Programming: Understand the basics of software development and tools that developers use for maintaining code and tracking bugs.  Not all full-stack engineers develop code, but one might need to check out production ready code to deploy it into development and production environments.  Programming skills are also useful for automating tasks, and this can lead to faster operations and fewer mistakes.

Getting A Full-Stack Education

So how does one get exposure and experience in all of the areas above?

There is no magic bullet, and much of the knowledge required for a full-stack engineering role is gained through time and experience.  There are a few ways you can help yourself, though.

  • Get a theory-based education: Get into an education program that covers the fundamental IT skills from a theory level.  Many IT degree programs are hands-on with today’s hot technologies, and they may not cover the business and technical theory that will be valuable across different technology silos.  Find ways to apply that theory outside of the classroom with side projects or in the lab.
  • Create learning opportunities: Find ways to get exposure to new technology.  This can be anything from building a home lab and learning technology hands-on to shadowing co-workers when they perform maintenance.
  • Be Curious: Don’t be afraid to ask questions, pick up a book, or read a blog on something you are interested in and want to learn.

Horizon 7.0 Part 4–Active Directory Design Considerations

/ seanpmassey

Traditionally, virtual desktops run Windows, and the servers that provide the virtual desktop infrastructure services also run on Windows.  Because of the heavy reliance on Windows, Active Directory plays a huge role in Horizon environments.  Even Linux desktops, which are a new option, can be configured for Active Directory and utilize the Horizon user’s AD credentials for Single Sign-On. 

When you’re planning a new Horizon deployment, or re-architecting 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 Horizon 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 Desktops and desktop templates 
  • Basic Group Policy Objects for the different organizational units
  • An organization unit for Microsoft RDS servers if published apps or RDSH-desktops are deployed

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 DESKTOPS

The first think that we need to do to prepare Active Directory for a Horizon 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 desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the Horizon Composer and/or Instant Clones Administrator service account.

There are a lot of ways that you can set up an Active Directory OU structure for Horizon.  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.

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 use-case specific OUs for pools that require additional Group Policy options above and beyond the top-level. These grandchild OUs are completely optional.  If there is no need to set any custom policy for a specific use case, 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.

I’ve found that there is less of a need for these use-case specific OUs as I’ve learned more about modern UEM tools like RES and VMware User Environment Manager.  These tools can be a scalpel that allow administrators to dynamically apply context-aware policies and settings to specific users or groups without having to create additional pools or OUs for Group Policy configurations.

Creating an Organizational Unit for RDS Servers

Horizon 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.

RDSH 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. Since RDSH servers are often heavily locked down through Group Policy, I also recommend creating an RDSH Maintenance Mode OU.  This OU is where RDSH servers can be placed when administrators need to remove restrictive group policies such blocking the command prompt or MSI installers removed to perform maintenance on the server.

Horizon Group Policy Objects

Horizon 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 and templates is same as what was available in Horizon 6.

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 Service Accounts

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

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

Horizon 7.0 Part 3–Desktop Design Considerations

/ seanpmassey

Whether it is Horizon, XenDesktop, or a cloud-based Desktop-as-a-Service provider, the implementation of a virtual desktop and/or published applications 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 the solution.

So before we move into installing the actual components for a Horizon environment, we’ll spend the next two posts on design considerations.  This post, Part 3, will discuss design considerations for the Horizon 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 four types of desktops in Horizon 7:

  • Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
  • Linked Clone Desktops – 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 Composer.
  • Instant Clone Desktops – Instant Clone desktops are new to Horizon 7, and they are built off of the VMfork technology introduced with vSphere 6.0.  Instant Clones are essentially a rapid clone of a running virtual machine with extremely fast customization.
  • Remote Desktop Session Host Pools – Horizon 6 expanded RDSH support 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.

Understanding Use Cases

When you design a virtual desktop environment, you have to design around the use cases.  Use cases are the users, applications, peripherals, and how they are used to complete a task, and they are used to define many of the requirements in the environment.  The requirements of the applications in the type of desktops that are used and how they are assigned to users.

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.

Other factors that may impact the use cases or the desktop design decisions include existing management tools, security policies, and other policies.

Once you have determined your use cases and the impacts that the use cases have on desktop design, 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 Servers needed
  • The remote access delivery method

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.

The conceptual and logical designs, built on details from the use cases, will influence 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 7.  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 environments.

Horizon 7.0 Part 2–Horizon Requirements

/ seanpmassey

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

The Basics

The smallest Horizon 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 Horizon 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, user authentication and access.  They also manage connections to multi-user desktops and published applications.   Connection Servers also manage the

There are four types of Connection Server roles, and all four roles have the same requirements.  These roles are:

  • Standard Connection Server – The first Connection Server installed in the environment.
  • Replica Connection Server – Additional Connection Servers that replicate from the standard connection server
  • Security Server – A stripped down version of the Connection Server, designed to sit in the DMZ and proxy traffic to the Connection Servers.  A Security Server must be “paired” with a Connection Server.
  • Enrollment Server – A new role introduced in Horizon 7.  The Enrollment Server is used to facilitate the new True SSO feature.

The requirements for a Connection Server are:

  • 1 CPU, 4 vCPUs recommended
  • 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
  • Static IP Address

Note: The requirements for the  Security Server  and Enrollment Server are the same as the requirements for Connection Server.  Security Servers do not need to be 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 7 can be found in the VMware compatibility matrix.  ESXi 5.0 Update 1 and newer, excluding ESXi 5.5 vanilla, are currently supported.  However, ESXi 6.0 Update 1 and newer are required for Instant Clones.

vCenter Server – The versions of vCenter that are supported by Horizon 7 can be found in the VMware compatibility matrix.  vCenter Server 5.0 Update 1 and newer, excluding vCenter 5.5 vanilla, are currently supported, and vCenter 6.0 Update 1 and newer are required to support Instant Clones.  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 the domain must be set to at least the Server 2008 functional level.  Group Policy is used for configuring parts of the environment, including desktop settings, roaming profiles, user data redirection, UEM, and the remoting protocol.   

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 – There are a couple of options for providing secure remote access to virtual desktops and published applications.  Traditionally, remote access has been provided by the Horizon Security Server.  The Security Server is a stripped down version of the connection server that is designed to be deployed into a DMZ.  It also requires each server to be paired with a Connection Server.

There are two other remote access options.  The first is the Horizon Access Point.  The access point comes from the Horizon Air platform, and it was introduced in the on-premises solution in Horizon 6.2.2.  The Access Point is a hardened Linux appliance that is designed to be managed like a cloud appliance, and it serves the same function as the Security Server.  Unlike the Security Server, the Access Point does not need to be paired with a Connection Server.

Both the Security Server and the Access Point can be load balanced for high availability.

The other remote access option is the Horizon proxy built into the F5 APM module.  The APM module combines load balancing and rule-based secure remote access.  It can also replace the portal feature in vIDM.

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 Horizon Composer.

The requirements for Horizon Composer are:

  • 2 vCPUs, 4 vCPUs recommended 
  • 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.
  • Static IP Address

Horizon Composer also requires a database.  The database requirements can be found in the VMware Product Interoperability Matrix.  The current requirements include SQL Server 2014 (RTM and SP1), SQL Server 2012 (SP2) and Oracle 12c Release 1.

Networking Requirements – Horizon requires a number of ports to be opened to allow the various components of the infrastructure to communicate.  The best source for showing all of the ports required by the various components is the VMware Horizon 7 Network Ports diagram.  It’s available in PDF format from here.

Other Components:  The Horizon Suite includes a number of tools to provide administrators with a full-fledged ecosystem for managing their virtual end-user computing environments.  These tools are App Volumes, User Environment Manager, VMware Identity Manager (vIDM), and vRealize Operations for Horizon.  The requirements for these tools will be covered in their respective sections.

Horizon 7.0 Part 1–Introduction

/ seanpmassey

I realize that this series might seem like it’s a little late.  After all, Horizon 7.0 has been out for a few months now.  But between a very large writing project and wanting to take a few weeks off from writing, it’s time to get started with the comprehensive Horizon 7.0 series.

There have been a lot of updates and new features added to Horizon 7.0, and I covered most of those updates in a post back in February after the initial Horizon 7 announcement.  The major features are:

  • Instant Clones – New Provisioning Method
  • Blast Extreme – New Remoting Protocol
  • UEM Smart Policies – New Context Aware Policy Management

Those are just what I consider the major features that will impact most deployments.  There are a lot of other improvements as well, including improvements to scalability through CloudPod, security through True SSO, and new client redirection features to support additional use cases.

Unlike my previous series, I plan to go beyond installing the core Horizon 7.0 components.  This year, I hope to cover Access Point, RDSH, UEM, vRealize Operations for Horizon, and the latest version of App Volumes.  No, that won’t be App Volumes 3.0.  But I could cover that too.

Stay tuned.  There will be much more to come.