Horizon 8 on Alibaba Cloud VMware Service 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 when deployed on Alibaba Cloud VMware Service (referred to as ACVS throughout this document).

Introduction

Omnissa Horizon 8 on Alibaba Cloud VMware Service (AVCS) delivers a seamlessly integrated hybrid cloud for virtual desktops and applications.

ACVS 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 Alibaba Cloud Infrastructure (ACI).

ACVS combined 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 or have Horizon deployed on-premises, deploying Horizon 8 on ACVS lets you leverage a unified architecture and familiar tools. This means that you use the same expertise you know from vSphere and Horizon 8 for operational consistency and leverage the same rich feature set and flexibility you expect. By outsourcing the management of the hardware and vSphere platform, you can simplify management of Horizon 8 deployments.

For more information about Horizon 8 on ACVS, visit Alibaba Cloud VMware Service and the Alibaba Cloud documentation.

Figure 1: Omnissa Horizon 8 on ACVS

For details on feature parity between Horizon 8 on-premises and Horizon 8 on ACVS, see the Knowledge Base article Omnissa Horizon on Alibaba Cloud Omnissa Service (ACVS) Support (92140).

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

Deployment Options

Horizon 8 on ACVS has one deployment option, the All-in-SDDC, which is a consolidated design with all the Horizon 8 components located inside the SDDC.

All-in-SDDC

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

The following figure shows the high-level logical architecture of this deployment model and all the management components inside the SDDC.

Figure 2: All-in-SDDC Logical Architecture

Architectural Overview

In this section, we discuss the various components, including individual server components used for Omnissa Horizon 8, single or multiple VMware vSphere Software-Defined Data Centers (SDDC), management and compute components, VMware NSX components, and resource pools.

Components

The individual server components used for Horizon 8, whether deployed on ACVS 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 92140 for feature parity of Horizon 8 on ACVS.

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

Software-Defined Data Centers (SDDC)

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

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

After you have deployed an SDDC on ACVS, you can deploy Horizon in that cloud environment just like you would in an on-premises vSphere environment. For pricing information, see Pricing on ACVS.

Management Component

The management component for the network includes vCenter Server.

Compute Component

The compute component includes the following Horizon 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, Alibaba Express Connect, and also serves as an edge firewall for the Tier-1.
• Tier-1 router – Serves as a distributed firewall for all customer internal networks.

See Network Configuration for more information.

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 8 pod on ACVS 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 ACVS is created, two resource pools exist: 

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

When deploying both Horizon 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:

• Horizon Management Resource Pool - for the Horizon 8 management components, such as Connection Servers
• Horizon User Resource Pool - for the desktop pools and published apps

Figure 3: Resource Pools for All-in-SDDC Architecture of Horizon 8 on AVCS

Scalability and Availability

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

Block and Pod

A key concept of Horizon 8, whether deployed on AVCS 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

Cloud Pod Architecture

Cloud Pod Architecture (CPA) is a standard Horizon 8 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 AVCS, Site 1 and Site 2 might be different Alibaba Cloud availability zones, or Site 1 might be on-premises and Site 2 might be on AVCS.

Figure 4: Cloud Pod Architecture

   Optionally, when you use CPA, you can deploy a global load balancer 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.

One consideration to be aware of is potential hairpinning of the Horizon protocol traffic through another Horizon Pod or SDDC than the one where the users’ Horizon resource is located. See Protocol Traffic Hairpinning for more information.

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 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.

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 5: Syncing Horizon Resources into Workspace ONE Access SaaS

Sizing Horizon 8 on ACVS

The overall methodology for sizing AVCS is the same as for on-premises deployments. You must size your requirements for deploying Horizon 8 on AVCS to determine the number of hosts you must deploy for the following purposes:

• Your virtual desktop or RDS workloads.
• Your Horizon infrastructure components, such as Horizon Connection Servers, Unified Access Gateways, and App Volumes managers.
• SDDC infrastructure components on AVCS. These components are deployed and managed automatically for you by Alibaba but require capacity in your SDDC.

The minimum number of hosts required per SDDC on AVCS for production use is 3 nodes (hosts). See Host Specifications for the RAM, CPU, and disk capacities of the hardware in AVCS.

One design consideration in sizing an SDDC is the throughput capability of the SDDC networking and the NSX edge gateways. Each user session will generate a certain amount of traffic that needs to pass through the NSX edge gateways.

Each SDDC can handle up to 1,000 desktop or application sessions, assuming:

• The workload traffic aligns with the LoginVSI task worker profile.
• Only protocol traffic is considered, no user data.
• NSX Edge gateways are configured to be large.

Your workload profile and needs may be different, and therefore results may vary based on your use case. User data volumes may lower scale limits in the context of your workload. Size and plan your deployment accordingly.

Network Configuration

When SDDCs are deployed on AVCS, 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 6: Network Diagram (Subnets are for Illustrative Purposes Only)

Unified Access Gateway

The Unified Access Gateway appliances are located inside the AVCS SDDC. To ensure redundancy and scale, multiple Unified Access Gateways are deployed. To implement them in a highly available configuration and provide a single namespace, either the high availability (HA) feature built into Unified Access Gateway.

See the Load Balancing Unified Access Gateway section of the Horizon 8 Architecture chapter and the High Availability section of the Unified Access Gateway Architecture chapter.

Table 2: Load Balancing Unified Access Gateways Strategy

To provide direct external access, a public IP address would be configured with Network Address Translation (NAT) to forward traffic to either the Unified Access Gateway HA virtual IP address or to the load balancer virtual IP address.

When using Unified Access Gateway HA, the individual Unified Access Gateway appliances also each require a public IP address and NAT configured to route the Horizon protocol traffic to them.

Load Balancing Connection Servers

Multiple Connection Servers are deployed for scale and redundancy. Depending on the user connectivity, you may or may not need to deploy a third-party load balancer to provide a single namespace for the Connection Servers. When all user connections originate externally and come through a Unified Access Gateway, it is not necessary to have a load balancer between the Unified Access Gateways and the Connection Servers. Each Unified Access Gateway can be defined with a specific Connection server as its destination. While the diagram below shows a 1 to 1 mapping of Unified Access Gateway to Connection Server, it is also possible to have an N to 1 mapping, where more than one Unified Access Gateway maps to the same Connection Server.

Figure 7: Load Balancing when all Connections Originate Externally

Where users will be connecting from internally routed networks and their session will not go via a Unified Access Gateway, a load balancer should be used to present a single namespace for the Connection Servers. See the Load Balancing Connection Servers section of the Horizon 8 Architecture chapter.

When required for internally routed connections, a load balancer for the Connection Servers can be either:

• Placed in between the Unified Access Gateways and the Connection Server and used as an FQDN target for both internal users and the Unified Access Gateways.
• Located so that only the internal users use it as an FQDN.

Figure 8: Options for Load Balancing Connection Servers for Internal Connections

Table 3: Load Balancing Connection Servers Strategy

DHCP Service

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

AVCS 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. Your design choice will directly influence the configuration details.

Network Connectivity

If connecting an AVCS SDDC with on-premises data centers or with another SDDC, review the options available in the Alibaba documentation hybrid cloud network. 

Alibaba Express Connect is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to Alibaba Cloud Infrastructure. Using Alibaba Express Connect, you can establish private connectivity between Alibaba Cloud 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 9: AVCS Networking to On-Premises

Data Egress Cost

Unlike on-premises deployments, deploying Horizon 8 on AVCS 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 Alibaba 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 AVCS remotely via the Internet. Any data leaving the AVCS 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 AVCS via your on-premises data center. In this case, you will have to link your data center with the AVCS data center using VPN or Express Connect. Any data traffic leaving the AVCS data center and traveling back to your on-premises data center will incur egress charges. And if you have Cloud Pod Architecture (CPA) configured between the on-premises environment and the AVCS environment, you will incur egress charges for any CPA traffic between the two pods.
• External application traffic – You have configured your environment where your virtual desktops on AVCS must access applications hosted either in your on-premises environment or in another cloud. Any data traffic leaving the AVCS data center and traveling to these other data centers will incur egress charges.

Scaling Deployments

In this section, we will discuss options for scaling out Horizon on AVCS, using the All-in-SDDC architecture, with a single SDDC and with multiple SDCCs.

One of the main constraints to consider is the amount of network traffic throughput capability of the NSX edge gateway components inside the SDDCs. The network throughput into and out of an SDDC limits the number of Horizon sessions each SDDC is capable of hosting.

When assessing the amount of network traffic that the Horizon sessions will consume, a variety of factors should be considered, including:

• Protocol traffic – Can be affected by the display resolution, number of displays, content type, and usage.
• User data – Where the user data is outside the SDDC or is replicated into or out of the SDDC.
• Application data – When applications used in the Horizon desktops or published applications reside outside the SDDC.

The number of Horizon sessions that can be hosted within a single SDDC depends on how much network traffic the sessions generate that needs to enter or exit the SDDC and therefore traverse the NSX edge gateways.

Single SDDC

The simplest deployment comprises of a single SDDC. This will also form the building block for multiple SDDC deployments.

• Resource pools for Horizon Management and Horizon User are created within the default created Workload resource pool.
• Network segments are added for External-DMZ, Internal-DMZ, Horizon-Management, and VDI and RDSH as detailed in Network Configuration.

The Horizon management components, such as the Horizon Connection Servers and Unified Access Gateways are built out and attached to the relevant network segment, inside the SDDC.

Figure 10: Logical Architecture for a Single SDDC with Networking

An FQDN (for example, acvs1.company.com) is bound to an external public IP address which will then be NATed to the HA virtual IP address of the Unified Access Gateways. Each individual Unified Access Gateway will also need a public IP address and NAT rules to forward protocol traffic to them.

This FQDN will then be used to provide user access by either:

• Using the FQDN with the Horizon Client.
• Using Universal Broker and configuring the Pod External FQDN to use the pod FQDN.
• Integrating with Workspace ONE Access. See Workspace ONE Access and Integration in the Platform Integration chapter.

Figure 11: Horizon Connection Flow with Single SDDC

To build out a full Horizon 8 pod environment, the following components and servers were deployed.

Table 4: Connection Server Strategy

Table 5: Unified Access Gateway Strategy

Table 6: App Volumes Manager Strategy

Table 7: Dynamic Environment Manager Strategy

Table 8: SQL Server Strategy

Multiple SDDCs

To build environments capable of supporting larger numbers of users than a single SDDC can support, multiple SDDC environments can be deployed. As the All-in-SDDC architecture for Horizon on AVCS places all the management components inside the SDDC, there are some considerations when scaling above a single SDDC, related to the traffic throughput of the NSX edge gateways.

The current recommendation is that a Horizon pod, based in AVCS, should only contain a single SDDC. If multiple SDDCs were added to the same Horizon pod, user traffic might get routed through an initial SDDC to get to a destination SDDC, causing unnecessary protocol traffic through the NSX edge gateways in the initial SDDC. See Protocol Traffic Hairpinning to understand this consideration.

Figure 12: Logical Architecture for Multiple SDDC

Each SDDC is built out as a separate Horizon 8 pod following the same design outlined in the Single SDDC design. Each SDDC has its own distinct set of Horizon management components, including Connection Servers, Unified Access Gateways, and App Volumes Managers.

Figure 13: Multiple SDDC Deployment with Networking

When deploying environments with multiple Horizon Pods, there are different options available for administrating and entitling users to resources across the pods. This is applicable for Horizon environments on AVCS, on other cloud platforms, or on-premises.

• The Horizon pods can be managed separately, users entitled separately to each pod, and users directed to use the unique FQDN for the correct pod.
• Alternatively, you can manage and entitle the Horizon environments by linking them using Cloud Pod Architecture (CPA).

Each Horizon pod, and therefore the SDDC that contains it, will have a dedicated FQDN for user access. For example, acvs1.company.com and acvs2.company.com. Each SDDC would have a dedicated public IP address that would correlate to its FQDN.

This avoids potential protocol traffic hairpinning through the wrong SDDC.

Figure 14: Horizon Connection Flow for Two SDDCs

Protocol Traffic Hairpinning

One consideration to be aware of is potential hairpinning of the Horizon protocol traffic through another Horizon Pod or SDDC than the one where the users’ Horizon resource is located. This can occur if the users’ session is initially sent to the wrong SDDC for authentication.

With each SDDC, all traffic into and out of the SDDC goes via the NSX edge gateways and there is a limit to the traffic throughput. In the All-in-SDDC architecture, the management components, including the Unified Access Gateways, are located inside the SDDC, and authentication traffic has to enter an SDDC and pass through the NSX edge gateway.

If the authentication traffic is not precisely directed, such as using a unique namespace for each Horizon Pod, the user could be directed to any Horizon pod in its respective SDDC. If the users’ Horizon resource is not in that SDDC where they are initially directed for authentication, their Horizon protocol traffic would go into the initial SDDC to a Unified Access Gateway in that SDDC and then back out via the NSX edge gateways and then be directed to where their desktop or published application is being delivered from.

This causes a reduction in achievable scale due to this protocol hairpinning. For this reason, caution should be exercised if using Cloud Pod Architecture.

Figure 15: Potential Horizon Protocol Traffic Hairpinning with Multiple SDDC Deployments

Licensing

Enabling Horizon to run on AVCS requires two separate licenses: a capacity license for AVCS and an Omnissa Horizon license. For a POC or pilot deployment of Horizon on AVCS, you may use a temporary evaluation license. However, to enable Horizon for production deployment on AVCS, you should obtain Horizon licensing.

To license a Horizon pod, use one of the following licensing methods.

• Term – A license key is manually entered into a Connection Server to license the Horizon pod.
• Subscription – Licensing is obtained from the Horizon Cloud Service and synchronized by a Horizon Edge Gateway to license the Horizon pod.

With a Horizon subscription-based license, you do not need to retrieve or manually enter a license key for Horizon product activation. However, supporting component license keys, such as the license keys for App Volumes, and others, will be delivered separately, and the administrator must manually enter them to activate the product.

You can use different types of licensing (term and subscription) 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.

Horizon Edge Gateway

When using subscription licensing you need to connect to the Horizon Cloud Service. The Horizon Edge Gateway is a virtual appliance that connects a Horizon pod with Horizon Cloud Service -next-gen features, such as subscription licensing.

• A separate Horizon Edge Gateway is required for each Horizon pod that will be connected to Horizon Cloud Service -next-gen.
• The Horizon Cloud Service – next-gen is hosted in several locations outside of China.
• The Horizon Edge Gateway is an optional component and not required if you are using Term licensing.

For more information on the Horizon Edge Gateway appliance and connecting to Horizon Cloud Service – next-gen, see the Horizon Edge Gateway Appliance section of the Horizon 8 Architecture chapter.

Preparing Active Directory

Horizon 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 AVCS Horizon pod, you should extend the on-premises Microsoft Active Directory (AD) to AVCS.

Although you could access on-premises located active directory services and not locate new domain controllers in AVCS, this could introduce undesirable latency and a dependency on the WAN links to the on-premises locations.

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

Table 9: 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 AVCS 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.

Deploying Desktops

With Horizon 8 on AVCS, 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 AVCS, do the following:

• When installing a Horizon Connection Server, select AWS as the deployment type.
• When adding AVCS vCenter Server to the Horizon configuration, select VMware Cloud on AWS as the deployment type.

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 AVCS 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 AVCS, 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 AVCS, you can explore the following resources:

• ACVS 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.

Contributors:

• Daniel Berkowitz, 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.