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:
- 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.
- Set up the required administrator users and groups in Active Directory.
- Install and set up Connection Servers. Also install the event database.
- 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.
- Set up an RDSH server VM and install applications to be remoted to end users.
- Create desktop pools, application pools, or both.
- Entitle users to desktops and published applications.
- Install Horizon Client on end users’ machines and have end users access their remote desktops and applications.
- (Optional) Set up and configure enrollment servers to enable True SSO. See Setting Up True SSO.
- (Optional) Create and configure additional administrators to allow different levels of access to specific inventory objects and settings.
- (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.
- (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:
- Install the first standard Connection Server – See Install Horizon Connection Server with a New Configuration.
- Install a second Connection Servers into the pod – See Install a Replicated Instance of Horizon Connection Server.
- 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.
- To connect to Horizon Cloud Service – next-gen, deploy a Horizon Edge Gateway Appliance.
- To connect to Horizon Cloud Service – first-gen, deploy a Horizon Cloud Connector.
- 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:
- 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. - Add vCenter Server and configure the View Storage Accelerator – See Configuring Horizon for the First Time.
- Add instant clone domain administrators – See Add an Instant-Clone Domain Administrator.
- Configure event reporting – See Configuring Event Reporting in Horizon Console.
- Assign administrators and roles – See Configuring Role-Based Delegated Administration.
- Register Unified Access Gateways – See Monitoring Unified Access Gateway in Horizon Console.
- This provides visibility of the Unified Access Gateways on the dashboard.
- Register App Volumes Managers – See Add an App Volumes Manager.
- This is required when using Apps on Demand to allow the Connection Servers to communicate with the App Volumes Managers.
- 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.
- For each of the Connection Servers, configure the following.
Table 1: Connection Server Configuration Tasks
Task | Detail |
General settings | Because we are using Unified Access Gateway for external connectivity, ensure that the following fields are deselected:
If HTML Access is not being used, select the option for Do not use Blast Secure Gateway under Blast Secure Gateway. If HTML Access is to be used, we can tunnel through the Connection Server and have it provide the TLS certificate. This can remove the requirement for each virtual desktop to have a trusted TLS certificate. In the Blast Secure Gateway section, select the option Use Blast Secure Gateway for only HTML Access connections to machine. Set the Blast External URL to the Connection Server FQDN, with port 8443. For example, https://s1hcs1.domain.com:8443 |
Authentication | Follow the steps in Configure a SAML Authenticator in Horizon Console to set up the Workspace ONE Access as a SAML authenticator. |
Backup | Define a backup schedule and location for the Connection Server configuration according to Backing Up and Restoring Horizon Configuration Data. |
Origin checking | With multiple Connection Servers fronted by a load balancer, it is necessary to change origin checking on each server. If origin checking is left enabled, the load balanced name used to initiate a connection would not match the actual server name. This can cause the connection server to reject the request. One indication of this is when using HTML Access or the Horizon Administrator console from Google Chrome or Safari browsers. To turn off origin checking, create a locked.properties file in the C:\Program Files\Omnissa\Horizon\Server\sslgateway\conf directory. Enter the following entries as detailed in Cross-Origin Resource Sharing. Restart the Connection Server services. |
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:
- Create a certificate signing request (CSR) configuration file. This file is used to generate the CSR to request a certificate.
- Once you receive the signed certificate, import it.
- 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
Configuration Item | Settings for Instant-Clone Pools |
Desktop Pool Definition | Type: Automated User Assignment: Floating vCenter Server: Instant clones |
Desktop Pool Settings | Remote Machine Power Policy: N/A Delete or refresh machine on logout: N/A Default display protocol: Blast 3D renderer: N/A or NVIDIA GRID vGPU (depending on use case) HTML access: Enabled |
Provisioning Settings | Provision all machines up-front: Selected |
Guest Customization | AD container: Dedicated OU for this type of desktop |
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
Configuration Item | Settings for RDSH Server Farms |
Desktop Pool Definition | Type: Automated |
Identification and Settings | Default display protocol: Blast HTML access: Enabled Max sessions per RDS host: 30 or greater, depending on server hardware and VM specifications |
Guest Customization | AD container: Dedicated OU for this type of desktop Predefined specification |
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
- Connect to the Horizon Administrator console on one of the Connection Servers in the first pod (Site 1).
- Choose the task to initialize the Cloud Pod Architecture feature.
- Rename the pod federation if desired.
- Rename the site.
- Rename the pod if desired.
Join Another Pod to the Federation
- Connect to the Horizon Administrator console on one of the Connection Servers in the that pod (Site 2).
- Choose the option to join the pod federation.
- Enter the FQDN of a Connection Server from the first pod, along with credentials.
- If this pod is in another physical location, create a new site.
- Edit the newly added pod.
- Rename the pod if desired.
- 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
GE Setting | Value |
Name | Roaming |
Scope | All Sites (ANY) |
Entitlements | MYDOMAIN\All_Sales_People |
Use home site | Disabled |
This configuration allows anyone connecting to the federation through the global namespace, https://horizon.mydomain.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
Global Entitlement Setting | Value |
Name | PowerUser |
Scope | Within Site |
Entitlements | MYDOMAIN\Site1-PowerUsers MYDOMAIN\Site2-PowerUsers |
Use home site | Enabled |
Entitled user must have home site | Enabled |
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
Group | Domain | Site |
Site1-PowerUsers | MYDOMAIN | Site 1 |
Site2-PowerUsers | MYDOMAIN | Site 2 |
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
Group | Domain | Site |
Site1-PowerUsers | MYDOMAIN | Site 2 |
Site2-PowerUsers | MYDOMAIN | Site 1 |
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:
- Configure Horizon and Workspace ONE Access Integration.
- Install and configure Microsoft Certificate Authority service.
- Set up a certificate template for use with True SSO.
- Install and configure the enrollment servers.
- Add Workspace ONE Access as a SAML Authenticator to the Connection Servers.
- 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
- Add the Active Directory Certificate Services Server role using the Add Roles and Features Wizard. The only role service required is Certification Authority.
- Once installed, configure Active Directory Certificate Services using the following values.
Table 4: Settings for Active Directory Certificate Services
Configuration Item | Setting |
Role Services | Certification Authority |
Setup Type | Enterprise CA |
CA Type | Root CA or Subordinate CA, depending on your preference for PKI deployments. Choose Root CA if you are not integrating into an existing PKI. |
Private Key | Create a new private key |
Cryptology | Key length: 2048 (recommended) Hash algorithm: SHA256 (recommended) |
CA Name | Change if desired. |
Validity Period | Leave as default of 5 years. |
- The final configuration is done by opening a command prompt, as an Administrator, and running the following commands:
- Enable non-persistent certificate processing and help reduce the CA database growth rate:
certutil -setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS
- Ignore offline CRL (certificate revocation list) errors on the CA:
certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
- 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.
- Create a new certificate template by first opening the Certification Authority administrative tool.
- Expand the tree in the left pane, right-click Certificate Templates and select Manage. Right-click the Smartcard Logon template and select Duplicate Template.
- Do not click OK until you have completed all the configurations listed in the following table.
Table 5: Configuration Settings for the Certificate Template
Configuration Item | Setting |
Compatibility | Certification Authority: Windows Server 2008 R2 Certificate recipient: Windows 7 / Server 2008 R2 |
General | Template display name: True SSO Template name: TrueSSO Validity period: 1 hour Renewal period: 0 hours |
Request Handling | Purpose: Signature and smartcard logon Select Allow private key to be exported. Select For automatic renewal of smart card certificates. |
Cryptography | Provider category: Key Storage Provider Algorithm name: RSA Minimum key size: 2048 Request hash: SHA256 Can be different depending on the security standards. |
Server | Select Do not store certificates and requests in the CA database. De-select Do not include revocation information in issued certificates. |
Issuance Requirements | Select This number of authorized signatures. Value: 1 Policy type required in signature: Application Policy Application Policy: Certificate Request Agent Require the following for enrollment: Valid existing certificate |
Subject Name | Leave as is. |
Security | Add the group you created for the enrollment servers in preparation and give this read and enroll permissions. |
- 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. - Close the Certificate Template console.
- Issue the True SSO certificate template.
- Right-click Certificate Templates and select New > Certificate Template to Issue.
- 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.
- Issue the Enrollment Agent (Computer) certificate template.
- Right-click Certificate Templates and select New > Certificate Template to Issue.
- 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
- Run the Horizon Connection Server installer.
- 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.
- Open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
- Expand Certificates > Personal folder.
- Right-click All tasks > Request New Certificate.
- 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.
- Export certificate from Connection Server:
- On one of the Connection Servers, open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
- Expand Certificates > Omnissa Horizon Server Certificates > Certificates folder.
- Right-click the certificate file with the friendly name vdm.ec, and select All Tasks > Export.
- In the Certificate Export wizard, accept the defaults, including leaving the No, do not export the private key radio button selected.
- Save the file with a meaningful name such as s1-pod1-enrollclient.cer.
- This step only needs to be done from one of the Connection Servers in the pod.
- Import the certificate to the enrollment server:
- On the enrollment server, open the Microsoft Management Console (MMC) and select Add/Remove Snap-in > Certificates > Computer account > Local computer.
- Expand Certificates > Omnissa Horizon Server Enrollment Server Trusted Roots folder.
- Right-click All tasks > Import and browse to the file you saved from the Connection Server export.
- Ensure that the certificate will be placed in the Omnissa Horizon Server Enrollment Server Trusted Roots store.
- Configure the enrollment service to give preference to the local certificate authority when they are co-located:
- Edit the registry using regedit.exe as an administrator.
- Browse to the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Omnissa\Horizon\Enrollment Service. You must create the Enrollment Service key if it does not already exist.
- 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\ Omnissa\Horizon \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.
- Add the enrollment servers to environment.
- List enrollment servers to confirm their details.
- Create the connectors.
- List the SAML authenticator details.
- 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
Syntax
| |
Example 1: Add first enrollment server | |
Example 2: Add second enrollment server | |
Table 7: Step 2: List Enrollment Servers (ES)
Syntax
| |
Example 1: List enrollment servers | |
Example 2: List detail of first enrollment server | |
Example 3; List detail of second enrollment server | |
Table 8: Step 3: Create Connectors
Syntax
| |
Example: Create connector with primary and secondary servers and both certificate authorities | |
Table 9: Step 4: List SAML Authenticator
Syntax
| |
Example | |
Table 10: Step 5: Enable TrueSSO for the SAML Authenticator
Syntax
|
|
Example | |
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.
- On one of the Connection Servers, from Windows Administrative Tools, open ADSI Edit.
- Right-click Connect to and define the Connection Settings.
- For the Connection Point setting, choose the option for Select or type a Distinguished Name and type vdi
- For the Computer setting, type localhost:389
- Expand OU=Properties, select OU=Global, and double-click CN=Common in the right pane.
- Edit the pae-NameValuePair attribute.
- 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.
- 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.
- 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
- Verify that the two-way forest transitive trust exists between the resource forest and the user account forest.
- Confirm Domain or Enterprise Administrator permissions to access enterprise certificate authorities in the resource and user account forests.
PKI Objects
- If an enterprise certificate authority exists in the user account forest, verify that it is reachable from the resource domain.
- Enable LDAP referral on the enterprise certificate authority in the resource forest using the certutil command.
certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
- Verify the enterprise certificate authority computer accounts in the resource forest are members of the CA Publisher Group in the user account forest.
- Verify the domain controller security group has permission to enroll in the domain controller authentication template. See Knowledgebase article 59953.
- 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.
- 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
- 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
- True SSO certificate template.
- 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
- 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 mydomain-fqdn
- 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
- 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 mydomain-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
- 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.
- 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:
- Install and configure a Certificate Authority. See Set Up a Microsoft Enterprise Certificate Authority.
- Set up a certificate template on the Certificate Authority. See Create and Issue a Certificate Template.
- Download the Horizon Cloud pairing bundle from the Administration Console's Active Directory page.
- The pairing bundle is used when setting up the Enrollment Server.
- Set up the Enrollment Server.
- Configure the Enrollment Server to prefer to use the local Certificate Authority service. See Enrollment Server Configuration Settings.
- Edit the registry on the Enrollment servers using regedit.exe as an administrator.
- Browse to the following location: HKLM\SOFTWARE\ Omnissa\Horizon\Enrollment Service. You must create the Enrollment Service key if it does not already exist.
- 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
Setting | Value |
Configure user Group Policy loopback processing mode | Enabled |
Configure Logon Script Delay | Disabled |
Table 16: Settings for Computer Configuration > Policies > Administrative Templates > System > Logon
Setting | Value |
Show first sign-in animation | Disabled |
Always wait for the network at computer startup and logon | Enabled |
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
Setting | Value |
Use the specified Remote Desktop license servers | Enabled |
Hide notifications about RD Licensing problems that affect the RD Session Host server | Enabled |
Set the Remote Desktop licensing mode | Enabled |
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
Setting | Value |
Remove and prevent access to the Shut Down, Restart, Sleep and Hibernate commands | Enabled |
Add Logoff to the Start Menu | Enabled |
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:
Changelog
The following updates were made to this guide:
Date | Description of Changes |
2024-10-07 |
|
2024-05-16 |
|
2024-03-05 |
|
2023-07-24 |
|
2023-01-23 |
|
2021-04-02 |
|
Author and Contributors
- Graeme Gordon, Senior Staff Architect, Omnissa.
The following people contributed content to this guide:
- Leon Ngo, Senior Consultant, 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.