Omnissa Workspace ONE Unified Endpoint Management Integration with Horizon

Overview

Author’s Note

Many of the concepts herein apply to any virtual machine in the Horizon family of products, regardless of platform (Horizon 8 or Horizon Cloud Service).  For the purposes of this document, except where explicitly called out, Horizon is used interchangeably for either platform. 

Audience

This tutorial is intended for IT administrators and product evaluators who are familiar vCenter and vSphere, as well as Omnissa Horizon 8 or Horizon Cloud Service, and Omnissa Workspace ONE UEM. Additionally, for cloud-based Horizon deployments, it is assumed that administrators have knowledge specific to the customization of virtual machines specific to how an image is prepared during deployment into a pool.

Introduction

Persistent VDI desktops traditionally present a straightforward way to quickly onboard users and use cases with little up-front work.  However, several challenges arise from their use due to their similarity to a regular PC:

• Persistent desktops will drift in configuration from their original parent over time, leading to inconsistency between existing users and users receiving new desktops.
• Maintaining application and OS patching can be difficult as users often install their own software without the administrator’s knowledge.
• Supporting a user with both a physical device and a virtual desktop adds complexities given the number of components involved.

Management (Workspace ONE UEM) gives Horizon administrators a broad toolset to provide a consistent patching experience and additional tools for monitoring, maintenance, and support. The following table shows the Workspace ONE UEM features that can be leveraged with Horizon desktops.

Note: While many of the features of this integration will work with long-lived instant clones, they have not been fully tested yet. Please refer to Virtual Desktop Platforms Supported by Workspace ONE UEM (90624) for the complete and up-to-date details of supported features.

 Figure 1 - Workspace ONE UEM feature compatibility with Horizon desktop virtual machines

	Gold Image	Full Clone
Operating System Updates	✅	✅
Software Deployment	✅	✅
Profiles & Baselines	✅	✅
Data collection via Sensors	✅	✅
Automated endpoint configuration via Scripts	✅	✅
Usage & Performance Reporting via Intelligence	✅	✅
Real-Time User Support via Assist	✅	✅

 

This document defines the recommended practices and integration process for integrating Horizon Desktops into Workspace ONE UEM. In addition, it will provide considerations for enhancing key tasks in desktop management.

Practical Uses of UEM with Horizon

The most familiar integration for Horizon administrators is Workspace ONE Access. Providing Horizon resources via Access’s catalog gives end users a single place to access any corporate resources and provides administrators a robust and granular toolset for authentication and usage of said resources. While the inner workings are quite complex, the user’s login process can be boiled down into five distinct phases.

Figure 2 - User information exchange with Workspace ONE Access and Horizon

Understanding this flow, the addition of Workspace ONE UEM provides a potent set of tools to administrators if the client, the VDI, or both ends of process are connected.

For example, a user calls the help desk and states that their Horizon VDI session is missing keystrokes or repeating keys unexpectedly. Most typically, this is a network issue and a Horizon administrator’s visibility is limited, often starting with the desktop VM and ending at the UAG since the connection then traverses out of the corporate network onto public WAN.

Figure 3 - Horizon Administrator's typical environment sphere of influence for diagnostics

The catch with this scenario is many of these logs are isolated on specific components and if there are multiple connection server for example, an administrator must look through logs on multiple devices before finding the correct log with the information they need. Additionally, retrieving logs from the Client can further complicate the process as it may depend on a device that isn’t connected to the corporate network.

Workspace ONE UEM can dramatically help shorten the troubleshooting cycle, especially if both the client device and the VDI desktop are enrolled simultaneously. This puts the full suite of modern management tools on both sides of the user’s connection, giving many new tools to help identify and resolve issues, sometimes even automatically.

In the example above, if both the client and virtual desktop were enrolled in Workspace ONE UEM, an administrator could use a specialized sensor to collect key information off both the client device to identify the issue.

For example, assuming Workspace ONE Intelligence has detected issues with the client device’s Wi-Fi adapter, the administrator can simply use Workspace ONE Assist to help the end user resolve the problem in real-time. With Horizon alone, this would be impossible as the administrator only has limited control over the datacenter components and wouldn’t know of the Wi-Fi problem.

Figure 4 - Horizon & UEM Issue Resolution Scope

In short, enrollment in Workspace ONE UEM aggregates data from both the client endpoint device and the virtual desktop into Workspace ONE Intelligence giving a single point to identify issues and enables administrators to quickly resolve them with Workspace ONE Assist

Horizon and UEM Synergy

Workspace ONE UEM offers several ways to enroll devices. The ability to use one or more staging accounts to pre-enroll VDI desktops as single user devices within UEM gives synergy with Horizon’s ability to automatically assign a user to a VM; once the Horizon user’s logon is complete, the UEM device is assigned to the user.

Most typically UEM administrators use staging accounts to set up a machine prior assignment to an end user. The device is pre-staged into the correct OG within UEM, automatically ensuring that patching, apps, and other policies are applied and enforced even before a user logs in. Upon first login, the user is presented with the Intelligent Hub app on the desktop into which they provide their credentials registering the device to the user.

Horizon’s ability to create pools of desktops and automatically assign users to pre-staged persistent desktops creates a natural workflow that adds no additional burden to administrators:

1. A user launches their Horizon resource either via their client device’s Intelligent Hub App or directly via the Horizon Client
2. A new desktop is brokered to the user and persistently assigned to them within the Horizon system
3. Upon reaching the desktop, the VM device is assigned to the user in UEM and presents them with the Intelligence Hub application

This is hugely advantageous as it unifies the experience for the end user on both their client device and their virtual desktop, presenting a common look and field that doesn’t require any additional training to use.

Figure 5 - A freshly created UEM Horizon Desktop on first login

Environment Preparation in Workspace ONE UEM

There are several preparatory steps that should be taken in UEM to allow for better integration. The following steps assume the UEM environment has been configured to an operational state. For guidance on the initial setup of the UEM platform, please see the Workspace ONE Configuration section of the Reference Architecture.

Horizon integration into the UEM platform is straightforward: Horizon desktops will be Windows-based, persistent virtual machines, assigned to a single user.  Meshing the provisioning process with the enrollment process only requires a couple of additional steps:

• An Organization Group structure should be set up for the Horizon desktops to allow for easier management within the UEM platform.
• One or more Staging Accounts will be required to ensure the desktops are enrolled correctly.
• A Profile to allow the desktop to keep apps on unenroll for Gold Images.

Organization Groups

For Horizon, Organization Groups allow automatic collection of like machine types into a single unit to apply policies and configurations. For our example, a new Organization Group tree is created for BYOD with the following divisions:

Figure 6 – Example Organization Group Tree

Generally, the OG structure will be unique per deployment, so firm recommendations are beyond the scope of this document. Instead, the general guidance is to create a structure that best represents your individual use case and provides appropriate control points to help manage day 2 operations in a simplified manner.

For this guide, the example structure will allow for fine tuning of many of UEMs features to best work with Horizon desktops as well as providing a quick way to understand which resources are from Horizon versus other enrolled devices but doesn’t add any additional complexity below that. The Corporate division under BYOD future-proofs the deployment for any policies allowing end users to purchase their own devices. Under this, we split out managed desktops and gold images as they do have slight differences with how policies are applied. If required, any level of the OG structure can have one or more new groups created to further subdivide devices as needed.

Please see the Organization Groups section of the Workspace ONE UEM documentation for complete details on creating and managing Organization Groups.

Staging Accounts

For information on creating an account for use as a staging account, please see the Basic User Accounts section of the Workspace ONE UEM documentation.

For use with Horizon, after creation, ensure that the account is configured with Device Staging enabled for Single User devices. For reference, the image below shows a typical configuration of the Staging settings for an account used in this document.

Figure 7 – Staging Account Settings

Policies and Baselines

A major pitfall with persistent desktops is the inability to quickly deploy patches with a new image like instant clones. UEM’s profiles and baselines features allow administrators to quickly roll out patches and apps to enrolled devices and ensure consistency. Utilizing the Organization Group(s) created earlier for the Horizon desktops, two Policies will be configured:

• Keep Apps on Unenroll – This policy will allow gold images to be unenrolled prior to the Horizon provisioning process to minimize the number of virtual machines requiring app downloads.
• Windows Updates – Horizon VDI – This policy will control the Windows Updates in the VDI environment separately from the more standard policies available in UEM. This allows for greater control over the versioning for the VDI environment to ensure stability and security of the platform.

Keep Apps on Unenroll

One of the tenets of gold image management is the installation and update of required applications used by everyone in the enterprise. While technologies like App Volumes allow for many of these applications to be delivered on demand in non-persistent environments, persistent desktops are more typically used like a standard workstation rather than a virtual desktop. By setting a policy to keep apps on unenrollment for our Gold Image OG, we can easily deploy and maintain a common set of applications to all Horizon gold images that will remain through the provisioning process.

1. Under Resources > Profiles & Baselines > Profiles, select Add > Add Profile.

2. On the Add Profile screen, select Windows, then Windows Desktop

3. On the Select Context screen, select Device Profile

4. Give the profile a name and description for reference, then under the Smart Groups item, add the Horizon Gold Images Smart Group that was created with the OG.

5. Scroll down the left-hand menu, select the Managed Applications section, then press Configure.

6. Set the Keep Managed Applications on Device flag to Enabled, then select Save and Publish.

Windows Update – Horizon Desktops

Windows Updates can be a resource intensive operation in a virtual desktop environment. A custom Windows Update policy for Horizon VDI will allow better control over the update process to ensure that it doesn’t inadvertently cause a boot storm or resource contention.  Key considerations for updates:

• Update and patch download Windows
• Deferral and compliance
• VM reboot scheduling

Windows Updates in UEM are a very complex topic.  For recommendations and complete details, please see the Managing Updates for Windows Devices TechZone operational guide and/or Managing Windows Device Updates in the Workspace ONE UEM documentation.

Virtual Machine Enrollment

Enrolling virtual desktops into UEM is facilitated by command-line enrollment. There are two basic methods in which this can be accomplished both with advantages and limitations. The main difference between the two options is the location from which we call the enrollment process.

• vSphere Customization Specification – Limited to native vSphere platforms (private datacenters, vSphere-based cloud SDDC platforms, etc.), this option places the command line options within the vCenter Server’s Commands to Run Once option in the customization specification. With this option, the Customization Specification is selected as part of the Horizon Pool’s VM options.
• Automated In-guest script – Located within the VM itself, this option can run on any platform, including Horizon Cloud on Azure. The main consideration with any in-guest script is ensuring that the script is properly scrubbed of any credentials prior to the desktop being assigned to a user.

On the surface, both methods depend on the command-line utility for enrollment. In both cases, it is recommended to use the Staging Account created earlier to pre-enroll the desktop machines to ensure that user credentials remain secured.

Core Methodology: Command-line Enrollment

The command-line enrollment functionality of the agent installer is the core of any of the following procedures.

Figure 8 - UEM enrollment command-line

msiexec /i "\\File-Server\UEM\AirwatchAgent.msi" /quiet ENROLL=Y SERVER=DS FQDN LGName=GroupID USERNAME=Username PASSWORD=Password ASSIGNTOLOGGEDINUSER=Y

Note: While they will not be used in this document, more flags are available in the command-line in Workspace ONE UEM Windows 10 Command-Line Enrollment Arguments (78733).

For the recommended use with Horizon, the Username and Password will both use a staging account to prepare the desktop for the user’s first login. The above command should be tailored to each deployment by replacing the items in red with the correct information: 

• The Agent installer path can be located locally on the desktop or on an accessible network share.
• The Server is the enrollment URL or Device Services server FQDN
   
• The GroupID is the Organization Group ID
   
• The Username and Password fields are set to the staging account information.

These items can either be hardcoded or scripted as variables dependent upon implementation. The following procedure sections break down the methods to implement this command.

Golden Images

Managing Gold Images with UEM provides several advantages in that it allows administrators to quickly ensure the appropriate patches and applications are automatically installed without need for manual work. Administrators can configure native app installations at any OG level, and they will be installed automatically if not present. Combined with the Keep Apps on Unenroll policy created in the prerequisites, this creates a powerful way to dynamically build images based on the OG and assignments for apps and policies.

In some cases, apps may be assigned to all devices in the top-level OG, but that app isn’t needed for a Horizon desktop (EG: Workspace ONE Tunnel). In such instances, exclusions can be placed in the assignment for Horizon OGs, and the app will be skipped automatically during creation of the image.

Figure 9 - App Assignment Exclusions

Gold Images can easily be enrolled automatically with the vSphere Customization Specification below or by manually installing the Workspace ONE UEM Agent. Before deploying the Gold Image, it should be unenrolled from Workspace ONE UEM:

“C:\Program Files (x86)\Airwatch\AgentUI\AWProcessCommands.exe” Unenroll

This will ensure that any new images can successfully register with UEM as a new device.

vSphere Customization Specification Procedure

This method is the most basic process by which desktops can be enrolled on vSphere-based platforms and is presented here as a starting point for smaller proof of concept testing. This method does not currently work with Horizon Cloud next-gen.

Prerequisites

For this procedure, it is assumed that a customization specification for full clone persistent desktops has already been created. If not, prior to completing the following steps one must be created. See Creating and Managing Customization Specifications in the vSphere documentation for more information.

Additionally, for this method, the UEM Agent installer must be staged on the desktop gold image and the command-line location updated to the installer’s location in the gold image. The agent can be downloaded from https://getwsone.com

Procedure

1. In vCenter from the main menu, select Policies and Profiles
    
2. Click VM Customization Specifications
    
3. Select the policy for Horizon’s full clone persistent desktops and click Edit
    
4. From the navigation pane, select Commands to Run Once
    
5. In the top text entry field, paste the msiexec command to enroll, then press Add
    
6. Again, in the top text entry field, type logoff, then press Add
    
7. Repeat the above steps for all vCenter Server environments in which Horizon will deploy full clone persistent desktops, the continue to step 8
8. In the Horizon Administration UI, configure desired Horizon pool(s) to use the updated specification under the pool’s Settings > Guest Customization > VM Customization Specification field
    

Note: This procedure will only affect new VMs provisioned by Horizon. Existing VMs must be manually enrolled or removed and recreated.

Automated In-Guest Scripted Procedure

For a more scripted deployment, there are several methods available to automatically enroll desktops. The deciding factor in which to choose comes down to what the platform will support based on how Windows instances are prepared during the cloning process.

• For deployments that support modification and use of the SetupComplete.cmd functionality within Windows, <TODO: insert link to Azure script> may be used when sealing the gold image to configure the desktop to register with UEM after creation.
• For deployments that do not support modification of the SetupComplete.cmd functionality, like Amazon Workspaces Core, Scheduled Tasks may be used to complete the process instead. <TODO: Insert link to AWS script> may be used for enrollment on these platforms.
• For vSphere environments, rather than adding the msiexec command into the Run Once commands, you can simply call the script on the desktop itself.

For any scripted option, the main factor is ensuring that the enrollment process is completed prior to the user first logging into the desktop, as the enrollment process is sensitive to a reboot occurring. Should the process be interrupted, it is recommended to delete the desktop and recreate it. In the event a user has already logged in and saved data to a desktop where enrollment has been interrupted, it must be migrated off before deletion like normal to prevent data loss when recreating the VM.

Summary and Additional Resources

Introduction

This operational tutorial supplied guidance on integrating Horizon and Workspace ONE UEM.

Procedures included:

• Setting up Horizon specific Organization Groups and Staging Accounts
• Enabling App Retention when Unenrolling a Device
• Enrolling Horizon Desktops during VM Customization

Additional Resources

For other information, you can explore the following resources:

• Workspace ONE and Horizon Reference Architecture
• Omnissa Knowledge Base

Changelog

The following updates were made to this guide:

Date	Description of Changes
2024/10/24	Rebranding edits
2023/09/29	First Draft

Feedback

Your feedback is valuable.

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.