Deploying Omnissa Horizon with Amazon EC2 and Amazon Workspaces

Overview

With Omnissa Horizon® 8, IT departments can run remote desktops and applications in the data center (whether it is on-premises, private corporate cloud, or public cloud) and deliver these desktops and applications to their employees. These employees, or end users, gain a familiar, personalized environment that they can access from any number of devices anywhere throughout the enterprise or from home. Administrators gain centralized control, efficiency, and security by having desktop data in the data center.

As more customers move their enterprise workloads into the public cloud, we are seeing rapid growth of Horizon being deployed in public cloud VMware SDDC (Software Defined Data Center) services such as VMware Cloud™ on AWS. However, there are AWS environments where VMware Cloud (VMC) on AWS services is not available, such as the AWS secret regions. Without VMware vSphere, the traditional way of deploying Horizon is unavailable.

Purpose of This Tutorial

In this document, we want to highlight a little-known but supported use case of Horizon 8 which would enable deployment on native AWS, either Amazon Elastic Compute Cloud (EC2) or Amazon WorkSpaces Core, without the presence of VMware Cloud on AWS. Specifically, we will discuss how to deploy Automated Pools, Manual Pools, and Manual Farms in these non-vSphere AWS environments.

Audience

This document is intended for IT practitioners. It assumes working knowledge of AWS as well as Horizon 8. For more information on Horizon, see Omnissa Horizon product documentation.

Overview of Horizon 8 Desktop Pools and Farms

  Horizon supports two types of desktop pools and farms: automated or manual:

An automated desktop pool or farm uses a vCenter virtual machine template or snapshot to create a pool of identical virtual machines. As of the Horizon 2406 release, automated pools may also be deployed targeting AWS WorkSpaces Core as a provider.

A manual pool or farm is a collection of pre-created vCenter virtual machines, physical machines, or non-vCenter virtual machines. With manual pools or farms, Horizon does not create or manage the lifecycle of the machines. These machines are created outside of Horizon and then registered with the Horizon Connection Servers. Compared to an automated desktop pool or farm, a manual pool or farm has limited features. Some examples include (but are not limited to):

• Horizon does not manage the lifecycle of the desktops in a manual desktop pool, therefore, features such as automated provisioning or remote power policy do not apply
• Instant clones, being a vSphere feature, are not applicable to manual pools or farms
• App Volumes does not support manual pools or farms

The types of pools or farms from AWS that you can manage with Horizon include:

• Automated pool of virtual desktops using Amazon WorkSpaces Core
• Manual pool of virtual desktops using Amazon WorkSpaces Core
• Manual pool of published / RDSH desktops using native Amazon EC2 machines or Amazon WorkSpaces Core
• Manual pool of Linux desktops using native Amazon EC2 machines
• Manual pool of virtual desktops using Amazon EC2 machines. For Win 10 virtual desktops, bare metal EC2 hosts are required

This document focuses on the first three use cases in detail. Similar steps apply to the remaining use cases.

Why Deploy Pools and Farms on AWS Native?

With a few limitations, using Horizon 8 to deploy automated or manual pools or farms on Amazon EC2 or WorkSpaces Core has the following benefits:

• With very few exceptions, you can use the same set of remote experience features that Horizon 8 has for VMware Cloud on AWS virtual machines
• You can leverage the same Horizon 8 connection broker for all user entitlement workflows on Amazon EC2 machines or Amazon WorkSpaces Core, including features such as Cloud Pod Architecture (CPA)
• If you have an existing pod of Horizon 8 on VMware Cloud on AWS desktops running, you can extend the pod to cover the Amazon EC2 machines or Amazon WorkSpaces Core

Overview of Native AWS Services

This section explores Amazon EC2 and Amazon WorkSpaces Core.

Amazon EC2

Amazon EC2 provides a self-managed secure, resizable compute capacity in the cloud. Amazon EC2 offers the broadest and deepest compute platform with the choice of processor, storage, networking, operating system, and purchase model. You can provision from 400 instance types running Windows or Linux operating systems within minutes including instances with the most powerful GPU instances.

Some of the benefits and features of using Amazon WorkSpaces Core:

• Compliance for HIPAA and PCI
• Eliminate the complexity of managing hardware inventory, OS versions, and patches
• Increase storage allocation at any time per instance

Additional information about pricing, options, and features can be found on the Amazon EC2 website.

Amazon WorkSpaces Core

Amazon WorkSpaces Core is a managed, secure Desktop-as-a-Service (DaaS) solution. You can use Amazon WorkSpaces Core to provision Windows desktops in just a few minutes and quickly scale to provide thousands of desktops to workers across the globe. You can pay monthly for only the WorkSpaces Core that you launch.

Some of the benefits and features of using Amazon WorkSpaces Core include:

• Compliance for HIPAA and PCI
• Eliminate the complexity of managing hardware inventory, OS versions, and patches
• Range of image bundles for different hardware and software options such as Value, Standard, Performance, Power, PowerPro, and G4dn instances.
• Optional bundles include Microsoft Office, Trend Micro Worry-Free Business Security Services, and a utilities bundle
• Increase storage allocation at any time per desktop
• Bring your own Windows desktop licenses to Amazon WorkSpaces Core if they meet Microsoft's licensing requirements

Additional information about pricing, options, and features can be found on the Amazon WorkSpaces Core website.

Choosing Between Horizon on Amazon EC2 and Amazon WorkSpaces Core

After you determine that VMware Cloud on AWS is not available to you, the next step is to consider whether to deploy Horizon on Amazon EC2 machines or Horizon on Amazon WorkSpaces Core. Which choice to make will largely depend on your use case. Amazon WorkSpaces Core does not support RDSH apps, so for this use case, deploy Horizon on Amazon EC2 machines. If you are looking to deploy Windows 10 or Linux desktops, you can deploy Horizon on Amazon WorkSpaces Core.

Key Horizon Features Available on AWS Native

A significant portion of Horizon features that are available for automated pools or farms (such as on VMware Cloud on AWS or running on-premises VMware SDDC) are also available for pools or farms on native Amazon EC2 or Amazon WorkSpaces Core. You can find detailed information in the following table, broken down into three sections:

• High-level product support across Horizon suite of products
• Horizon Platform support
• Horizon Agent, Clients, and Remote Experience support

Table 1: Horizon Product Suite Support 

Horizon 8 Platform (Connection Server) Support

The following table shows a list of key Horizon Platform features and compares support on VMware Cloud on AWS versus AWS native. Note that not all features are listed.

 Table 2: Horizon Platform (Connection Server) Support 

Horizon Remote Experience Support

There are two Horizon Agents (one for Windows VMs and one for Linux VMs), and they support both Horizon Virtual Desktop Infrastructure (VDI) or Apps running on VMware Cloud on AWS, as well as running on Amazon EC2 or Amazon WorkSpaces Core machines.

There are eight Horizon Clients (Windows, Linux, Mac, iOS, Android, ARC++, Windows 10 UWP, and Chrome). In addition, end users can also access Horizon from an Internet browser with our HTML Access support. They all support both Horizon VDI or Apps running on VMware Cloud on AWS, as well as running on Amazon EC2 or Amazon WorkSpaces Core machines.

Omnissa KB 80386 details the specific features that are supported on Horizon automated pools or farms deployed in a vSphere environment such as VMware Cloud on AWS. The majority of these features are also supported for manual pools or farms on AWS EC2 or AWS WorkSpaces Core machines. The few exceptions are listed below:

Table 3: Horizon Remote Experience Support

Deployment Architecture Options

This section describes three high-level architectural options you have for deploying Horizon 8 with Amazon native EC2 or WorkSpaces Core.

Option 1 - Horizon Remote Agent

In this model you extend an existing Horizon pod, running in a private datacenter, to broker virtual machines running on native EC2 or WorkSpaces Core. Horizon infrastructure components remain in your existing data center, and the Horizon Agent is added to your AWS virtual machines. This option makes it easy to realize a hybrid Horizon 8 deployment using AWS capacity. See Remote Agent Support for Horizon Enterprise for additional details. 

Implementation

• This option assumes you have an existing Horizon pod deployed in a private data center.
• You will need an existing or new AWS account. See Setting Up and Configuring an Amazon Account.
• See Deploying Horizon Manual Pools or Farms using Amazon EC2 Machines to configure your Amazon machines for use with Horizon.

Option 2 – Hybrid Cloud Deployment using Cloud Pod Architecture

In this model, you start with a Horizon pod in a private data center and create an additional Horizon pod on AWS capacity. The pods are federated using Cloud Pod Architecture. See Cloud Pod Architecture in Horizon for more information on CPA.

Implementation

• This option assumes you have an existing Horizon pod deployed in a private data center.
• You will need an existing or new AWS account. See Setting Up and Configuring an Amazon Account.
• See Deploying Horizon Infrastructure on Amazon EC2 Machines.
• See Deploying Horizon Manual Pools or Farms using Amazon EC2 Machines to configure your Amazon machines for use with Horizon.

Option 3 – Horizon 8 in the Cloud

If you don’t have an existing Horizon 8 pod in a private data center or would like to transition purely to the cloud, you have several options with Amazon. Deploying Horizon 8 infrastructure components to EC2 enables you to create manual desktop pools with Amazon WorkSpaces Core, or manual RDSH farms with native EC2. Horizon on VMware Cloud on AWS provides additional Horizon functionality such as Instant Clones and App Volumes, on a managed, vSphere-based SDDC.

Implementation

• You will need an existing or new AWS account. See Setting Up and Configuring an Amazon Account.
• See Deploying Horizon Infrastructure on Amazon EC2 Machines.
• See Deploying Horizon Manual Pools or Farms using Amazon EC2 Machines to configure your Amazon machines for use with Horizon.

Setting up and Configuring an Amazon Account

Amazon Web Services (AWS) is a secure cloud services platform, offering compute power, database storage, content delivery, and other functionality to help businesses scale and grow.

If you do not have an account, you can create an account on the Amazon Web Services home page.

Alternatively, you can use your existing Amazon account.

When using the Horizon Agent with Amazon WorkSpaces or WorkSpaces Core, make sure the instances are configured for AlwaysOn. AlwaysOn is the default running mode for WorkSpaces Core instances. With AlwaysOn, the WorkSpaces Core service will ensure that instances are always powered on and ready to be accessed by the Horizon Client. If an end user powers the instance down via Windows, the WorkSpaces Core service will automatically power it back on.

Deploying Horizon Infrastructure on Amazon EC2 Machines

Before you can use Horizon to manage Amazon EC2 machines or Amazon WorkSpaces Core, you must first deploy Horizon infrastructure components on Amazon EC2 machines:

1. Set up and configure an AWS Account.
2. Create the desired EC2 instance type and quantity that meet the recommended requirement of the Horizon infrastructure in your AWS account.
   1. Deploy Horizon Infrastructure Components in the Amazon EC2 machines you created in Step 2.
3. Deploy any additional infrastructure components needed for Horizon, such as events database, Active Directory domain controllers, or file shares.

Deploying Horizon components on Amazon EC2 Environment

Regardless of whether you have chosen to deploy Horizon on Amazon EC2 machines or Horizon on Amazon WorkSpaces Core, you need to deploy the Horizon infrastructure components on Amazon EC2 instances.

Note: The exception is that if you already have a Horizon pod deployed in a private data center or a managed SDDC environment such as VMware Cloud on AWS, you can extend the infrastructure components of the existing Horizon Pod to manage your Amazon EC2 machines or Amazon WorkSpaces Core machines. Latency from the Horizon Connection Servers to managed agents must be less than 120ms.

Horizon Connection Server

Horizon Connection Servers are enterprise-class desktop management servers that securely broker and connect users to desktops and RDSH-published applications running on VMs, physical PCs, blade PCs, or RDSH servers. Connection Servers authenticate users through Windows Active Directory and direct the request to the appropriate, entitled resource.

Connection Servers provide the following management capabilities:

• Authenticating users
• Entitling users to specific remote desktops and application pools
• Assigning applications packaged with Omnissa ThinApp® to specific desktops and pools
• Managing remote desktop and application sessions
• Establishing secure connections between users and remote desktops and applications
• Enabling single sign-on
• Setting and applying policies

Connection Servers (up to 7) from a single data center can be grouped into a pod.

Omnissa Unified Access Gateway Appliance

Omnissa Unified Access Gateway virtual appliances enable secure remote access from an external network to a variety of internal resources without the need for a VPN. These appliances direct authentication requests to the appropriate server and discard any unauthenticated requests. Users can access only the resources that they are authorized to access.

Unified Access Gateway also ensures that the traffic for an authenticated user can be directed only to the desktop and application resources to which the user is entitled. This level of protection involves specific inspection of desktop protocols and coordination of potentially rapid-changing policies and network addresses, to accurately control access.

Omnissa Horizon Cloud Connector

The Omnissa Horizon® Cloud Connector is a virtual appliance that connects a Horizon pod with Omnissa Horizon Control Plane. During deployment of the virtual appliance, a pairing process connects the specified Connection Server to Horizon Cloud Service so that you can manage the Horizon subscription licenses.

If you are using a Horizon Term License, this component does not need to be installed.

While Horizon Cloud Connector can also enable additional SaaS services of Horizon Control Plane to be consumed, these services are currently only available for vSphere-based deployment.

  Omnissa Dynamic Environment Manager

Omnissa Dynamic Environment Manager offers personalization and dynamic policy configuration across any virtual, physical, or cloud-based environment.

• Simplify end-user profile management by providing organizations with a single and scalable solution that leverages existing infrastructure.
• Provide end users with quick access to a Windows WorkSpaces and applications, with a personalized and consistent experience across devices and locations.

Dynamic Environment Manager provides profile management by capturing user settings for the operating system and applications. Unlike traditional application profile management solutions, Dynamic Environment Manager does not manage the entire profile. Instead, it captures settings that the administrator specifies. This reduces login and logout time because less data needs to be loaded. User data is managed through folder redirection.

 Omnissa Access

Omnissa Access is an identity-as-a-service (IDaaS) offering. Access acts as an identity provider by syncing with Active Directory to provide single sign-on (SSO) for SaaS, web, cloud, and native mobile applications. It supports access to applications and desktops running Microsoft Windows Remote Desktop Services, XenApp 5.0 and later, ThinApp, SAML-based applications, and virtual desktops with Horizon. Access is also responsible for enforcing authentication policies based on networks, applications, or platforms.

While Access can be used to provide access to Horizon Manual Pools and Manual Farms running on Amazon EC2, Access cannot be directly installed in Amazon EC2 machines.

  Horizon Deployment Architecture on Amazon EC2

A typical Horizon architecture design uses a pod strategy. A pod is a unit of organization determined by Horizon scalability limits (which is up to 7 Connection Servers at the current time). Each pod has a separate management UI and therefore the typical design is to minimize the number of pods.

For this particular use case, you can deploy an AWS Virtual Private Cloud (VPC) within an AWS Region, spanning two Availability Zones (AZ). For a proof of concept, this could be a single AZ. This VPC holds AWS services shown in orange and basic components, Amazon Elastic Compute Cloud (EC2) VMs for Horizon infrastructure components shown in green, and Elastic Network Interfaces (ENI) installed on EC2 bare metal hardware.

Figure 1: Horizon Deployment Architecture on Amazon EC2

For the customer-managed VPC, a /20 CIDR is taken which is carved up into 4 subnets on both Availability Zones.

• Two /22 Orange subnets for private AWS components that use DHCP, like ENI and Directory Service
• Two /23 Green subnets for private Horizon components that use static addresses
• Two /24 Yellow subnets for public AWS components that use DHCP, like the public load balancer
• Two /25 Red networks for public Unified Access Gateway static addresses which also leverage a public Elastic IPv4 address

The public subnets have a default route towards the internet gateway, but the private subnets all point to the same NAT Gateway. On failure of the primary Availability Zone, an administrator will have to adjust the main route table to point to the NAT Gateway of the secondary Availability Zone to maintain certificate revocation checking and enable Identity Manager to synchronize changes.

For load balancing Unified Access Gateway and Horizon by default AWS Classic Load Balancers are used, which work with Cloud Password Identity Manager deployments. For more advanced deployments or when leveraging certificates/smartcards these can be replaced by a 3rd party load balancer such as F5 or KEMP.

By default, two Unified Access Gateways with the c5.large instance type are deployed, one on each AZ, capable of handling 1,000 sessions. For every extra 2,000 sessions two extra Unified Access Gateways should be deployed, one on each AZ, this also requires raising the EIP soft limit (default is 5, but 2 are taken by NAT gateways and 2 by the existing UAGs) through the Amazon VPC limits.

By default, four Horizon Connection Servers with the t3.xlarge instance type are deployed, two on each AZ, capable of handling 4,000 sessions on each AZ. For every extra 4,000 sessions two extra Connection Servers should be deployed, one on each AZ. One Cloud Connector with the t3.xlarge instance type is deployed.

Two Identity Manager Connectors with the t3.xlarge instance type should be deployed manually, which can handle the AZ maximum of 10 pods or 100.000 users.

For Dynamic Environment Manager and user profiles, at least two file servers (t3.xlarge with 5 General Purpose SSD EBS Volumes suggested per pod) should be deployed manually (or leveraging Amazon FSx for Windows File Server if available in the region) across the AZs.

When using multiple sites or regions a Global Service Load Balancer (GSLB) like Amazon Route 53 should be leveraged.

Deploying and Configuring Horizon Infrastructure Components

Deploying Horizon 8 on EC2 follows the same principles as installing Horizon 8 on a traditional vSphere-based, private data center. See the Horizon installation guide in the Horizon documentation for detailed instructions.

Example Configuration

The following illustrates a sample configuration for Horizon infrastructure components deployed on EC2.

1. VPC: In the AWS services console, under Services, navigate to and click VPC. In the VPC Dashboard, click Your VPCs. You should be able to view your newly created VPC in this window.
    
2. Subnets: In the VPC dashboard, select Subnets and search for the name you provided in the parameters section. This should search all the subnets which are in this deployment.
    
3. Route Tables: You should notice two route tables with EXTERNAL and INTERNAL in their names. The INTERNAL route table should say Yes in the Main column.
    
4. Directory Services: In the AWS services console, search for directory, and select Directory Services. In the directory services window, you should be able to view the domain name of the directory deployed using the template.
    
5. AWS RDS MS SQL: In the AWS services console, select RDS. In the Amazon RDS window, click Databases, and you should be able to view your database in the DB identifier column.
    
6. Horizon Connection Server: In the list of EC2 Instances, you will find two connection servers. You can identify these by the names you provided during deployment, or check for CS logical ID in the tag name of the EC2 Instance.
   1. CS01: Primary Connection Server
       
   2. CS02: Replica Connection Server
       
7. ELB for Connection Server: You will see a classic load balancer for connection servers deployed across two availability zones. The following screenshot shows the contents of the Description tab:
   
   The following screenshot shows the contents of the Instances tab:
    
8. Cloud Connector: A cloud connector instance will have a logical ID in the Instance tag, such as CloudConnectorInstance.
    
9. UAG: Two UAG instances will be deployed.
    

 Post Deployment Configuration

After the ELB deployment is successful, you need to make the following changes in the ELB settings to successfully connect this ELB to selected connection servers.

• Security Group: Allow the 80,443 HTTP inbound traffic from Anywhere for the time being
• Stickiness: AppCookieStickinessPolicy, cookieName='JSESSIONID'
• HEALTH CHECK condition to HTTPS: 443/favicon.ico
• LISTENER: HTTPS 443 -> HTTPS 443
•  For more information, see Unified Access Gateway - PowerShell deployment to Amazon AWS EC2

 Data Encryption

Refer to SSE-S3 or SSE-KMS encryption for Amazon S3 and Amazon EBS encryption.

 Monitoring

For details on how to monitor the various Horizon system health components, see Horizon support documentation:

• Monitor Horizon Connection Server Load Status
• Monitor Services on Horizon Connection Server
• Monitor Events in Omnissa Horizon

 Backup and Restore

For more information on how to backup and restore the Horizon configuration data and Connection server configuration data, see Maintaining Horizon Components.

 Upgrades and Patching

Refer to Horizon support documentation:

• Troubleshooting Errors During Upgrade and Installation of Connection Servers
• Removing the Entry for a Connection Server Instance Using the ‑S Option

 Support

The process to contact support is available at Omnissa Customer Connect.

Preparing Horizon 8 and the Amazon WorkSpaces Core Service

There are several prerequisite steps that must be completed prior to deploying a pool of desktops.

Set Up Amazon WorkSpaces Core as a Capacity Provider for Horizon

Before creating images and pools, Amazon WorkSpaces Core must be registered as a Capacity Provider on the connection server. This allows for the creation, management, and brokering of desktops by the connection servers. 

Note: Review all of the prerequisites outlined in the Horizon 8 product documentation prior to beginning the steps below.

Procedure

1. On the Horizon Connection Server, navigate to Settings > Servers > Capacity Providers.
2. Validate that you’ve configured one or more Amazon WorkSpaces Core providers.
   1. If none are present, press Add and provide the Name and Region
       

General Image Prerequisites

Like other non-vSphere virtual machines, Amazon WorkSpaces Core instances are registered with the Connection Server as part of the Horizon Agent installation process. Hence these machines are also referred to as registered non-vSphere virtual machines.

• Verify that you have administrative rights on the WorkSpaces Core machine(s).
• To make sure that remote desktop users are added to the local Remote Desktop Users group of WorkSpaces Core machine(s), create a restricted Remote Desktop Users group in Active Directory. See the Horizon Installation document for more information.
• Verify that you have prepared Active Directory. See the Horizon Installation document.
• If you are using a Windows Server OS as a virtual desktop (as opposed to using it as an RDS host), perform the steps described in Prepare Windows Server Operating Systems for Desktop Use.
• Familiarize yourself with the Horizon Agent custom setup options for non-vSphere machines. See Horizon Agent Custom Setup Options for Non-vSphere Machines.
• Familiarize yourself with the TCP ports that the Horizon Agent installation program opens on the firewall. See the Horizon Architecture Planning document for more information.
• If the machine has the Microsoft Visual C++ Redistributable package installed, verify that the version of the package is 2005 SP1 or later. If the package version is 2005 or earlier, you can either upgrade or uninstall the package.
• Download the Horizon Agent installer file from Omnissa Customer Connect and make a note of the location where it is downloaded.

Horizon Agent Considerations on Amazon WorkSpaces Core

• When selecting the Internet Protocol (IP) version, you may choose IPv4 or IPv6. You must install all Omnissa Horizon components with the same IP version.
• When selecting the FIPS configuration during the Horizon Agent installation, FIPS must be enabled in Windows.
• When you install Horizon Agent on an EC2 machine or Workspace, the following list of configurations are available to you. Some of them are non-optional and will be automatically installed on all guest operational systems on which they are supported. To change custom setup options after you install the latest Horizon Agent version, you must uninstall and reinstall Horizon Agent. For patches and upgrades, you can run the new Horizon Agent installer and select a new set of options without uninstalling the previous version. Note that the availability of these features is different depending on when you select IPv4 or IPv6.
  • Blast Extreme – Omnissa's in-house Blast Extreme protocol is supported with manual pools and is the only supported protocol for use with Horizon 8 automated pools running Amazon WorkSpaces Core instances.
  • PCoIP Agent - Lets users connect to the remote desktop with the PCoIP display protocol, supported only on manual pools.
  • Lync - Provides support for Microsoft Lync 2013 Client on remote desktops.
  • Unity Touch - Allows tablet and smartphone users to interact easily with Windows applications that run on the remote desktop. Users can browse, search, and open Windows applications and files, choose favorite applications and files, and switch between running applications, all without using the Start menu or Taskbar.
  • USB Redirection - Gives users access to locally connected USB devices on their desktops. USB redirection is supported on remote desktops that are deployed on single-user machines. In addition, redirection of USB flash drives and hard disks is supported on RDS desktops and applications. This setup option is not selected by default. You must select the option to install it. For guidance on using USB redirection securely, see the Horizon Security document. For example, you can use group policy settings to deactivate USB redirection for specific users.
  • Client Drive Redirection - Allows Horizon Client users to share local drives with their remote desktops. After this setup option is installed, no further configuration is required on the remote desktop. Client Drive Redirection is also supported on VDI desktops that run on managed, single-user virtual machines and on RDS desktops and applications.
  • Smartcard Redirection - Allows users to authenticate with smart cards when they use the PCoIP or Blast Extreme display protocol. Smartcard Redirection is supported on remote desktops that are deployed on single-user machines but is not supported on RDS host-based remote desktops.
  • Virtual Audio Driver - Provides a virtual audio driver on the remote desktop.
• To change custom setup options after you install the latest Horizon Agent version, you must uninstall and reinstall Horizon Agent. For patches and upgrades, you can run the new Horizon Agent installer and select a new set of options without uninstalling the previous version.

Creating Automated Pools

Automated pools allow Horizon 8 to use a template (called a Bundle in Amazon WorkSpaces Core) to deploy many desktop images without the need to individually customize each instance through a process called cloning. The image is registered with the Connection Server and the subsequent clones are automatically managed by the Horizon Pod.

Create Image(s)

One or more Image(s) need to be ingested into the Amazon platform. Once created and bundled, these can be used for either automatic or manual pools, depending upon the use case.

Procedure

1. Ensure that you have created an Amazon Simple Storage Service (S3) bucket to host the images. For setup information, please see Setting up Amazon S3.
2. Upload your BYOL image to the S3 bucket. For information on uploading to an S3 bucket, please see Uploading an object to your bucket.
3. Import the image into EC2 from the S3 bucket. For information on this process, please see Importing a VM as an image.
4. Import the image from EC2 into WorkSpaces Core.  For additional information, see Step 6: Create a BYOL image using the WorkSpaces Core console.

Create Gold Pattern and Bundle(s)

Next, a WorkSpaces Core Bundle must be created as a template.  A Bundle is a collection of the operating system as well as storage, compute, and software resources. For administrators familiar with VMware vSphere deployments, the Bundle is akin to the Virtual Machine settings for the parent image, setting such attributes like the vCPU count, RAM amount, virtual disk sizes, etc. More information about the types of bundles can be found in Amazon WorkSpaces Core Bundle Options.

Two Bundles will be created during this process:

• A Gold Pattern bundle where the Horizon Agent and other software will be installed. In a VMware vSphere deployment, this would be the gold image virtual machine.
• A Provisioning bundle created from the Gold Pattern that will be used for the creation of automated pools. In a VMware vSphere deployment, this would be akin to the snapshot of the gold image virtual machine.

Procedure

1. Create a new custom Bundle from the image created above, and provision a new instance of this bundle. This will become the Gold Pattern. For instructions, see Create a custom image and bundle.
2. Connect to the WorkSpaces Core instance via RDP and perform the standard image setup:
   1. Install and configure all third-party software required for the image.
   2. Install, and configure the Horizon 8 Agent, when prompted do not reboot.
3. On the Horizon Connection Server, register the Gold Image:
   1. Navigate to Settings > Registered Machines
   2. Select Others, then select the WorkSpaces Core instance from step 2.
   3. Select Set Gold Image, then OK
4. Return to the WorkSpaces Core instance and select Finish, then reboot.
5. Create an image and bundle from the WorkSpaces Core instance created above. This new Bundle will be used to provision automated pools. For information please see Step 3: Create a custom image and custom bundle.

Create Automated Pools

Automated Pools allow Horizon to create Amazon WorkSpaces Core instances automatically from the Gold Image.  This helps reduce administrative overhead and removes the need to customize each instance individually.

Procedure

1. On the Horizon Connection Server, select Inventory > Desktops and Add a new Pool.
2. On the Add Pool – Type section, select Automated Desktop Pool, then click Next.
3. On the Capacity Provider section, select the appropriate Amazon WorkSpaces Core deployment, then click Next.
    
4. Select the desired User Assignment method, then click Next.
5. For Desktop Pool Identification, enter a Pool ID, a Display Name, and Domain, select the Bundle created above, then click Next.
    
6. Complete the pool creation with the desired configuration. Note: For the machine naming pattern, a four-digit unique identifier will be appended to the end of each machine name in the VM Name field.

Creating Manual Pools

Like other non-vSphere virtual machines, Amazon WorkSpaces Core are registered with Connection Server as part of the Horizon Agent installation process. Hence these machines are also referred to as registered non-vSphere virtual machines.

Procedure

1. Prepare the non-vSphere virtual machine to deliver remote desktop access. Before you add this virtual machine to a manual desktop pool, you must prepare each machine individually.
2. Install Horizon Agent into these Amazon WorkSpaces Core. As part of the installation process, these WorkSpaces Core are now registered with Horizon. These machines are also referred to as registered virtual machines. To prepare non-vSphere virtual machines, see Prepare a non-vSphere Machine for Horizon 8 Management.
3. Gather the configuration information that you must provide to create the pool. See Worksheet for Creating a Manual Desktop Pool.
   1. Power policies are not supported for manual desktop pools that contain registered non-vSphere virtual machines because these machines are not directly managed by vSphere.
   2. 3D rendering options are not applicable for manual desktop pools that contain registered non-vSphere virtual machines. However, these virtual machines can directly leverage GPU capability available to the Horizon Agent operating system. Verify the graphics support with the third-party virtualization platform vendor.
4. Create the manual desktop pool and select the Other sources option to select the registered non-vSphere virtual machine as the desktop pool source. See Create a Manual Desktop Pool.
5. Entitle users to access the manual desktop pool. See Entitling Users and Groups in the Horizon Administration document.
6. Perform management tasks on non-vSphere registered machines. See Managing non-vSphere Registered Machines.

Preparing Amazon WorkSpaces Core Instances

When using manual pools, each WorkSpaces Core Instance must be configured separately.  The following procedures outline the customization required for correction functionality.

Procedure

1. Power on the WorkSpaces Core machine(s) and verify that it is accessible to the Connection Server instance.
2. Join the WorkSpaces Core to the Active Directory domain for your remote desktops.
3. Configure the Windows firewall to allow Remote Desktop connections to the WorkSpaces Core.

Creating a Manual Pool of Amazon WorkSpaces Core Machines

This section describes the process for creating a manual pool of Amazon WorkSpaces machines.

Prerequisite

• Prepare the machines to deliver remote desktop access.
• In a manual pool, you must prepare each machine individually.
• Horizon Agent must be installed and running on each machine.
• To prepare non-vSphere virtual machines or physical computers, see Managing non-vSphere Registered Machines.

Procedure

1. In Horizon Console, select Inventory > Desktops.
2. Click Add to pull up the Add Pool wizard.
3. In the Type pane, select Manual Desktop Pool.
4. In the Machine Source panel, choose Other sources.
5. In the User Assignment panel:
   • Choose the type of User Assignment:
     • In a dedicated-assignment pool, each user is assigned to a machine. After a user is assigned a desktop, no other user can use the desktop. Users receive the same machine each time they log in.
     • In a floating-assignment pool, users receive different machines each time they log in.
     • For details, see Assign a Machine to a User in a Dedicated-Assignment Pool.
   • Choose Enable Automatic Assignment if using a dedicated-assignment pool. For floating-assignment pools, this is automatically enabled for you. When enabled, a machine is assigned to a user when the user first logs in to the pool. If you do not enable Automatic Assignment, you must explicitly assign a machine to each user. You can assign machines manually even when Automatic Assignment is enabled.
   • Choose Enable Multi-User Assignment if using a dedicated-assignment pool. For floating-assignment pools, this option is not available. When this option is enabled, you can assign multiple users to each machine in the pool. However, only one user can log in to the machine at any given time. If an assigned user has a connected or disconnected session on a multi-user assignment machine, other assigned users will be unable to launch a session on that machine. Multi-user assignment is not supported for automatic user assignment desktop pools.
6. In the Desktop Pool ID panel:
   • ID. Type the desired ID for the pool you are creating. This is the pool name that users see when they log in to their desktop in Horizon Client. This ID is the unique identifier for the pool. If you have a vCenter running separately in your Horizon pod, make sure that vCenter Server is not using the same pool ID.
   • Display Name. Optionally, you can add a Display Name. This is the name of the desktop that end-users will see when they connect to the Horizon Client. If this field is left blank, the ID will be shown to the end-users.
   • Access Group. Optionally, you can specify an Access Group for the pool. If you use an access group, you can delegate managing the pool to an administrator who has a specific role. If you do not specify an Access Group for this pool, you are leaving the pool in the default root access group. Most customers do not use Access Group.
   • Description. Optionally, you can specify a description for the pool. This is only visible to administrators.
7. In the Desktop Pool Settings panel:
   1. Specify State.
      • Enabled. After being created, the desktop pool is enabled and ready for immediate use.
      • Disabled. After being created, the desktop pool is deactivated and unavailable for use. This is an appropriate setting if you want to conduct activities such as testing or other forms of baseline maintenance. When this state is in effect, remote desktops are unavailable for use.
   2. Optionally, you can specify Connection Server Restrictions. This capability allows you to restrict or separate incoming end-user connection requests by connection server for security purposes.
      • None. The desktop pool can be accessed by any Connection Server instance.
      • With tags. Select one or more Connection Server tags to make the desktop pool accessible only to Connection Server instances that have those tags. You can use the check boxes to select multiple tags.
      • If you intend to provide access to your desktops through Omnissa Access, and you configure Connection Server restrictions, the Omnissa Access app might display desktops to users when those desktops are restricted. Omnissa Access users will be unable to launch these desktops.
   3. Optionally, you can specify a Category Folder. This specifies the name of the category folder that contains a Start menu shortcut for the desktop pool entitlement on Windows client devices.
   4. Optionally, you can enable Client Restrictions. Select whether to restrict access to entitled desktop pools from certain client computers. You must add the names of the computers that are allowed to access the desktop pool in an Active Directory security group. You can select this security group when you add users or groups to the desktop pool entitlement.
   5. Specify Logoff After Disconnect setting:
      1. Immediately. Users are logged off as soon as they disconnect.
      2. Never. Users are never logged off.
      3. After. The time after which users are logged off when they disconnect. Type the duration in minutes. The log off time applies to future disconnections. If a desktop session was already disconnected when you set a log off time, the log off duration for that user starts when you set the log off time, not when the session was originally disconnected. For example, if you set this value to five minutes, and a session was disconnected 10 minutes earlier, Horizon will log off that session five minutes after you set the value.
   6. Optionally select Show Assigned Machine Name. This is only available for Dedicated Assignment desktops. This displays the host name of the assigned machine instead of the pool display name when the user logs into their Horizon Client to launch their desktop. If the machine is assigned, then Display Name (Machine not assigned) will be displayed.
   7. Optionally select Show Machine Alias Name. This is only available for Dedicated Assignment desktops. Show the machine alias name in Horizon Client launch items for assigned users. If this option is not selected, but Show Assigned Machine Name is selected, the machine hostname is shown.
   8. If neither Show Assigned Machine Name or Show Machine Alias Name are selected, then the pool name is displayed to the user in their Horizon Client.
8. In the Remote Display Protocol panel:
   1. Select Default Display Protocol. You can choose Omnissa Blast, PCoIP, or Microsoft RDP.
      1. Omnissa Blast. The Omnissa Blast Extreme protocol is built on the H.264 protocol and supports the broadest range of client devices, including smartphones, tablets, ultra-low-cost PCs, and Macs, across any network.
      2. PCoIP. PCoIP is supported as the display protocol for virtual and physical machines that have Teradici hardware. PCoIP provides an optimized PC experience for the delivery of images, audio, and video content for a wide range of users on the LAN or across the WAN.
      3. Microsoft RDP. Microsoft Remote Desktop Connection (RDC) uses RDP to transmit data. RDP is a multichannel protocol that allows a user to connect to a computer remotely.
   2. Select whether to Allow Users to Choose Protocol. When selected, this allows users to override the default display protocol for their desktops in Horizon Client.
   3. Optionally enable Allow Session Collaboration. When enabled, this allows users of the pool to invite other users to join their remote desktop sessions. Session owners and session collaborators must use the Omnissa Blast display protocol.
      1. In the Machines panel, you can select one or more EC2 machines or WorkSpaces Core to add to this manual pool.
      2. In the Ready to Complete panel, confirm your selections and then press Finish.

Note: Horizon Manual Pool with WorkSpaces Core can directly leverage GPU capabilities available to those machines. Ensure that you have the appropriate GPU-enabled AWS instances before adding them to the Horizon Manual Pool.

In Horizon Console, you can view the machines as they are added to the pool by selecting Inventory > Desktops. Now you can entitle users to access the pool. See Entitling Users and Groups in the Horizon Administration document.

You can also view the individual EC2 machines and Amazon WorkSpaces Core that have been registered with Horizon (for example, have Horizon Agent installed) by navigating to Settings > Registered Machines > Others.

Managing A Manual Pool or Farm Created from Amazon WorkSpaces Core

This section details how to remove registered machines from manual desktop pools and Horizon.

Remove a Registered Machine from a Manual Desktop Pool

You can reduce the size of a desktop pool by removing registered machines from the pool.

Procedure

1. In Horizon Console, select Inventory > Machines.
2. Select the Others tab.
3. Select the unmanaged machines to remove.
4. Click Remove.
5. Click OK.

Remove Registered Machines From Horizon

If you do not plan to use a registered machine again, you can remove it from Horizon.

After you remove a registered machine, it becomes unavailable in Horizon. To make the machine available again, you must reinstall Horizon Agent.

Prerequisites

Verify that the registered machines that you want to remove are not being used in any desktop pool.

Procedure

1. In Horizon Console, select Settings > Registered Machines.
2. Click the RDS Hosts tab.
3. Select one or more machines and click Remove.
   You can select only machines that are not being used by a desktop pool.
4. Click OK to confirm.

Summary and Additional Resources

 This operational tutorial explored several options to deploy Horizon 8 with AWS. Whether you want to deploy in a hybrid cloud or pure cloud model, extend an existing or expand with a new Horizon pod to AWS, leverage manual desktops and farms, or the complete Horizon stack, there is an architecture available to support you.

Procedures included:

• Deploying Horizon infrastructure on Amazon EC2 devices
• Deploying Horizon Automated Pools using Amazon WorkSpaces Core
• Deploying Horizon Manual Pool or Farm using Amazon EC2 devices
• Managing Manual Pools or Farms created from Amazon WorkSpaces Core

Additional Resources

For more information, you can explore the following resources:

• Extending Omnissa Horizon to Amazon WorkSpaces Core
• For more information about creating manual non-vSphere virtual desktop pools, see the Desktops and Applications in Horizon 8 document.
• For more information about creating manual published desktop pools or manual RDS host farms, see the Setting Up Published Desktops and Applications in Horizon document.
• For more information about creating a manual desktop pool that uses Linux virtual machines, see the Setting Up Linux Desktops in Horizon document.

Changelog

The following updates were made to this guide:

About the Author and Contributors

This document was written by the following collaborators:

• Mike Erb, Staff EUC Architect, Technical Marketing, Omnissa
• Dan Berkowitz, Senior Product Line Manager, Broadcom
• Nguyen Kim, Product Manager, Omnissa
• Josh Spencer, Group Product Line Manager, Omnissa
• Angela Ge, Director, Product Management - Horizon, Omnissa

Feedback

Your feedback is valuable.

To comment on this paper, contact Omnissa End-User-Computing Technical Marketing at  tech_content_feedback@omnissa.com