Getting Started With UEM Part 2: Laying The Foundation – File Services

In my last post on UEM, I discussed the components and key considerations that go into deploying VMware UEM.  UEM is made up of multiple components that rely on a common infrastructure of file shares and Group Policy to manage the user environment, and in this post, we will cover how to deploy the file share infrastructure.

There are two file shares that we will be deploying.  These file shares are:

  • UEM Configuration File Share
  • UEM User Data Share

Configuration File Share

The first of the two UEM file shares is the configuration file share.  This file share holds the configuration data used by the UEM agent that is installed in the virtual desktops or RDSH servers.

The UEM configuration share contains a few important subfolders.  These subfolders are created by the UEM management console during it’s initial setup, and they align with various tabs in the UEM Management Console.  We will discuss this more in a future article on using the UEM Management console.

  • General – This is the primary subfolder on the configuration share, and it contains the main configuration files for the agent.
  • FlexRepository – This subfolder under General contains all of the settings configured on the “User Environment” tab.  The settings in this folder tell the UEM agent how to configure policies such as Application Blocking, Horizon Smart Policies, and ADMX-based settings.

Administrators can create their own subfolders for organizing application and Windows  personalization.  These are created in the user personalization tab, and when a folder is created in the UEM Management Console, it is also created on the configuration share.  Some folders that I use in my environment are:

  • Applications – This is the first subfolder underneath the General folder.  This folder contains the INI files that tell the UEM agent how to manage application personalization.  The Applications folder makes up one part of the “Personalization” tab.
  • Windows Settings – This folder contains the INI files that tell the UEM agent how to manage the Windows environment personalization.  The Windows Settings folder makes up the other part of the Personalization tab.

Some environments are a little more complex, and they require additional configuration sets for different use cases.  UEM can create a silo for specific settings that should only be applied to certain users or groups of machines.  A silo can have any folder structure you choose to set up – it can be a single application configuration file or it can be an entire set of configurations with multiple sub-folders.  Each silo also requires its own Group Policy configuration.

User Data File Share

The second UEM file share is the user data file share.  This file share holds the user data that is managed by UEM.  This is where any captured application profiles are stored. It can also contain other user data that may not be managed by UEM such as folders managed by Windows Folder Redirection.  I’ve seen instances where the UEM User Data Share also contained other data to provide a single location where all user data is stored.

The key thing to remember about this share is that it is a user data share.  These folders belong to the user, and they should be secured so that other users cannot access them.  IT administrators, system processes such as antivirus and backup engines, and, if allowed by policy, the helpdesk should also have access to these folders to support the environment.

User application settings data is stored on the share.  This consists of registry keys and files and folders from the local user profile.  When this data is captured by the UEM agent, it is compressed in a zip file before being written out to the network.  The user data folder also can contain backup copies of user settings, so if an application gets corrupted, the helpdesk or the user themselves can easily roll back to the last configuration.

UEM also allows log data to be stored on the user data share.  The log contains information about activities that the UEM agent performs during logon, application launch and close, and logoff, and it provides a wealth of troubleshooting information for administrators.

UEM Shared Folder Replication

VMware UEM is perfect for multi-site end-user computing environments because it only reads settings and data at logon and writes back to the share at user logoff.  If FlexDirect is enabled for applications, it will also read during an application launch and write back when the last instance of the application is closed.  This means that it is possible to replicate UEM data to other file shares, and the risk of file corruption is minimized due to file locks being minimized.

Both the UEM Configuration Share and the UEM User Data share can be replicated using various file replication technologies.

DFS Namespaces

As environments grow or servers are retired, this UEM data may need to be moved to new locations.  Or it may need to exist in multiple locations to support multiple sites.  In order to simplify the configuration of UEM and minimize the number of changes that are required to Group Policy or other configurations, I recommend using DFS Namespaces to provide a single namespace for the file shares.  This allows users to use a single path to access the file shares regardless of their location or the servers that the data is located on.

UEM Share Permissions

It’s not safe assume that everyone is using Windows-based file servers to provide file services in their environment.  Because of that, setting up network shares is beyond the scope of this post.  The process of creating the share and applying security varies based on the device hosting the share.

The required Share and NTFS/File permissions are listed in the table below. These contain the basic permissions that are required to use UEM.  The share permissions required for the HelpDesk tool are not included in the table.

Share Share Permissions NTFS Permissions
UEMConfiguration Administrators: Full Control

UEM Admins: Change

Authenticated Users: Read

Administrators: Full Control

UEM Admins: Full Control

Authenticated Users: Read and Execute

UserData Administrators: Full Control

UEM Admins: Full Control

Authenticated Users: Change

Administrators: Full Control

UEM Admins: Full Control

Authenticated Users (This folder Only):

Read and Execute

Create Folders/Append Data

Creator Owner (Subfolders and files only):

Full Control

Wrapup and Next Steps

This post just provided a basic overview of the required UEM file shares and user permissions.  If you’re planning to do a multi-site environment or have multiple servers, this would be a good time to configure replication.

The next post in this series will cover the setup and initial configuration of the UEM management infrastructure.  This includes setting up the management console and configuring Group Policy.

VMware Horizon and Horizon Cloud Enhancements – Part 1

This morning, VMware announced enhancements to both the on-premises Horizon Suite and Horizon Cloud product sets.  Although there are a lot of additions to all products in the Suite, the VMware blog post did not go too indepth into many of the new features that you’ll be seeing in the upcoming editions.

VMware Horizon 7.5

Let’s start with the biggest news in the blog post – the announcement of Horizon 7.5.  Horizon 7.5 brings several new, long-awaited, features with it.  Some of these features are:

  1. Support for Horizon on VMC (VMware on AWS)
  2. The “Just-in-Time” Management Platform (JMP)
  3. Horizon 7 Extended Service Branch (ESB)
  4. Instant Clone improvements, including support for the new vSphere 6.7 Instant Clone APIs
  5. Support for IPv4/IPv6 Mixed-Mode Operations
  6. Cloud-Pod Architecture support for 200K Sessions
  7. Support for Windows 10 Virtualization-Based Security (VBS) and vTPM on Full Clone Desktops
  8. RDSH Host-based GPO Support for managing protocol settings

I’m not going to touch on all of these items.  I think the first four are the most important for this portion of the suite.

Horizon on VMC

Horizon on VMC is a welcome addition to the Horizon portfolio.  Unlike Citrix, the traditional VMware Horizon product has not had a good cloud story because it has been tightly coupled to the VMware SDDC stack.  By enabling VMC support for Horizon, customers can now run virtual desktops in AWS, or utilize VMC as a disaster recovery option for Horizon environments.

Full clone desktops will be the only desktop type supported in the initial release of Horizon on VMC.  Instant Clones will be coming in a future release, but some additional development work will be required since Horizon will not have the same access to vCenter in VMC as it has in on-premises environments.  I’m also hearing that Linked Clones and Horizon Composer will not be supported in VMC.

The initial release of Horizon on VMC will only support core Horizon, the Unified Access Gateway, and VMware Identity Manager.  Other components of the Horizon Suite, such as UEM, vRealize Operations, and App Volumes have not been certified yet (although there should be nothing stopping UEM from working in Horizon on VMC because it doesn’t rely on any vSphere components).  Security Server, Persona Management, and ThinApp will not be supported.

Horizon Extended Service Branches

Under the current release cadence, VMware targets one Horizon 7 release per quarter.  The current support policy for Horizon states that a release only continues to receive bug fixes and security patches if a new point release hasn’t been available for at least 60 days.  Let’s break that down to make it a little easier to understand.

  1. VMware will support any version of Horizon 7.x for the lifecycle of the product.
  2. If you are currently running the latest Horizon point release (ex. Horizon 7.4), and you find a critical bug/security issue, VMware will issue a hot patch to fix it for that version.
  3. If you are running Horizon 7.4, and Horizon 7.5 has been out for less than 60 days when you find a critical bug/security issue, VMware will issue a hot patch to fix it for that version.
  4. If you are running Horizon 7.4, and Horizon 7.5 has been out for more than 60 days when you find a critical bug/security issue, the fix for the bug will be applied to Horizon 7.5 or later, and you will need to upgrade to receive the fix.

In larger environments, Horizon upgrades can be non-trivial efforts that enterprises may not undertake every quarter.  There are also some verticals, such as healthcare, where core business applications are certified against specific versions of a product, and upgrading or moving away from that certified version can impact support or support costs for key business applications.

With Horizon 7.5, VMware is introducing a long-term support bundle for the Horizon Suite.  This bundle will be called the Extended Service Branch (ESB), and it will contain Horizon 7, App Volumes, User Environment Manager, and Unified Access Gateway.  The ESB will have 2 years of active support from release date where it will receive hot fixes, and each ESB will receive three service packs with critical bug and security fixes and support for new Windows 10 releases.  A new ESB will be released approximately every twelve months.

Each ESB branch will support approximately 3-4 Windows 10 builds, including any recent LTSC builds.  That means the Horizon 7.5 ESB release will support the Windows 10 1709, 1803, 1809 and 1809 LTSC builds of Windows 10.

This packaging is nice for enterprise organizations that want to limit the number of Horizon upgrades they want to apply in a year or require long-term support for core business applications.  I see this being popular in healthcare environments.

Extended Service Branches do not require any additional licensing, and customers will have the option to adopt either the current release cadence or the extended service branch when implementing their environment.

JMP

The Just-in-Time Management Platform, or JMP, is a new component of the Horizon Suite.  The intention is to bring together Horizon, Active Directory, App Volumes, and User Environment Manager to provide a single portal for provisioning instant clone desktops, applications, and policies to users.  JMP also brings a new, HTML5 interface to Horizon.

I’m a bit torn on the concept.  I like the idea behind JMP and providing a portal for enabling user self-provisioning.  But I’m not sure building that portal into Horizon is the right place for it.  A lot of organizations use Active Directory Groups as their management layer for Horizon Desktop Pools and App Volumes.  There is a good reason for doing it this way.  It’s easy to audit who has desktop or application access, and there are a number of ways to easily generate reports on Active Directory Group membership.

Many customers that I talk to are also attempting to standardize their IT processes around an ITSM platform that includes a Service Catalog.  The most common one I run across is ServiceNow.  The customers that I’ve talked to that want to implement self-service provisioning of virtual desktops and applications often want to do it in the context of their service catalog and approval workflows.

It’s not clear right now if JMP will include an API that will allow customers to integrate it with an existing service catalog or service desk tool.  If it does include an API, then I see it being an important part of automated, self-service end-user computing solutions.  If it doesn’t, then it will likely be another yet-another-user-interface, and the development cycles would have been better spent on improving the Horizon and App Volumes APIs.

Not every customer will be utilizing a service catalog, ITSM tool and orchestration. For those customers, JMP could be an important way to streamline IT operations around virtual desktops and applications and provide them some benefits of automation.

Instant Clone Enhancements

The release of vSphere 6.7 brought with it new Instant Clone APIs.  The new APIs bring features to VMFork that seem new to pure vSphere Admins but have been available to Horizon for some time such as vMotion.  The new APIs are why Horizon 7.4 does not support vSphere 6.7 for Instant Clone desktops.

Horizon 7.5 will support the new vSphere 6.7 Instant Clone APIs.  It is also backward compatible with the existing vSphere 6.0 and 6.5 Instant Clone APIs.

There are some other enhancements coming to Instant Clones as well.  Instant Clones will now support vSGA and Soft3D.  These settings can be configured in the parent image.  And if you’re an NVIDIA vGPU customer, more than one vGPU profile will be supported per cluster when GPU Consolidation is turned on.  NVIDIA GRID can only run a single profile per discrete GPU, so this feature will be great for customers that have Maxwell-series boards, especially the Tesla M10 high-density board that has four discrete GPUs.  However, I’m not sure how beneficial it will be with customer that adopt Pascal-series or Volta-series Tesla cards as these only have a single discrete GPU per board.   There may be some additional design considerations that need to be worked out.

Finally, there is one new Instant Clone feature for VSAN customers.  Before I explain the feature, I can to explain how Horizon utilizes VMFork and Instant Clone technology.  Horizon doesn’t just utilize VMFork – it adds it’s own layers of management on top of it to overcome the limitations of the first generation technology.  This is how Horizon was able to support Instant Clone vMotion when the standard VMFork could not.

This additional layer of management also allows VMware to do other cool things with Horizon Instant Clones without having to make major changes to the underlying platform.  One of the new features that is coming in Horizon 7.5 for VSAN customers is the ability to use Instant Clones across cluster boundaries.

For those who aren’t familiar with VSAN, it is VMware’s software-defined storage product.  The storage boundary for VSAN aligns with the ESXi cluster, so I’m not able to stretch a VSAN datastore between vSphere clusters.  So if I’m running a large EUC environment using VSAN, I may need multiple clusters to meet the needs of my user base.  And unlike 3-tier storage, I can’t share VSAN datastores between clusters.  Under the current setup in Horizon 7.4, I would need to have a copy of my gold/master/parent image in each cluster.

Due to some changes made in Horizon 7.5, I can now share an Instant Clone gold/master/parent image across VSAN clusters without having to make a copy of it in each cluster first.  I don’t have too many specific details on how this will work, but it could significantly reduce the management burden of large, multi-cluster Horizon environments on VSAN.

Blast Extreme Enhancements

The addition of Blast Extreme Adaptive Transport, or BEAT as it’s commonly known, provided an enhanced session remoting experience when using Blast Extreme.  It also required users and administrators to configure which transport they wanted to use in the client, and this could lead to less than optimal user experience for users who frequently moved between locations with good and bad connectivity.

Horizon 7.5 adds some automation and intelligence to BEAT with a feature called Blast Extreme Network Intelligence.  NI will evaluate network conditions on the client side and automatically choose the correct Blast Extreme transport to use.  Users will no longer have to make that choice or make changes in the client.  As a result, the Excellent, Typical, and Poor options are being removed from future versions of the Horizon client.

Another major enhancment coming to Blast Extreme is USB Redirection Port Consolidation.  Currently, USB redirection utilizes a side channel that requires an additional port to be opened in any external-facing firewalls.  Starting in Horizon 7.5, customers will have the option to utilize USB redirection over ports 443/8443 instead of the side channel.

Performance Tracker

The last item I want to cover in this post is Performance Tracker.  Performance Tracker is a tool that Pat Lee demonstrated at VMworld last year, and it is a tool to present session performance metrics to end users.  It supports both Blast Extreme and PCoIP, and it provides information such as session latency, frames per second, Blast Extreme transport type, and help with troubleshooting connectivity issues between the Horizon Agent and the Horizon Client.

Part 2

As you can see, there is a lot of new stuff in Horizon 7.5.  We’ve hit 1900 words in this post just talking about what’s new in Horizon.  We haven’t touched on client improvements, Horizon Cloud, App Volumes, UEM or Workspace One Intelligence yet.  So we’ll have to break those announcements into another post that will be coming in the next day or two.

Getting Started with VMware UEM

One of the most important aspects of any end-user computing environment is user experience, and a big part of user experience is managing the user’s Windows and application preferences.  This is especially true in non-persistent environments and published application environments where the user may not log into the same machine each time.

So why is this important?  A big part of a user’s experience on any desktop is maintaining their customizations.  Users invest time into personalizing their environment by setting a desktop background, creating an Outlook signature, or configuring the applications to connect to the correct datasets, and the ability to retain these settings make users more productive because they don’t have to recreate these every time they log in or open the application.

User settings portability is nothing new.  Microsoft Roaming Profiles have been around for a long time.  But Roaming Profiles also have limitations, such as casting a large net by moving the entire profile (or the App Data roaming folder on newer versions of Windows) or being tied to specific versions of Windows.

VMware User Environment Manager, or UEM for short, is one of a few 3rd-party user environment management tools that can provide a lighter-weight solution than Roaming Profiles.  UEM can manage both the user’s personalization of the environment by capturing Windows and application settings as well as apply settings to the desktop or RDSH session based on the user’s context.  This can include things like setting up network drives and printers, Horizon Smart Policies to control various Horizon features, and acting as a Group Policy replacement for per-user settings.

UEM Components

There are four main components for VMware UEM.  The components are:

  • UEM Management Console – The central console for managing the UEM configuration
  • UEM Agent – The local agent installed on the virtual desktop, RDSH server, or physical machine
  • Configuration File Share – Network File Share where UEM configuration data is stored
  • User Data File Share – Network File Share where user data is stored.  Depending on the environment and the options used, this can be multiple file shares.

The UEM Console is the central management tool for UEM.  The console does not require a database, and anything that is configured in the console is saved as a text file on the configuration file share.  The agent consumes these configuration files from the configuration share during logon and logoff, and it saves the application or Windows settings configuration when the application is closed or when the user logs off, and it stores them on the user data share as a ZIP file.

The UEM Agent also includes a few other optional tools.  These are a Self-Service Tool, which allows users to restore application configurations from a backup, and an Application Migration Tool.  The Application Migration Tool allows UEM to convert settings from one version of an application to another when the vendor uses different registry keys and AppData folders for different versions.  Microsoft Office is the primary use case for this feature, although other applications may require it as well.

UEM also includes a couple of additional tools to assist administrators with maintaining environment.  The first of these tools is the Application Profiler Tool.  This tool runs on a desktop or an RDSH Server in lieu of the UEM Agent.  Administrators can use this tool to create UEM profiles for applications, and it does this by running the application and tracking where the application writes to.  It can also be used to create default settings that are applied to an application when a user launches it, and this can be used to reduce the amount of time it takes to get users applications configured for the first time.

The other support tool is the Help Desk support tool.  The Helpdesk support tool allows helpdesk agents or other IT support to restore a backup of a user settings archive.

Planning for a UEM Deployment

There are a couple of questions you need to ask when deploying UEM.

  1. How many configuration shares will I have, and where will they be placed? – In multisite environments, I may need multiple configuration shares so the configs are placed near the desktop environments.
  2. How many user data shares will I need, and where will they be placed?  – This is another factor in multi-site environments.  It is also a factor in how I design my overall user data file structure if I’m using other features like folder redirection.  Do I want to keep all my user data together to make it easier to manage and back up, or do I want to place it on multiple file shares.
  3. Will I be using file replication technology? What replication technology will be used? – A third consideration for multi-site environments.  How am I replicating my data between sites?
  4. What URL/Name will be used to access the shares? – Will some sort of global namespace, like a DFS Namespace, be used to provide a single name for accessing the shares?  Or will each server be accessed individually?  This can have some implications around configuring Group Policy and how users are referred to the nearest file server.
  5. Where will I run the management console?  Who will have access to it?
  6. Will I configure UEM to create backup copies of user settings?  How many backup copies will be created?

These are the main questions that come up from an infrastructure and architecture perspective, and they influence how the UEM file shares and Group Policy objects will be configured.

Since UEM does not require a database, and it does not actively use files on a network share, planning for multisite deployments is relatively straight forward.

In the next post, I’ll talk about deploying the UEM supporting infrastructure.

vMotion Support for NVIDIA vGPU is Coming…And It’ll Be Bigger than you Think

One of the cooler tech announcements at VMworld 2017 was on display at the NVIDIA booth.  It wasn’t really an announcement, per se, but more of a demonstration of a long awaited solution to a very difficult challenge in the virtualization space.

NVIDIA displayed a tech demo of vMotion support for VMs with GRID vGPU running on ESXi.  Along with this demo was news that they had also solved the problem of suspend and resume on vGPU enabled machines, and these solutions would be included in future product releases.  NVIDIA announced live migration support for XenServer earlier this year.

Rob Beekmans (Twitter: @robbeekmans) also wrote about this recently, and his blog has video showing the tech demos in action.

I want to clarify that these are tech demos, not tech previews.  Tech Previews, in VMware EUC terms, usually means a feature that is in beta or pre-release to get real-world feedback.  These demos likely occurred on a development version of a future ESXi release, and there is no projected timeline as to when they will be released as part of a product.

Challenges to Enabling vMotion Support for vGPU

So you’re probably thinking “What’s the big deal? vMotion is old hat now.”  But when vGPU is enabled on a virtual machine, it requires that VM to have direct, but shared, access to physical hardware on the system – in this case, a GPU.  And vMotion never worked if a VM had direct access to hardware – be it a PCI device that was passed through or something plugged into a USB port.

If we look at how vGPU works, each VM has a shared PCI device added to it.  This shared PCI device provides shared access to a physical card.  To facilitate this access, each VM gets a portion of the GPU’s Base Address Register (BAR), or the hardware level interface between the machine and the PCI card.  In order to make this portable, there has to be some method of virtualizing the BAR.  A VM that migrates may not get the same address space on the BAR when it moves to a new host, and any changes to that would likely cause issues to Windows or any jobs that the VM has placed on the GPU.

There is another challenge to enabling vMotion support for vGPU.  Think about what a GPU is – it’s a (massively parallel) processor with dedicated RAM.  When you add a GPU into a VM, you’re essentially attaching a 2nd system to the VM, and the data that is in the GPU framebuffer and processor queues needs to be migrated along with the CPU, system RAM, and system state.  So this requires extra coordination to ensure that the GPU releases things so they can be migrated to the new host, and it has to be done in a way that doesn’t impact performance for other users or applications that may be sharing the GPU.

Suspend and Resume is another challenge that is very similar to vMotion support.  Suspending a VM basically hibernates the VM.  All current state information about the VM is saved to disk, and the hardware resources are released.  Instead of sending data to another machine, it needs to be written to a state file on disk.  This includes the GPU state.  When the VM is resumed, it may not get placed on the same host and/or GPU, but all the saved state needs to be restored.

Hardware Preemption and CUDA Support on Pascal

The August 2016 GRID release included support for the Pascal-series cards.  Pascal series cards include hardware support for preemption.  This is important for GRID because it uses time-slicing to share access to the GPU across multiple VMs.  When a time-slice expires, it moves onto the next VM.

This can cause issues when using GRID to run CUDA jobs.  CUDA jobs can be very long running, and the job is stopped when the time-slice is expired.  Hardware preemption enables long-running CUDA tasks to be interrupted and paused when the time-slice expires, and those jobs are resumed when that VM gets a new time-slice.

So why is this important?  In previous versions of GRID, CUDA was only available and supported on the largest profiles.  So to support the applications that required CUDA in a virtual virtual environment, and entire GPU would need to be dedicated to the VM. This could be a significant overallocation of resources, and it significantly reduced the density on a host.  If a customer was using M60s, which have two GPUs per card, then they may be limited to 4 machines with GPU access if they needed CUDA support.

With Pascal cards and the latest GRID software, CUDA support is enabled on all vDWS profiles (the ones that end with a Q).  Now customers can provide CUDA-enabled vGPU profiles to virtual machines without having to dedicate an entire GPU to one machine.

This has two benefits.  First, it enables more features in the high-end 3D applications that run on virtual workstations.  Not only can these machines be used for design, they can now utilize the GPU to run models or simulations.

The second benefit has nothing to do with virtual desktops or applications.  It actually allows GPU-enabled server applications to be fully virtualized.  This potentially means things like render farms or, in a future looking state, virtualized AI inference engines for business applications or infrastructure support services.  One potentially interesting use case for this is running MapD, a database that runs entirely in the GPU, on a virtual machine.

Analysis

GPUs have the ability to revolutionize enterprise applications in the data center.  They can potentially bring artificial intelligence, deep learning, and massively parallel computing to business apps.

vMotion support is critical in enabling enterprise applications in virtual environments.  The ability to move applications and servers around is important to keeping services available.

By enabling hardware preemption and vMotion support, it now becomes possible to virtualize the next generation of business applications.  These applications will require a GPU and CUDA support to improve performance or utilize deep learning algorithms.  Applications that require a GPU and CUDA support can be moved around in the datacenter without impacting the running workloads, maintaining availability and keeping active jobs running so they do not have to be restarted.

This also opens up new opportunities to better utilize data center resources.  If I have a large VDI footprint that utilizes GRID, I can’t vMotion any running desktops today to consolidate them on particular hosts.  If I can use vMotion to consolidate these desktops, I can utilize the remaining hosts with GPUs to perform other tasks with GPUs such as turning them into render farms, after-hours data processing with GPUs, or other tasks.

This may not seem important now.  But I believe that deep learning/artificial intelligence will become a critical feature in business applications, and the ability to turn my VDI hosts into something else after-hours will help enable these next generation applications.

 

Top 10 EUC Sessions at #VMworld 2017 Las Vegas

VMworld 2017 is just around the corner.  The premier virtualization conference will be returning to the Mandalay Bay convention center in Las Vegas at the end of August. 

There is one major addition to the EUC content at VMworld this year.  VMware has decided to move the Airwatch Connect conference, which cover’s VMware’s offerings in the mobility management space, from Atlanta and colocate it with VMworld.  So not only do attendees interested in EUC get great expert content on VMware’s Horizon solutions, they’ll get more content on Airwatch, mobility management, identity management, and IoT as well.

My top 10 EUC sessions for 2017 are:

  1. ADV1594BU – Beyond the Marketing: VMware Horizon 7.1 Instant Clones Deep Dive – This session, by Jim Yanik and Oswald Chen, is a technical deep dive into how Instant Clone desktops work.  This updated session will cover new features that have been added to Instant Clones since they were released in Horizon 7.  I’m often wary of “deep dive sessions,” but I’ve seen Jim give a similar presentation at various events and he does a great job talking through the Instant Clone technology in a way that all skill levels can understand it.  If you’re interested in VMware EUC, this is the one session you must attend as this technology will be relevant for years to come. 
  2. ADV1609BU – Deliver Any App, Any Desktop, Anywhere in the World Using VMware Blast Extreme – Blast Extreme is VMware’s new protocol that was officially introduced in Horizon 7.  Pat Lee and Ramu Panayappan will provide a deep dive into Blast Extreme.  Pat does a good job talking about Blast Extreme and how it works, and attendees will definitely walk away having learned something.
  3. ADV1681GU/ADV1607BU – Delivering 3D graphics desktops and applications in the real world with VMware Horizon, BEAT and NVIDIA GRID – VMware’s Kiran Rao and NVIDIA’s Luke Wignall talk about how Blast Extreme utilizes NVIDIA GPUs to provide a better user experience in End-User Computing environments.  This session was actually listed twice in the Content Catalog, so don’t worry if you miss one.
  4. ADV1583BU – Delivering Skype for Business with VMware Horizon: All You Need to Know – Official support for Skype for Business GA’d with Horizon 7.2.  This session will dive into how that the new Skype for Business plugin works to provide a better telephony experience in EUC environments.
  5. ADV3370BUS – DeX Solutions: How Samsung and VMware are Pioneering Digital Transformation – Samsung DeX is a new cell phone from Samsung that, when placed in a dock, can utilize a keyboard, mouse, and monitor to act as a virtual thin client endpoint while still having all the capabilities of a phone.  DeX has the potential to revolutionize how businesses provide endpoints and cellular phones to users.
  6. ADV1655GU – CTOs perspective on the Workspace 2020 and beyond: time to act now! – End-User Computing expert and technology evangelist Ruben Spruijt talks about the future of the end-user workspace and strategies on how to implement next-generation workspace technology.
  7. UEM1359BU – Best Practices in Migrating Windows 7 to Windows 10 – Windows 10 migrations are a hot topic, and almost every business will need a Windows 10 strategy.  This session will explore the best practices for migrating to Windows 10 in any type of organization.
  8. SAAM1684GU – Ask the Experts: How to Enable Secure Access from Personal/BYO Devices and All Types of Users with Workspace ONE – How do you enable secure remote access to company resources while allowing employees, contractors, and other types of workers to use their personal devices?  This group discussion will cover best practices for using VMware Workspace ONE to provide various levels of secure access to company resources from personal devices based on various context settings.  Unlike most sessions, this is a group discussion.  There are very few slides, and most of the session time will be devoted to allowing attendees to ask questions to the discussion leaders.
  9. ADV1588BU – Architecting Horizon 7 and Horizon Apps – A successful EUC environment starts with a solid architecture.  This session covers how to architect an integrated Horizon environment consisting of all components of the Horizon Suite. 
  10. vBrownbag TechTalks on EUC – There are three community driven vBrownbag Tech Talks focusing on EUC led by EUC Champions.  These talks are:
    1. GPU-Enabled Linux VDI by Tony Foster – Tony will cover how to build GPU-enabled Linux virtual desktops in Horizon and some of the pain points he encountered while implementing this solution at a customer.
    2. Windows 10 and VDI – Better Come Prepared – Rob Beekmans and Sven Huisman will cover lessons they’ve learned while implementing Windows 10 in VDI environments.
    3. Leveraging User Environment Manager to Remove GPOs – Nigel Hickey will cover how to use VMware UEM as a Group Policy replacement tool.
  11. ADV1605PU – Ask the Experts: Practical Tips and Tricks to Help You Succeed in EUC – So this top 10 list will actually have 11 entries, and this one is a bit of shameless self-promotion.  This session is s a repeat of last year’s EUC champions session featuring Earl Gay, VCDX Johan van Amersfoot, moderator Matt Heldstab, and I.  We’re answering your questions about EUC based on our experiences in the trenches.  Last year, we also had some prizes. 

Bonus Session

There is one bonus session that you must put on your schedule.  It’s not EUC-related, but it is put on by two of the smartest people in the business today.  They were also two of my VCDX mentors.  The session is Upgrading to vSphere 6.5 the VCDX Way [SER2318BU] by Rebecca Fitzhugh and Melissa Palmer.  You should seriously check this session out as they’ll provide a roadmap to take your environment up to vSphere 6.5. 

Introducing Horizon 7.2

What’s new in Horizon 7.2?  A lot, actually.  There are some big features that will impact customers greatly, some beta features are now general availability, and some scalability enhancements. 

Horizon 7 Helpdesk Tool

One of the big drawbacks of Horizon is that it doesn’t have a very good tool for Helpdesk staff to support the environment.  While Horizon Administrator has role-based access control to limit what non-administrators can access and change, it doesn’t provide a good tool to enable a helpdesk technician to look up what desktop a user is in, grab some key metrics about their session, and remote in to assist the user.

VMware has provided a fling that can do some of this – the Horizon Toolbox.  But flings aren’t officially supported and aren’t always updated to support the latest version. 

Horizon 7.2 addresses this issue with the addition of the Horizon Helpdesk tool.  Horizon Helpdesk is an HTML5-based web interface designed for level 1 and 2 support desk engineers.  Unlike Citrix Director, which offers similar features for XenApp and XenDesktop environments, Horizon Helpdesk is integrated into the Connection Servers and installed by default.

Horizon Helpdesk provides a tool for helpdesk technicians who are supporting users with Horizon virtual desktops and published applications.  They’re able to log into the web-based tool, search for specific users, and view their active sessions and desktop and application entitlements.  Technicians can view details about existing sessions, including various metrics from within the virtual desktops and use the tool to launch a remote assistance.

Skype for Business Support is Now GA

The Horizon Virtualization Pack for Skype for Business was released under Technical Preview with Horizon 7.1.  It’s now fully supported on Windows endpoints in Horizon 7.2, and a private beta will be available for Linux-based clients soon. 

The Virtualization Pack allows Horizon clients to offload some of the audio and video features of Skype for business to the endpoint, and it provides optimized communication paths directly between the endpoints for multimedia calls.  What exactly does that mean?  Well, prior to the virtualization pack, multimedia streams would need to be sent from the endpoint to the virtual desktop, processed inside the VM, and then sent to the recipient.  The virtualization pack offloads the multimedia processing to the endpoint, and all media is sent between endpoints using a separate point-to-point stream.  This happens outside of the normal display protocol virtual channels.

image

Skype for Business has a number of PBX features, but not all of these features are supported in the first production-ready version of this plugin.  The following features are not supported:

  • Multiparty Conferencing
  • E911 Location Services
  • Call to Response Group
  • Call Park and Call Pickup from Park
  • Call via X (Work/Home, Cell, etc)
  • Customized Ringtones
  • Meet Now Conferencing
  • Call Recording

Instant Clone Updates

A few new features have been added to Horizon Instant Clones.  These new features are the ability to reuse existing Active Directory Computer accounts, support for configuring SVGA settings – such as video memory, resolution and number of monitors supported –  on the virtual desktop parent, and support for placing Instant Clones on local datastores.

Scalability Updates

VMware has improved Horizon stability in each of the previous releases, usually by expanding the number of connections, Horizon Pods, and sites that are supported in a Cloud Pod Architecture.  This release is no exception.  CPA now supports up to 120,000 sessions across 12 Horizon Pods in five sites.  While the number of sites has not increased, the number of supported sessions has increased by 40,000 compared to Horizon 7.1.

This isn’t the only scalability enhancement in Horizon 7.2.  The largest enhancement is in the number of desktops that will be supported per vCenter Server.  Prior to this version of Horizon, only 2000 desktops of any kind were supported per vCenter.  This means that a Horizon Pod that supported that maximum number of sessions would require five vCenter servers.  Horizon 7.2 doubles the number of supported desktops per vCenter, meaning that each vCenter Server can now support up to 4000 desktops of any type. 

Other New Features

Some of the other new features in Horizon 7.2 are:

  • Support for deploying Full Clone desktops to DRS Storage Clusters
  • A Workspace One mode configure access policies around desktops and published applications
  • Client Drive Redirection and USB Redirection are now supported on Linux
  • The ability to rebuild full clone desktops and reuse existing machine accounts.

Key Takeaways

The major features of Horizon 7.2 are very attractive, and they address things that customers have been asking for a while.  If you’re planning a greenfield environment, or it’s been a while since you’ve upgraded, there are a number of compelling reasons to look at implementing this version.

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