Horizon 8 on Oracle Cloud VMware Solution Architecture

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 architecting Omnissa Horizon 8 on Oracle Cloud VMware Solution (referred to as OCVS throughout this document)..

A companion chapter, Horizon 8 on Oracle Cloud VMware Solution Configuration, provides information about common configuration and deployment tasks for Horizon 8 on OCVS.

Introduction

Omnissa Horizon 8 on Oracle Cloud VMware Solution (OCVS) delivers a seamlessly integrated hybrid cloud for virtual desktops and applications.

OCVS is based on VMware Cloud Foundation and provides a fully supported, customizable cloud environment. The solution delivers a full-stack software-defined data center (SDDC), including vCenter, vSphere ESXi, NSX, and vSAN, delivered as a service on Oracle Cloud Infrastructure (OCI).

OCVS combines with the market-leading capabilities of Omnissa Horizon 8 gives a simple, secure, and scalable solution, that can easily address use cases such as on-demand capacity, disaster recovery, and cloud co-location without buying additional data center resources.

For customers who are already familiar with Horizon 8 or have Horizon 8 deployed on-premises, deploying Horizon 8 on OCVS lets you leverage a unified architecture and familiar tools. This means that you use the same expertise you know from Horizon 8 and vSphere for operational consistency and leverage the same rich feature set and flexibility you expect.

For more information about Horizon 8 on OCVS, see OCVS.

Figure 1: Omnissa Horizon 8 on OCVS

For details on feature parity between Horizon 8 on-premises and Horizon 8 on OCVS, see the Knowledge Base article Horizon on Oracle Cloud VMware Solution (OCVS) Support (88202).

The purpose of this design chapter is to provide a set of best practices on how to design and deploy Horizon 8 on OCVS. This content is designed to be used in conjunction with Horizon 8 documentation, and OCVS documentation.

Deployment Options

Horizon 8 on OCVS has one deployment option:

• All-in-SDDC - A consolidated design with all the Horizon components located inside the SDDC.

SDDC-based

Every component in the All-in-SDDC-based deployment model, including management, is located inside the OCVS Software-Defined Data Centers (SDDC).

The following figure shows the high-level logical architecture of this deployment model and all the management components inside the SDDC. There is a customer-provided load balancer that sits in the Oracle Cloud Infrastructure to forward protocol traffic into the SDDC.

Figure 2: All-in-SDDC Logical Architecture

Architectural Overview

The components and features that are specific to Horizon on GCVE are described in this section.

Components

The individual server components used for Horizon, whether deployed on OCVS or on-premises, are the same. See the Components section in the Horizon 8 Architecture for details on the common server components.

Check the Knowledge Base article 88202 for feature parity of Horizon 8 on OCVS.

The components and features that are specific to Horizon 8 on OCVS are described in this section.

Software-Defined Data Centers (SDDC)

OCVS allows you to create vSphere Software-Defined Data Centers (SDDCs) on Oracle Cloud Infrastructure (OCI). These SDDCs include vCenter Server for VM management, vSAN for storage, and NSX for networking.

You can connect an on-premises SDDC to a cloud SDDC and manage both from a single vSphere Web Client interface. Using a connected OCI account, you can access OCI services such as Oracle Cloud Infrastructure Compute and Oracle Cloud Infrastructure File Storage from virtual machines in your SDDC. For more information, see the Oracle Cloud Infrastructure documentation.

After you have deployed an SDDC on OCVS, you can deploy Horizon in that cloud environment just like you would in an on-premises vSphere environment. For pricing information, see Compute - Oracle Cloud VMware Solution.

Management Component

The management component for the network includes vCenter Server.

Compute Component

The compute component includes the following Omnissa Horizon 8 infrastructure components:

• Omnissa Horizon Connection Servers
• Omnissa Unified Access Gateway appliances
• Omnissa App Volume Managers
• Virtual machines

NSX Components

NSX is the network virtualization platform for the Software-Defined Data Center (SDDC), delivering networking and security entirely in software, abstracted from the underlying physical infrastructure.

The maximum number of ports per logical network is 1000. Pools can leverage the multi-VLAN option in Horizon to extend beyond this.

• Tier-0 router – Handles Internet, route- or policy-based IPsec VPN, Oracle Cloud Infrastructure FastConnect, and also serves as an edge firewall for the Tier-1.
• Tier-1 router – Serves as a distributed firewall for all customer internal networks.

Resource Pools

A resource pool is a logical abstraction for flexible management of resources. Resource pools can be grouped into hierarchies and used to hierarchically partition available CPU and memory resources.

Within a Horizon pod on OCVS, you can use vSphere resource pools to separate management components from virtual desktops or published applications workloads to make sure resources are allocated correctly. 

After an SDDC instance on OCVS is created, two resource pools exist: 

• A Management Resource Pool with reservations that contain vCenter Server plus NSX
• A Workload Resource Pool within which everything is managed by the customer 

When deploying both management components and user resources in the same SDDC, it is recommended to create two sub-resource pools within the Workload Resource Pool for your Horizon deployments:

• A Horizon Management Resource Pool for your Horizon management components, such as connection servers
• A Horizon User Resource Pool for your desktop pools and published apps

Figure 3: Resource Pools for SDDC-based Horizon 8 on OCVS

Scalability and Availability

In this section, we discuss the concepts and constructs that can be used to provide scalability of Horizon.

Block and Pod

A key concept of Horizon 8, whether deployed on OCVS or on-premises is the use of blocks and pods. See the Pod and Block section in Horizon 8 Architecture.

Table 1: Block and Pod Strategy

Horizon Universal Broker

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.

Note: At the time of writing, the brokering service from Horizon Cloud Service – next-gen is not supported with Horizon 8 pods and resources.

The Horizon Universal Broker is the cloud-based brokering technology used to manage and allocate Horizon resources from multi-cloud assignments to end users. It allows users to authenticate and access their assignments by connecting to a single fully qualified domain name (FQDN) and then get directed to the individual Horizon pods that will deliver their virtual desktop or published applications. To facilitate user connections to Horizon resources, each Horizon Pod has its own unique external FQDN.

Figure 4: Universal Broker Sample Architecture

Cloud Pod Architecture

Cloud Pod Architecture (CPA) is a standard Horizon feature that allows you to connect your Horizon deployment across multiple pods and sites for federated management. It can be used to scale up your deployment, build a hybrid cloud, and provide redundancy for business continuity and disaster recovery. CPA introduces the concept of a global entitlement (GE) that spans the federation of multiple Horizon pods and sites. Any users or user groups belonging to the global entitlement are entitled to access virtual desktops and RDS published apps on multiple Horizon pods that are part of the CPA.

Important: CPA is not a stretched deployment; each Horizon pod is distinct and all Connection Servers belonging to each of the individual pods are required to be in a single location and run on the same broadcast domain from a network perspective.

Here is a logical overview of a basic two-site/ two-pod CPA implementation. For OCVS, Site 1 and Site 2 might be different OCI availability domains, or Site 1 might be on-premises and Site 2 might be on OCVS.

Figure 5: Cloud Pod Architecture

For the full documentation on how to set up and configure CPA, refer to Cloud Pod Architecture in Horizon 8 and the Cloud Pod Architecture section in Horizon 8 Configuration.

     Linking Horizon Pods on OCVS

You can use the Cloud Pod Architecture feature to connect Horizon pods regardless of whether the pods are on-premises or on OCVS. When you deploy two or more Horizon pods on OCVS, you can manage entitlements independently or manage them together by linking them with CPA.

• On one Connection Server, initialize CPA and join the Connection Server to a pod federation.
• After CPA is initialized, you can create a global entitlement across your Horizon pods on-premises and on OCVS.
• Optionally, when you use CPA, you can deploy a global load balancer (such as F5, Oracle Cloud Infrastructure DNS, or others) between the pods. The global load balancer provides a single-namespace capability that allows the use of a common global namespace when referring to Horizon CPA. Using CPA with a global load balancer provides your end users with a single connection method and desktop icon in their Horizon Client or Workspace ONE console.  

Without the global load balancer and the ability to have a single namespace for multiple environments, end users will be presented with a possibly confusing array of desktop icons (corresponding to the number of pods on which desktops have been provisioned for them). For more information on how to set up Cloud Pod Architecture, see the Cloud Pod Architecture in Horizon 8.  

Use CPA to link any number of Horizon pods on OCVS. The maximum number of pods must conform to the limits set for pods in CPA. See, Omnissa Configuration Maximums.

When you connect multiple Horizon pods with CPA, the Horizon versions for each of the pods can be different from one another. Additional details can be found in the Horizon 8 documentation.

Using Cloud Pod Architecture to Build Hybrid Cloud and Scale for Horizon

You can deploy Horizon in a hybrid cloud environment when you use CPA to interconnect Horizon on-premises or vSphere-based clouds pods. You can easily entitle your users to virtual desktops and RDS-published apps on-premises and/or vSphere-based clouds. You can configure it to connect to whichever site is closest to them geographically as they roam.  

You can also stretch CPA across Horizon pods in two or more OCVS data centers with the same flexibility to entitle your users to one or multiple pods as desired.

 Using Cloud Pod Architecture to Provide Business Continuity and Disaster Recovery for Horizon

Unlike traditional BCDR (business continuity and disaster recovery) solutions for apps, where replication of all data from the primary site to the secondary site is needed, we recommend a different approach for Horizon, using CPA. Because the majority of VDI and RDS deployments use non-persistent and stateless virtual machines that can be created and recreated very quickly, it is senseless to replicate them across sites. CPA can be used across on-premises Horizon pods (primary site) and Horizon pods on OCVS (secondary site) for BCDR.

During normal operations, keep a small host footprint on OCVS where you will deploy your Horizon instance, store your updated golden images, and create a small pool of VMs. Note that there is a minimum number of hosts requirement per SDDC. When the primary site goes down, you can create new virtual desktops as well as new hosts on the secondary site from the very same golden image. Use Global Entitlements to ensure that your end users can access desktops on the secondary site.

You will need to keep persistent data such as user profiles, user data, and golden images synced between the two sites by using a storage replication mechanism, such as DFS-R in a hub-spoke topology or another third-party file share technology. If you also use App Volumes and Dynamic Environment Manager, AppStacks and file share data will also need to be replicated from the primary site to the secondary site.  

An important consideration in leveraging OCVS as a secondary site for BCDR involves host availability at the OCI data center when you need your BCDR capacity. Although there are usually spare hosts available that can be used to expand your secondary site, depending on your RPO (Recovery Point Objective) and growth requirement, you might not be able to reach your target number right away. The only way to guarantee the number of hosts you need right away is to reserve them ahead of time, but the tradeoff is the high cost. There are things you can do to optimize your availability and cost:

• Segment end-user populations into tiers in terms of RTO (recovery time objective). Some user segments may require a secondary desktop immediately. You should have desktops created and on standby for them. Other user segments might be able to tolerate longer RTO and may require a secondary desktop within hours rather than minutes. In this case, you can wait for new hosts and desktops to be created.

Work with your sales representative to ensure that you will have adequate BCDR capacity when you need it.

 Business Continuity and Disaster Recovery for Horizon Full-Clone Desktops

The BCDR (business continuity and disaster recovery) workflow recommended in the previous section works well for non-persistent instant clones. There are some additional considerations for protection of persistent full-clone desktops.

First, consider whether your users require the mirror image desktops after a primary site failure? If the answer is yes, you will need to replicate your primary full-clone desktops periodically to the secondary site. This is the most expensive type of protection for every primary full-clone desktop, you will need an equivalent secondary full-clone desktop on OCVS, running at all times. You will also need to script the import of secondary desktops into the Connection Servers on the secondary site as a manual full-clone pool.  

Most customers find that, given the cost of providing a fully mirrored desktop, it is acceptable to give their persistent full-clone desktop users a secondary desktop that is a pristine copy of the same golden image. Any user customization or data not saved in a file share and replicated to the secondary site will be lost, so you will need to ensure that all-important user data resides on a file share. You can then use the sample workflow in the previous section to provision either an instant-clone desktop or a full-clone desktop on the secondary site for BCDR purposes.

Workspace ONE Access

Workspace ONE® Access SaaS can be used to broker Horizon resources. In this case, the entitlements and resources are synced to Workspace ONE Access and Workspace ONE Access knows the FQDN of each pod to properly direct users to their desktop or application resources. 

For more design details, see Workspace ONE Access and Horizon Integration in the Platform Integration chapter.

Figure 6: Syncing Horizon Resources into Workspace ONE Access SaaS

Sizing Horizon 8 on OCVS

Similar to deploying Horizon 8 on-premises, you will need to size your requirements for deploying Horizon 8 on OCVS to determine the number of hosts you will need to deploy. Hosts are needed for the following purposes:

• Your virtual desktop or RDS workloads.
• Your Horizon infrastructure components, such as connection servers, Unified Access Gateways, App Volumes managers.
• SDDC infrastructure components on OCVS. These components are deployed automatically for you by Oracle, but you will need capacity in your SDDC to run them.

The methodology for sizing Horizon 8 on OCVS is the same as for on-premises deployments. What is different (and simpler) is the fixed hardware configurations on OCVS.

At the time of writing, the minimum number of hosts required per SDDC on OCVS for production use is 3 nodes (hosts).

Network Configuration

When SDDCs are deployed on OCVS, NSX is used for network configuration.

The recommended network architecture consists of a double DMZ and a separation between Horizon management components and the RDSH and VDI virtual machines.

Figure 7: Network Diagram (Subnets are for Illustrative Purposes Only)

Unified Access Gateway

The Unified Access Gateway appliances are located inside of the OCVS SDDC. There is no way to forward Horizon protocol traffic from the OCI load balancer into the Unified Access Gateway devices inside of the SDDC. As the connections in OCI VLANs are opaque to the underlying software-defined network (SDN), for devices outside the VLAN to connect to workloads inside it, the workloads must be tagged to help locate them within the VLAN.

Because the OCI Load Balancing service cannot maintain session persistence between the authentication (over TCP) and the protocol (over UDP) phases, we need to ensure each Unified Access Gateway is accessible directly from the Internet. We do this by assigning public IP addresses to the external access virtual IPs and pointing the VLAN’s Route Table default route to an Internet Gateway. See Load Balancing Unified Access Gateway in  Horizon 8 Architecture for details on load-balancing the UAG appliances.

Load Balancing

A load balancer must be deployed to allow multiple Unified Access Gateway appliances and Connection Servers to be implemented in a highly available configuration.

Network Configuration and Services for Deploying Horizon on OCVS

To set up a successful hybrid cloud deployment, ensure that you understand and configure the following network services.

OCVS Network Connectivity

If connecting an OCVS SDDC with on-premises datacenters or with another SDDC, the following connection options can be used:

• VPN (policy- or route-based) over public Internet
• VPN (policy- or route-based) over Oracle FastConnect
• Oracle FastConnect

Depending on the requirements one or another option might be the best fit for you. For a predictable networking experience, Oracle FastConnect is recommended. After the connection is established, ensure that routing configuration permits required traffic flow (e.g., all required subnets are correctly announced via BGP to OCVS and route-based VPNs). Additional network capabilities provided by HCX or L2VPN can be leveraged if needed. For more detail, see NSX Networking Concepts section of the OCVS Product Documentation.

DHCP service

It is critical to ensure that all VDI-enabled desktops have proper assigned IP address. In most cases, you opt for the automatic IP assignment.

OCVS supports the following ways to assign IP addresses to clients:

• NSX based local DHCP service
• DHCP Relay, customer managed

DNS Service

Reliable and correctly configured name resolution is key for a successful hybrid Horizon deployment. When designing your environment, make sure to understand DNS strategies for OCVS. Your design choice will directly influence the configuration details.

Data Egress Cost

Unlike on-premises deployments, deploying Horizon 8 on OCVS incurs data egress costs based on the amount of data egress traffic the environment will generate. It is important to understand and estimate the data egress traffic. Refer to the Oracle Pricing documentation for more information.

Understanding Different Types of Data Egress Traffic

Depending on the deployment use case, you may be incurring costs for some or all of the following types of data egress traffic:

• End-user traffic via the Internet – You have configured your environment where your end users will connect to their virtual desktops on OCVS remotely via the Internet. Any data leaving the OCVS data center will incur egress charges. Egress data consists of the following components: outbound data from Horizon protocols and outbound data from remote experience features (for example, remote printing). Although the former is typically predictable, the latter has more variance and depends on the exact activity of the user.
• End-user traffic via the on-premises data center – You have configured your environment where your end users will connect to their virtual desktops on OCVS via your on-premises data center. In this case, you will have to link your data center with the OCVS data center using VPN or Direct Connect. Any data traffic leaving the OCVS data center and traveling back to your data center will incur egress charges. And if you have Cloud Pod Architecture (CPA) configured between the on-premises environment and the OCVS environment, you will incur egress charges for any CPA traffic between the two pods (although CPA traffic is typically fairly light).
• External application traffic – You have configured your environment where your virtual desktops on OCVS must access applications hosted either in your on-premises environment or in another cloud. Any data traffic leaving the OCVS data center and traveling to these other data centers will incur egress charges.

Note: Data traffic within your OCVS organization or between the organization and OCI services in that same region is exempt from egress charges. However, any traffic from the organization to another OCI region (after the first 10 TB per month, which is free) will be subject to egress charges. Refer to the Oracle Pricing documentation for more information.

Data ingress (that is, data flowing into the OCVS data center) is free of charge.

Networking to On-Premises

Oracle FastConnect is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to Oracle Cloud Infrastructure. Using Oracle FastConnect, you can establish private connectivity between OCI and your data center, office, or co-location environment, which in many cases can reduce your network costs, increase bandwidth throughput, and provide a more consistent network experience than Internet-based connections.

Figure 8: OCVS Networking to On-Premises (SDDC-based Deployment shown)

Table 2: Virtual Private Network Strategy

Table 3: Domain Controller Strategy

Table 4: File Server Strategy

Licensing

Enabling Horizon to run on OCVS requires two separate licenses: a capacity license for OCVS and a Horizon subscription license. 

To enable the use of subscription licensing, each Horizon 8 pod must be connected to the Horizon Cloud Service. For more information on how to do this, see the Horizon Cloud Service section of the Horizon 8 Architecture chapter.

For a POC or pilot deployment of Horizon 8 on OCVS, you may use a temporary evaluation license or your existing perpetual license. However, to enable Horizon 8 for production deployment on OCVS, you must purchase an Horizon subscription license. For more information on the features and packaging of Horizon subscription licenses.

You can use different licenses (including perpetual licenses) on different Horizon pods, regardless of whether the pods are connected by CPA. You cannot mix different licenses within a pod because each pod only takes one type of license. For example, you cannot use both a perpetual license and a subscription license for a single pod. You also cannot use both the Horizon Apps Universal Subscription license and the Horizon Universal Subscription license in a single pod.

Preparing Active Directory

Horizon 8 requires Active Directory services. For supported Active Directory Domain Services (AD DS) domain functional levels, see the Knowledge Base (KB) article: Supported Operating Systems, Microsoft Active Directory Domain Functional Levels, and Events Databases for Omnissa Horizon 8 (78652).

If you are deploying Horizon in a hybrid cloud environment by linking an on-premises environment with an OCVS-based Horizon pod, you should extend the on-premises Microsoft Active Directory (AD) to OCVS.

Although you could access on-premises active directory services and not locate new domain controllers in OCVS, this could introduce undesirable latency.

A site should be created in Active Directory Sites and Services and defined to the subnets containing the Domain Controller(s) in OCVS. This will keep the active directory services traffic local.

Table 5: Active Directory Strategy

Shared Content Library

Content Libraries are container objects for VM, vApp, and OVF templates and other types of files, such as templates, ISO images, text files, and so on. vSphere administrators can use the templates in the library to deploy virtual machines and vApps in the vSphere inventory. Sharing golden images across multiple vCenter Server instances, between multiple OCVSs and/or on-premises SDDCs guarantees consistency, compliance, efficiency, and automation in deploying workloads at scale.

For more information, see Using Content Libraries in the vSphere Virtual Machine Administration guide in the vSphere documentation.

Resource Sizing

When resource sizing, make sure to take memory, CPU, and VM-level reservations into consideration, and use CPU shares for different workloads.

Memory Reservations

Because physical memory cannot be shared between virtual machines, and because swapping or ballooning should be avoided at all costs, make sure to reserve all memory for all Horizon virtual machines, including management components, virtual desktops, and RDS hosts.

CPU Reservations

CPU reservations are shared when not used, and a reservation specifies the guaranteed minimum allocation for a virtual machine. For the management components, the reservations should equal the number of vCPUs times the CPU frequency. Any amount of CPU reservations not actively used by the management components will still be available for virtual desktops and RDS hosts when they are deployed in same the SDDC.

Virtual Machine–Level Reservations

As well as setting a reservation on the resource pool, make sure to set a reservation at the virtual machine level. This ensures that any VMs that might later get added to the resource pool will not consume resources that are reserved and required for HA failover. These VM-level reservations do not remove the requirement for reservations on the resource pool. Because VM-level reservations are taken into account only when a VM is powered on, the reservation could be taken by other VMs when one VM is powered off temporarily.

Leveraging CPU Shares for Different Workloads

Because RDS hosts can facilitate more users per vCPU than virtual desktops can, a higher share should be given to them. When desktop VMs and RDS host VMs are run on the same cluster, the share allocation should be adjusted to ensure relative prioritization.

As an example, if an RDS host with 8 vCPUs facilitates 28 users and a virtual desktop with 2 vCPUs facilitates a single user, the RDS host is facilitating 7 times the number of users per vCPU. In that scenario, the desktop VMs should have a default share of 1000, and the RDS host VMs should have a vCPU share of 7000 when deployed on the same cluster. This number should also be adjusted to the required amount of resources, which could be different for a VDI virtual desktop session versus a shared RDSH-published desktop session.

Table 6: Reservations and Shares Overview

Deploying Desktops

With Horizon 8 on OCVS, both Instant Clones and full clones can be used. Instant Clones, coupled with App Volumes and Dynamic Environment Manager helps accelerate the delivery of user-customized and fully personalized desktops.

Instant Clone

Dramatically reduce infrastructure requirements while enhancing security by delivering a brand-new personalized desktop and application services to end users every time they log in:

• Reap the economic benefits of stateless, nonpersistent virtual desktops served up to date upon each login.
• Deliver a pristine, high-performance personalized desktop every time a user logs in.
• Improve security by destroying desktops every time a user logs out.

When you install and configure Horizon for instant clone for deployment on OCVS, do the following:

• When adding OCVS vCenter Server to the Horizon configuration, select the Oracle Cloud VMware Solution check box.

For more information, see Instant Clone Smart Provisioning.

App Volumes

Omnissa App Volumes provides real-time application delivery and management:

• Quickly provision applications at scale.
• Dynamically attach applications to users, groups, or devices, even when users are already logged in to their desktop.
• Provision, deliver, update, and retire applications in real time.
• Provide a user-writable volume, allowing users to install applications that follow them across desktops.
• Provide end users with quick access to a Windows workspace and applications, with a personalized and consistent experience across devices and locations.
• Simplify end-user profile management by providing organizations with a single and scalable solution that leverages the existing infrastructure.
• Speed up the login process by applying configuration and environment settings in an asynchronous process instead of all at login.
• Provide a dynamic environment configuration, such as drive or printer mappings, when a user launches an application.

For design guidance, see App Volumes Architecture.

Dynamic Environment Manager

Use Omnissa Dynamic Environment Manager for application personalization and dynamic policy configuration across any virtual, physical, and cloud-based environment. Install and configure Dynamic Environment Manager on OCVS just like you would install it on-premises.

   See Dynamic Environment Manager Architecture.

Summary and Additional Resources

Now that you have come to the end of this design chapter on Omnissa Horizon 8 on OCVS, 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 on OCVS, you can explore the following resources:

• OCVS product page
• Horizon 8 documentation

• Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Hilko Lantinga, Staff Engineer 2, Omnissa.

Contributors:

• Daniel Berkowitz, Senior Staff Architect, Omnissa.
• Graeme Gordon, Senior Staff Architect, 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.