Horizon 8 Configuration

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about common configuration and deployment tasks for Omnissa Horizon 8. It is not intended to replace the product documentation but to reference and supplement it with additional guidance.

Horizon Installation and Configuration

This section provides an overview of the Horizon 8 deployment process, points to specific documents for detailed instructions, and lists certain settings that were used in this reference architecture.

Prerequisites

Before starting, certain other infrastructure components must be in place and configured. Refer to Environment Infrastructure Design, and see the following sections in that chapter:

• Management VMware vSphere cluster, as described in the vSphere section
• VDI vSphere cluster, as described in the vSphere section
• Active Directory, as described in the Active Directory section
• DNS, as described in the DNS section
• DHCP, as described in the DHCP section
• Certificate Authority, as described in the Certificate Authority section
• A load balancer, as described in the Load Balancing sections in Horizon 8 Architecture.

You must also create a Windows Server RDSH VM template, using the guidelines in Manually Creating Optimized Windows Images for Horizon VMs.

Installation Steps

This section outlines the Horizon installation steps.

1. Set up the required administrator users and groups in Active Directory.
2. If you have not yet done so, install and set up VMware ESXi hosts and VMware vCenter Server.
3. Install and set up Connection Servers. Also install the event database.
4. Create one or more VMs that can be used as a template for full-clone desktop pools or as a golden image for instant-clone desktop pools.
5. Set up an RDSH server VM and install applications to be remoted to end users.
6. Create desktop pools, application pools, or both.
7. Entitle users to desktops and published applications.
8. Install Horizon Client on end users’ machines and have end users access their remote desktops and applications.
9. (Optional) Set up and configure enrollment servers to enable True SSO. See Setting Up True SSO.
10. (Optional) Create and configure additional administrators to allow different levels of access to specific inventory objects and settings.
11. (Optional) Configure policies to control the behavior of Horizon components, desktop and application pools, and end users. See Configuring Settings for Client and Console Sessions.
12. (Optional) For added security, integrate smart card authentication or a RADIUS two-factor authentication solution, especially where external access is allowed. This is covered in Unified Access Gateway Architecture.

Preparation

Build Windows Server VMs: at least two for Connection Servers and two for the enrollment servers (required for True SSO).

Follow the hardware specifications in Reference Architecture VM Specifications, assign the VMs static IP addresses and join them to the active directory domain.

Deployment

This guide is not intended to replace the Horizon 8 documentation. Follow the relevant section of the Horizon Installation and Upgrade documentation to install the following components in the following order:

1. Install the first standard Connection Server – See Install Horizon Connection Server with a New Configuration.
2. Install a second Connection Servers into the pod – See Install a Replicated Instance of Horizon Connection Server.
3. Connect the Horizon pod to the Horizon Cloud Service to enable the use of subscription licensing and the use of cloud services. For more information, see Horizon Cloud Service section in the Horizon 8 Architecture chapter.
   
   1. To connect to Horizon Cloud Service – next-gen, deploy a Horizon Edge Gateway Appliance.
   2. To connect to Horizon Cloud Service – first-gen, deploy a Horizon Cloud Connector.
4. Install enrollment servers – See Setting Up True SSO in the Horizon documentation and Setting Up True SSO in this document.

Post-Installation Configuration

Connect to the first Connection Server and perform the following tasks in the following order:

1. Apply the term license key – See Add or Update Horizon 8 License.
   Note: This step is not necessary if subscription licensing is being used and you have connected to Horizon Cloud Service by deploying either the Horizon Edge Gateway appliance or the Horizon Cloud Connector.
2. Add vCenter Server and configure the View Storage Accelerator – See Configuring Horizon for the First Time.
3. Add instant clone domain administrators – See Add an Instant-Clone Domain Administrator.
4. Configure event reporting – See Configuring Event Reporting in Horizon Console.
5. Assign administrators and roles – See Configuring Role-Based Delegated Administration.
6. Register Unified Access Gateways – See Monitoring Unified Access Gateway in Horizon Console.
   
   1. This provides visibility of the Unified Access Gateways on the dashboard.
7. Register App Volumes Managers – See Add an App Volumes Manager.
   
   1. This is required when using Apps on Demand to allow the Connection Servers to communicate with the App Volumes Managers.
   2. When using multiple App Volumes Managers, register the load balancer FQDN instead of individual App Volumes Managers. Only one App Volumes Manager address can be associated with each RDSH farm, so using the load balancer address allows all App Volumes Managers, that are in the load balancer pool, to be able to respond to requests from the Connection Servers.
8. For each of the Connection Servers, configure the following.

Table 1: Connection Server Configuration Tasks

checkOrigin=false
balancedHost=horizon.example.com
portalHost.1=unified-access-gateway-name-1.example.com
portalHost.2=unified-access-gateway-name-2.example.com

Certificates

When you first install Horizon, it uses self-signed TLS certificates. It is not recommended that you use these in production. At a high level, the steps for replacing the certificates on the Connection Servers and the Composer server are:

1. Create a certificate signing request (CSR) configuration file. This file is used to generate the CSR to request a certificate.
2. Once you receive the signed certificate, import it.
3. Configure Horizon to use the signed certificate.

For the full process, see Configuring TLS Certificates for Horizon 8 Servers.

Desktop Pool Settings

The following table lists specific desktop pool settings that were used in this reference architecture.

Table 2: Configuration Settings for Instant-Clone Desktop Pools

RDS Farm Settings

The following table lists specific RDSH server farm settings that were used in this reference architecture.

Table 3: Configuration Settings for RDSH Server Farms

Cloud Pod Architecture

If multiple Horizon pods are being used, Cloud Pod Architecture (CPA) can be configured. This is especially useful when configuring multiple sites, where each site should have its own separate pod. Where Universal Broker is being used, either that or Cloud Pod Architecture should be configured. More detail on Cloud Pod Architecture can be found in Horizon 8 Architecture.

Create the Pod Federation

1. Connect to the Horizon Administrator console on one of the Connection Servers in the first pod (Site 1).
2. Choose the task to initialize the Cloud Pod Architecture feature.
3. Rename the pod federation if desired.
4. Rename the site.
5. Rename the pod if desired.

Join Another Pod to the Federation

1. Connect to the Horizon Administrator console on one of the Connection Servers in the that pod (Site 2).
2. Choose the option to join the pod federation.
3. Enter the FQDN of a Connection Server from the first pod, along with credentials.
4. If this pod is in another physical location, create a new site.
5. Edit the newly added pod.
   
   1. Rename the pod if desired.
   2. Move the pod to the appropriate site.

See Join a Pod to the Pod Federation in Horizon Console for full instructions.

Cloud Pod Architecture Global Entitlement Settings

For this reference architecture, Universal Broker and multi-cloud assignments were used. In previous iterations of the reference architecture Cloud Pod Architecture and global entitlements were used. Although not used in this deployment, for reference the global entitlement settings are given below.

Table 11: Global Entitlement Settings for Roaming User Use Case

This configuration allows anyone connecting to the federation through the global namespace, https://horizon.vmweuc.com for this environment, to get a desktop no matter which pod they get connected to.

Table 12: Global Entitlement Settings for Power User Use Case

This global entitlement configuration splits a group of users, PowerUsers, into two groups. This allows for initial user placement by making sure all the members of PowerUsers are not working from the same data center.

This configuration also enables and forces the presence of a home site for the entitled groups in conjunction with defining the scope to be Within Site. This effectively means that the two groups are associated with a home site that dictates their preferred placement.

Home Site Configuration When Both Sites Are Operational 

The home site configuration for the two groups is as shown in the following table. 

Table 13: Initial Placement in Different Data Centers

With this configuration, and under normal operating conditions, 

• A member of Site1-PowerUsers is always given a desktop resource in Site 1.
• A member in Site2-PowerUsers always gets a desktop resource in Site 2.

Home Site Override – Preparing for Failover 

The configuration shown in the preceding section is suitable when both sites are online and fully operational. But using just this global entitlement would cause issues because, in the event of either of the sites being unavailable, part of the user base would not be able to log in.

Additional configuration is required to reverse the logic so that users associated with a site that is currently offline can be temporarily allowed to connect and log in to another site.

For a given global entitlement, it is possible to configure a home site override option that does exactly this.

Table 14: Override Configurations to Use During an Outage

Notice how this effectively overrides the home site configuration for those groups at the global entitlement level to reverse the logic, allowing members from group Site1-PowerUsers to connect to Site 2 and members from group Site2-PowerUsers to connect to Site 1.

Note: This change should only be made for the group impacted by a data center outage. At no point in time would both the override options be configured as depicted in the preceding table; the override should be configured only for the group impacted.

The home site override configuration should only be changed after a failed site’s resources have been fully failed over. The reverse-logic configuration is of no use if users access the site before their resources are available.

Setting Up True SSO

True SSO provides users with SSO to Horizon desktops and applications regardless of the authentication mechanism used. See the True SSO section in Horizon 8 Architecture for more details.

Note: When deploying in Horizon Cloud first-gen on Microsoft Azure, see Setting Up True SSO for First-Gen Horizon Cloud Service on Microsoft Azure for specific platform instructions.

The high-level steps that need to be completed to deploy True SSO for Horizon are:

1. Configure Horizon and Workspace ONE Access Integration.
2. Install and configure Microsoft Certificate Authority service.
3. Set up a certificate template for use with True SSO.
4. Install and configure the enrollment servers.
5. Add Workspace ONE Access as a SAML Authenticator to the Connection Servers.
6. Add the Horizon pods to Workspace ONE Access.

For more information on how to install and configure True SSO, see Setting Up True SSO.

Horizon and Workspace ONE Access Integration

As a prerequisite, integrate Horizon and Workspace ONE Access. Guidance on this is given in Platform Integration.

Set Up a Microsoft Enterprise Certificate Authority

1. Add the Active Directory Certificate Services Server role using the Add Roles and Features Wizard. The only role service required is Certification Authority.
2. Once installed, configure Active Directory Certificate Services using the following values.

Table 4: Settings for Active Directory Certificate Services

3. The final configuration is done by opening a command prompt, as an Administrator, and running the following commands:
   
   1. Enable non-persistent certificate processing and help reduce the CA database growth rate:

certutil -setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS

2. Ignore offline CRL (certificate revocation list) errors on the CA:

certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

3. Restart the Certificate Authority Service so that these changes can take effect.

sc stop certsvc
sc start certsvc

Repeat these steps (1 to 3) on each Certificate Authority server. Also see Set Up an Enterprise Certificate Authority.

Create and Issue a Certificate Template

As preparation, create an active directory security group for the enrollment server computer accounts. This will be used when creating the certificate template and assigning permissions to the enrollment servers. A group makes adding new enrollment servers easier.

1. Create a new certificate template by first opening the Certification Authority administrative tool.
   
   1. Expand the tree in the left pane, right-click Certificate Templates and select Manage. Right-click the Smartcard Logon template and select Duplicate Template.
   2. Do not click OK until you have completed all the configurations listed in the following table.

Table 5: Configuration Settings for the Certificate Template

2. Before closing the Certificate Template console, change the permissions on the Enrollment Agent (Computer) template.
   Add the security group that you created for the enrollment server computer accounts and give it read and enroll permissions.
3. Close the Certificate Template console.
4. Issue the True SSO certificate template.
   
   1. Right-click Certificate Templates and select New > Certificate Template to Issue.
   2. Select the new True SSO template you just created.
      This step is required for all certificate authorities that issue certificates based on this template. Repeat the issuance on all certificate authority servers.
5. Issue the Enrollment Agent (Computer) certificate template.
   
   1. Right-click Certificate Templates and select New > Certificate Template to Issue.
   2. Select the Enrollment Agent (Computer) Template.
      This step is required for all certificate authorities that issue certificates based on this template. Repeat the issuance on all certificate authority servers

See Create Certificate Templates Used with True SSO.

Enrollment Server Setup

The next steps are to install the Horizon enrollment service, enable it to request certificates, and pair it the Connection Servers. See Install and Set Up an Enrollment Server.

Install the Enrollment Server Service

1. Run the Horizon Connection Server installer.
2. Select the Horizon Enrollment Server role.

Install the Enrollment Agent (Computer) Certificate.

This authorizes this enrollment server to act as an Enrollment Agent and generate certificates on behalf of users.

1. Open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
2. Expand Certificates > Personal folder.
3. Right-click All tasks > Request New Certificate.
4. Request and enroll the Enrollment Agent (Computer) certificate.

Configure Connection Server Pairing

Next, configure Connection Server pairing so that the enrollment service will trust the Connection Server when it prompts the enrollment servers to issue the short-lived certificates for Active Directory users.

1. Export certificate from Connection Server:
   
   1. On one of the Connection Servers, open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
   2. Expand Certificates > VMware Horizon View Certificates > Certificates folder.
   3. Right-click the certificate file with the friendly name vdm.ec, and select All Tasks > Export.
   4. In the Certificate Export wizard, accept the defaults, including leaving the No, do not export the private key radio button selected.
   5. Save the file with a meaningful name such as s1-pod1-enrollclient.cer.
   6. This step only needs to be done from one of the Connection Servers in the pod.
2. Import the certificate to the enrollment server:
   
   1. On the enrollment server, open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
   2. Expand Certificates > VMware Horizon View Enrollment Server Trusted Roots folder.
   3. Right-click All tasks > Import and browse to the file you saved from the Connection Server export.
   4. Ensure that the certificate will be placed in the VMware Horizon View Enrollment Server Trusted Roots store.
3. Configure the enrollment service to give preference to the local certificate authority when they are co-located:
   
   1. Edit the registry using regedit.exe as an administrator.
   2. Browse to the following location: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\Enrollment Service. You must create the Enrollment Service key if it does not already exist.
   3. Right-click and add a new String Value (REG_SZ)
      Name: PreferLocalCa Value data: 1

Repeat steps 2 and 3 on each Enrollment Server. Also see Enrollment Server Configuration Settings.

Connection Server Configuration

The last configuration is to add the enrollment servers to the Horizon Connection Servers, and to enable the authenticators. On one of the Connection Servers in the pod, open a command prompt, as an administrator, and browse to C:\Program Files\VMware\VMware View\Server\tools\bin. You will use the vdmutil.exe command tool in the following steps. Note that some steps will require synchronization to occur. Use the list commands indicated below to ensure that the previous step has completed before moving on to the next step.

1. Add the enrollment servers to environment.
2. List enrollment servers to confirm their details.
3. Create the connectors.
4. List the SAML authenticator details.
5. Enable TrueSSO for the SAML Authenticator

The parameters are case-sensitive.

In each of the commands you need to specify credential parameters:

--authAs <administrator>
--authDomain <domain>
--authPassword <Password>

The following tables provide the syntax and examples for performing each of these steps. For more information about these steps, also see Configure Horizon Connection Server for True SSO.

Table 6: Step 1: Add Enrollment Servers (ES) to Environment

vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --environment --add --enrollmentServer <enrollment Server FQDN>

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --environment --add --enrollmentServer s1hes1.vmweuc.com  

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --environment --add --enrollmentServer s1hes2.vmweuc.com  

Table 7: Step 2: List Enrollment Servers (ES)

vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --environment --list –-enrollmentServers
vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --environment --list –-enrollmentServer <enrollment Server FQDN> --domain <domain FQDN>

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --environment –-list --enrollmentServers

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --environment –-list --enrollmentServer s1hes1.vmweuc.com --domain vmweuc.com

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --environment --list –-enrollmentServer s1hes2.vmweuc.com --domain vmweuc.com

 Table 8: Step 3: Create Connectors

vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --create --connector --domain <domain FQDN> --template TrueSSO-template-name --primaryEnrollmentServer <enrollment Server FQDN> --certificateServer <Domain-CA> --mode enabled

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --create --connector --domain vmweuc.com --template TrueSSO --primaryEnrollmentServer s1hes1.vmweuc.com --secondaryEnrollmentServer s1hes2.vmweuc.com --certificateServer vmweuc-S1HES1-CA,vmweuc-S1HES2-CA --mode enabled

Table 9: Step 4: List SAML Authenticator

vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --list -–authenticator

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --list –-authenticator

Table 10: Step 5: Enable TrueSSO for the SAML Authenticator

vdmutil --authAs <administrator> --authDomain <domain> --authPassword <Password> --truesso --authenticator --edit --name <Workspace ONE Access FQDN> --truessoMode ENABLED

vdmutil --authAs administrator --authDomain vmweuc --authPassword Password --truesso --authenticator --edit --name my.vmweuc.com --truessoMode ENABLED

Finally, in any pod with two enrollment servers, change load balancing to round robin instead of the default active/passive. This only needs to be done on one Connection Server per pod.

1. On one of the Connection Servers, from Windows Administrative Tools, open ADSI Edit.
2. Right-click Connect to and define the Connection Settings.
3. For the Connection Point setting, choose the option for Select or type a Distinguished Name and type vdi
4. For the Computer setting, type localhost:389
5. Expand OU=Properties, select OU=Global, and double-click CN=Common in the right pane.
6. Edit the pae-NameValuePair attribute.
7. Add a new value cs-view-certsso-enable-es-loadbalance=true and click OK.

See Connection Server Configuration Settings.

Implement True SSO in Cross-Forest Environments

The following steps provide an overview for setting up True SSO in cross-forest environments. Review the guidance and scenarios in the Cross-Forest Scenarios section of Active Directory Domains.

Take note of:

• Which forest and domain is your resource forest and which resource domain in it will contain the Enrollment Servers.
• Which forests and domains contain the user accounts and will be your user account forests and domains.
• The location of the enterprise certificate authorities (CA) in relation to these forests and domains.

Step 1 – Validate True SSO Readiness in Horizon 8

As a first step, setup a basic True SSO configuration in the resource domain. This establishes a baseline before configuring cross-forest domains.

1. Set up and configure True SSO as described in Setting Up True SSO in this guide and in Setting Up True SSO in the Horizon 8 product documentation.
2. Check the status of True SSO using the health dashboard in the Horizon Admin Console and validate functionality.

Figure 3: Single Domain True SSO Status in Horizon Connection Server Dashboard

Step 2 – Validate Microsoft Services for True SSO

The following are referenced from Microsoft’s AD CS: Deploying Cross-forest Certificate Enrollment.

Disclaimer: it is recommended that you validate these steps in test environments before applying any settings to a production environment. Reach out to your Microsoft AD CS subject matter expert to ensure these steps meet your organization’s standard practices.

Active Directory

1. Verify that the two-way forest transitive trust exists between the resource forest and the user account forest.
2. Confirm Domain or Enterprise Administrator permissions to access enterprise certificate authorities in the resource and user account forests.

PKI Objects

1. If an enterprise certificate authority exists in the user account forest, verify that it is reachable from the resource domain.
2. Enable LDAP referral on the enterprise certificate authority in the resource forest using the certutil command.

certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS

3. Verify the enterprise certificate authority computer accounts in the resource forest are members of the CA Publisher Group in the user account forest.
4. Verify the domain controller security group has permission to enroll in the domain controller authentication template. See Knowledgebase article 59953.
5. Export the root and enterprise certificate authority certificates from the resource forest, and then publish these exported certificates to their respective containers (RootCA, AIA, NTAuthCA, and SubCA) in the user account forest.
   
   1. Run the certutil commands referenced in steps number 8 and 9 from Deploying AD CS for cross-forest certificate enrollment.

certutil -config <Computer-Name>\<Root-CA-Name> -ca.cert <root-ca-cert-filename.cer>
certutil -dspublish -f <root-ca-cert-filename.cer> RootCA
certutil -config <Computer-Name>\<Enterprise-CA-Name> -ca.cert <enterprise-ca-cert-filename.cer>
certutil -dspublish -f <enterprise-ca-cert-filename.cer> NTAuthCA
certutil -dspublish -f <enterprise-ca-cert-filename.cer> SubCA

6. Use AD CS: PKISync.ps1 Script for Cross-forest Certificate Enrollment to copy the following certificate templates to the user account forest referenced in Copying PKI objects to account forests
   
   1. True SSO certificate template.
   2. In the scenario when the user account forest does not contain an enterprise certificate authority, also copy the Domain Controller Authentication certificate template.

Step 3 - Verify CertState of the Enrollment Server

1. Run the following vdmutil command on a Horizon Connection Server.

vdmUtil --authAs admin-role-user --authDomain netbios-name --authPassword admin-user-password --truesso --environment --list --enrollmentServer enroll-server-fqdn --domain domain-fqdn

2. The domain in the user account forest should now appear as 'VALID' for Enrollment Certstate. Below is an example screenshot of True SSO across 3 Active Directory forests.

Figure 4: Verify CertState of Enrollment Server

Step 4 - Create a True SSO connector for the User Account Forest

1. Use the same command for creating a True SSO connectors as you did during the initial setup, but specify the user account domain in the domain field.

vdmUtil --authAs admin-role-user --authDomain netbios-name --authPassword admin-user-password --True SSO --create --connector --domain domain-fqdn --template template-name --primaryEnrollmentServer enroll-server1-fqdn [--secondaryEnrollmentServer enroll-server2-fqdn] --certificateServer CA-common-name --mode {enabled |disabled}

Step 5 - Verify True SSO Health Status

1. Check the status of True SSO via the health dashboard in the Horizon Admin Console and validate functionality.

Figure 5: Cross-forest Domains True SSO Status in Horizon Connection Server Dashboard

Troubleshooting Common True SSO issues

The following Knowledgebase articles are useful in helping to resolve common problems.

• Common Configuration Issues and Guidelines with TrueSSO (90037).

•  True SSO - Public Key Infrastructure: "The request is not supported" while launching a published Application or Desktop(59953)  - Outlines an error message received if the authenticating domain controller is not configured for smartcard logons.
•  True SSO - Public Key Infrastructure: Cannot create a True SSO Connector on the enrollment server on a domain with NOT_VALID enrollment certificate status (86228) - Outlines some steps to verify in relation to the enrollment of certificates and your PKI infrastructure when the cert state is reported as ‘Not Valid’.
•  True SSO – Enrollment Server unable to connect to CA: The authentication service is unknown (90682) - Outlines a workaround when the Certificate Authority and Enrollment Server are co-installed.
•  True SSO - Public Key Infrastructure - Error: "The attempted logon is invalid. This is either due to a bad username or authentication information. An untrusted certificate authority was detected while processing the domain controller certificate" (94971) - Outlines symptoms when a CA certificate is not present or auto enrollment has been disabled.
•  True SSO - Public Key Infrastructure - CRL : Error: "The attempted logon is invalid. The revocation status of the certificate used for authentication could not be determined (89994) - Outlines a scenario where the Certificate Revocation List (CRL) of the Certificate includes a URL that cannot be accessed from the Virtual Desktop or Domain Controllers.
•  True SSO - Public Key Infrastructure - CRL : Error: "Encountered unexpected error during execution" seen when using vdmutil to reconfigure Horizon True SSO (85571) - Outlines a scenario when editing your True SSO connector results in an Error.
•  True SSO - Public Key Infrastructure: Certificate Distribution Point Location expiration results in a VDI Launch Failure (90491) - Outlines a scenario when a CDL expiration can impact successful login.

Setting Up True SSO for First-Gen Horizon Cloud Service on Microsoft Azure

For detailed information on how to install and configure True SSO, see Configure True SSO for Use with Your Horizon Cloud Environment.

The high-level steps that need to be completed are:

1. Install and configure a Certificate Authority. See Set Up a Microsoft Enterprise Certificate Authority.
2. Set up a certificate template on the Certificate Authority. See Create and Issue a Certificate Template.
3. Download the Horizon Cloud pairing bundle from the Administration Console's Active Directory page.
   
   1. The pairing bundle is used when setting up the Enrollment Server.
4. Set up the Enrollment Server.
5. Configure the Enrollment Server to prefer to use the local Certificate Authority service. See Enrollment Server Configuration Settings.
   
   1. Edit the registry on the Enrollment servers using regedit.exe as an administrator.
   2. Browse to the following location: HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Enrollment Service. You must create the Enrollment Service key if it does not already exist.
   3. Right-click and add a new String Value (REG_SZ):
      Name: PreferLocalCa
      Value data: 1

This process needs to be repeated on each enrollment server.

Universal Broker Configuration

The Horizon Universal Broker is a feature of Horizon Cloud Service – first-gen, that allows you to broker desktops and applications to end users across all cloud-connected Horizon pods. For more information, see the Horizon Universal Broker section of the Horizon 8 Architecture chapter, and the Horizon Universal Broker section of the First-Gen Horizon Control Plane Architecture chapter.

To connect a Horizon pod to use the Universal Broker – first-gen, you need to leverage the Horizon Cloud Connector and Horizon Subscription SaaS licensing. The Horizon Cloud Connector is a virtual machine that enables the Horizon Control Plane services to integrate with your Horizon pods.

For more information, see First-Gen Tenants - Onboarding a Horizon Pod to First-Gen Horizon Cloud Control Plane and First-Gen Horizon Cloud Universal Broker and Multi-Cloud Assignments.

Horizon Cloud Connector

For Horizon 8 (and Horizon 7), a Horizon Cloud Connector must be deployed for each Horizon pod that will use Horizon Control Plane Services such as the Universal Broker features. The Horizon Cloud Connector is also required when subscription licensing is used. See the Horizon Cloud Connector section of Horizon 8 Architecture and First-Gen Tenants - Download and Deploy the Horizon Cloud Connector into Your Pod’s Environment.

One active, or primary, Horizon Cloud Connector VM is supported per pod.

To support service-level fault tolerance you can create a two-node Horizon Cloud Connector cluster by adding a worker node to the cluster containing the primary node. The worker node contains a replica of the Horizon Cloud Connector application services. For more information on Horizon Cloud Connector Clusters and to understand which services can currently be protected, see Horizon Cloud Connector 2.0 and Later - Horizon Cloud Connector Clusters, Node-Level High Availability, and Service-Level Fault Tolerance.

For instruction on how to implement a second worker node, see Horizon Cloud Connector 2.0 and Later - Add a Worker Node to a Horizon Cloud Connector Cluster.

High availability of each Cloud Connector node is also provided by vSphere HA, which restarts the Cloud Connector VM in the case of a vSphere host outage.

For more information, see First-Gen Tenants - Onboarding a Horizon Pod to First-Gen Horizon Cloud Control Plane.

Universal Broker Plug-In

For Horizon 8 the Universal Broker plug-In must be installed on each Connection Server, as described in Horizon Pods - Install the Universal Broker Plugin on the Connection Server.

JWT Settings on Unified Access Gateways

Unified Access Gateway instances should have JWT settings configured on them, and the Horizon service configured to use those settings. See Horizon Pods - Configure Unified Access Gateway for Use with Universal Broker

Figure 1: JWT Settings in Unified Access Gateway

Desktop Pools

With Horizon 8 when creating a pool, the Desktop Pools Settings option of Cloud Managed must also be selected in order to use a pool with multi-cloud assignments.

• For new desktop pools, see Horizon Pods - Create a Desktop Pool Suitable for Multi-Cloud Assignments.
• For existing desktop pools, see Horizon Pods - Prepare an Existing Desktop Pool for Use in a Multi-Cloud Assignment.

Figure 2: Select Cloud-Managed in the Horizon Pool Wizard

Multi-cloud assignments should be configured to entitle users to resources. See Horizon Pods - Create a Multi-Cloud Assignment of VDI Desktops.

Horizon Group Policies

You can use standard Microsoft Group Policy Object (GPO) settings to configure Horizon virtual desktops and applications, and also use the provided GPO administrative templates for fine-grained control of access to features.

OU GPO Best Practices

Use the following guidelines when applying GPO settings to organizational units (OUs):

• Consider blocking inheritance on the OUs where Horizon desktops or RDSH servers will be provisioned.
• Re-use GPOs.
• Create separate OUs for users and computers.
• Ensure that each GPO is enabled or turned off for Computer Settings and User Settings.
• Group similar settings into one GPO.
• Understand the difference between monolithic and functional GPOs:
  
  • Monolithic GPOs contain settings for many different areas and are quite large. All settings are in one place. Use monolithic GPOs for generic settings that apply to all users or computers. Monolithic GPOs are typically applied at the domain level or relatively high in the Active Directory hierarchy.
  • Functional GPOs contain a limited number of settings for a specific area. Functional GPOs are smaller GPOs that facilitate settings being defined for particular users or VMs. Functional GPOs are typically applied lower in the Active Directory hierarchy.
• Link the GPOs to the OU structure (or site), and then use security groups to selectively apply these GPOs to particular users or computers.
• Use loopback replace to ensure that only settings for the VM’s OU are applied to the session.

This chapter contains a list of group policy settings that would typically be applied (this is not an exhaustive list). Most other settings can be applied through Dynamic Environment Manager policies. As part of the Horizon and Horizon Cloud Services downloads, there is a Horizon-Extras-Bundle ZIP file that contains a set of group policy templates to assist in defining additional GPO settings.

Common GPO Settings for Desktop and RDSH Server VMs

The settings in this section apply to both VDI desktops and RDSH servers.

Table 15: Settings for Computer Configuration > Policies > Administrative Templates > System > Group Policy

Table 16: Settings for Computer Configuration > Policies > Administrative Templates > System > Logon

RDSH Server OU-Level Settings

The following settings apply only to RDSH servers.

Table 18: Settings for Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing

User Configuration Settings

Various settings can be used to optimize the user experience while protecting the system. The following tables list a few basic, initial settings that would normally be applied. Because these are user settings, you must also use the loopback processing setting.

Table 20: Settings for User Configuration > Policies > Administrative Templates > Start Menu and Taskbar

Summary and Additional Resources

     Now that you have come to the end of this design chapter on Omnissa Horizon 8, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:

• Overview chapters provide understanding of business drivers, use cases, and service definitions.
• Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
• Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional Resources

For more information about Horizon 8, you can explore the following resources:

• Horizon 8 product page
• Horizon 8 documentation

• Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

 This chapter was written by:

• Graeme Gordon, Senior Staff Architect, Omnissa.

The following people contributed content to this guide:

• Leon Ngo, Senior Consultant, Professional Services, Omnissa.

Feedback

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