Month: July 2014

Doing Things Because They Are HARD–My Virtual Design Master Experience

/ seanpmassey

“We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too. “

– John Fitzgerald Kennedy, September 12th, 1962

If you haven’t noticed, the frequency of my posts has dropped off quite a bit.  It’s surprising, even to me, since Horizon View 6.0 just came out.

My time, over the last couple of weeks, has been occupied by a few tasks.  Most of that time has been occupied by the Virtual Design Master competition.

What is Virtual Design Master?

Virtual Design Master is a community-run Internet “reality show,” now in it’s second season, that showcases the infrastructure design skills of the contestants.  It’s one part Chopped, one part Iron Chef, and one part The Walking Dead. 

Contestants are tasked with putting together a formal design, following a design methodology, on an open-ended but challenging problem surrounding the storyline for the season.  All decisions must be justified and design decisions documented.

Oh…and did I mention that you have four days to do it?

Each week, the participants have to defend their design to noted members of the virtualization community and get feedback on the choices they made.

Why do it?

Virtual Design Master can be hard and stressful.  There is a lot to learn in a short period of time, and it has to be balanced with family, work, and anything else going on in life.

The challenges can require cutting edge, or even bleeding edge, technology that needs to be learned in a few days.  For instance, one of the constraints of the moonbase challenge was working with an IPv6-only network.  The design had to identify which components would not work with IPv6 or would require a dual-stack approach and design around it.  Other constraints on that challenge required participants to learn about technology that they might not have used on a daily basis.

It also forces you to document your design with a formal design document.  The document isn’t a simple two to three page abstract but a detailed document outlining the design decisions, components, justifications, and component configurations as they are intended to be implemented.

Although the process of designing an infrastructure and documenting it in a short period for the competition can be challenging, it’s not nearly as bad as it sounds.

The community around the competition is great, and competitors are more than willing to help each other with questions on equipment and design reviews.  Answers to questions are a tweet or an email away.

But the takeaway that I found most useful was learning how to write a design document.  Prior to participating, I had never written a formal design.  In the two weeks of Virtual Design Master, I’ve written two that were longer and more elaborate than any design documentation I had seen for a project that I participated in.

Writing documentation has some secondary benefits as well.  It makes you think about your design and how you would explain it.  That makes it easier to explain, and eventually, defend.  This, in turn, makes it easier to answer the question “If I was hit by a bus, what would my replacement need to know?”

Takeaways

I started this post with an excerpt from a speech by President Kennedy where he announced his vision of putting a man on the moon within a decade.  There is one segment of that speech that really sums up what this competition does:

“…not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills…”

Participating in Virtual Design Master is a lot of fun and a great learning experience.  But it also challenges you, organizes you, and prepares you for bigger things.

As John Arrasjid said:

It is great practice for taking your skills to the next level, learning, and engaging the community.

Horizon View 6.0 Part 4–Active Directory Configuration

/ seanpmassey / 1 Comment

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

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

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

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

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

Creating An Organizational Unit for Horizon View Desktops

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

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

2013-12-28_21-55-14

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

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

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

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

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

Creating an Organizational Unit for RDS Servers

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

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

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

Horizon View Group Policy Objects

Horizon View contains a number of custom group policy objects that can be used for configuring features like Persona Management and optimizing the PCoIP protocol.  The number of Group Policy objects has been increased in Horizon View 6, and the number of templates has increased as well.

Unfortunately, most of the Group Policy templates are distributed as ADM files.  There are a number of drawbacks to ADM files in modern Active Directory environments.  The main one is that you cannot store the Group Policy files in the Central Store.

If you plan on using the Group Policy templates, it’s a good idea to convert them into the ADMX format.  I had previously written about converting the View Group Policy templates into the ADMX format and the reasons for converting here.

Horizon View Service Accounts

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

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

Horizon View 6.0 Part 3–Desktop Design Considerations

/ seanpmassey / 4 Comments

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

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

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

There are three types of desktops in Horizon View 6:

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

There are two desktop assignment types for desktop pools:

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

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

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

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

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

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

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

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

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

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

Horizon View 6.0 Part 2 – Prerequisites and System Requirements

/ seanpmassey / 3 Comments

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

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

The Basics

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

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

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

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

The requirements for a Connection Server are:

  • 2 CPU
  • Minimum 4GB RAM, 10GB recommended if 50 or more users are connecting
  • Windows Server 2008 R2 or Windows Server 2012 R2
  • Joined to an Active Directory domain
Note: The requirements for the View Security Server are the same as the requirements for View Connection Server minus being joined to an Active Directory domain. 

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

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

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

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

Advanced Features

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

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

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

The requirements for View Composer are:

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

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

Networking

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

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