VMware Workspace ONE and VMware Horizon 7 Enterprise Edition On-premises Reference Architecture

Executive Summary

This reference architecture describes how to address business requirements and use cases with services constructed by integrating the components of VMware Workspace ONE, including VMware Horizon® 7 Enterprise Edition, when deployed on-premises.

The example architecture and deployment described in this guide address key business requirements. The approach taken is, as with any technology solution, to start by defining those business requirements and drivers. The requirements can, in turn, be mapped to use cases that can be adapted to most scenarios.

To deliver a Workspace ONE solution, you build services efficiently from several reusable components. The resultant environment and services can be easily adapted to address changes in the business and use cases.

VMware Workspace ONE Logical Architecture Overview

Figure 1: VMware Workspace ONE Logical Architecture Overview

Mobile device and identity services are delivered through the VMware AirWatch® and VMware Identity Manager offerings. These services, in combination with the Workspace ONE app, extend the on-premises directory infrastructure and deliver unified and seamless single sign-on (SSO) access to software-as-a-service (SaaS) applications, public mobile applications, on-premises RDSH-published applications and virtual desktops, as well as legacy applications.

 User Workspace with VMware Workspace ONE

Figure 2User Workspace with VMware Workspace ONE

Additionally, Workspace ONE integrates with VMware Horizon®, either to cloud-hosted virtual desktops and applications with VMware Horizon Cloud Service, or to VMware Horizon 7 on-premises virtual desktops and published applications. This integration provides fast SSO access to a Windows desktop or set of Windows applications for those users that require it.

One key step in addressing the use cases is defining blueprints for the services to be delivered. This step allows us to understand the components and parts that need to be designed, built, and integrated.

Sample Horizon 7 Service Blueprint

Figure 3: Sample Horizon 7 Service Blueprint

Our modular, repeatable design approach combines components and services to customize the end-user experience without requiring specific configurations for individual users. The Horizon 7 Enterprise architecture content in this guide uses key features, such as Just-in-Time Delivery, which combines Instant Clone Technology, VMware App Volumes, and VMware User Environment Manager to deliver a persistent end-user experience in nonpersistent environments while accelerating the delivery of OS, applications, and user configuration.

The solution integrates tightly with infrastructure services such as Microsoft Active Directory, DNS, certificate services, and edge services, such as load balancing and firewalls, to provide a highly available, secure, and federated solution.

After deployment, users can access applications at the touch of an icon, regardless of where those applications or services are deployed. Users can also use the self-service feature of the Workspace ONE mobile app or secure browser to add applications as needed from a single catalog.

 

Workspace ONE App on an iOS Device

Figure 4: Workspace ONE App on an iOS Device

Workspace ONE includes many security features:

  • Email security – Workspace ONE integrates with corporate email solutions, whether on-premises or cloud-based, to provide secure access through operating-system native, third-party, or managed mobile email clients, such as VMware Boxer.
  • Sensitive content protection – Similarly, access to corporate and user content is provided through a flexible approach of integrating with on-premises file servers, Microsoft Office 365–based content, third-party cloud storage providers, and VMware AirWatch® Content Locker.
  • Easy but secure access – Making end-user access to applications seamless is a sure way to encourage adoption of those apps, so Workspace ONE introduces one-touch mobile SSO. This feature allows use of capabilities such as Apple Touch ID on an iPhone, fingerprint readers on Android devices, and Microsoft Windows Hello on a Surface Pro, to provide password-free, secure access.
    The conditional access and adaptive management features in Workspace ONE address the significant concerns of providing easy and trusted end-user access to business applications while ensuring an enterprise level of security.
  • Extra security for mobile platforms – Workspace ONE provides options for data loss prevention (DLP) and multifactor authentication (MFA) technology to ensure that enterprise information is protected on mobile platforms. When additional means of authentication are required, you can also easily implement a secure and easy-to-use solution.

VMware vSphere® is the foundation platform for running any on-premises resources, including VMware AirWatch, VMware Identity Manager, and Horizon 7 management components and end-user consumable resources. For the storage platform, we used VMware vSAN™ and followed best practices to design and build out a reference architecture that met our requirements. vSAN comes with Workspace ONE Enterprise Edition and Horizon 7 Enterprise Edition and provides an excellent scalable storage layer. However, you can use other storage types instead.

For Horizon 7, we also used VMware NSX® for vSphere®, the network virtualization platform from VMware. NSX enables the creation of entire networks in software and embeds them in the hypervisor layer, abstracted from the underlying physical hardware. NSX also makes network micro-segmentation feasible for the first time. It enables granular firewalling and security policy enforcement for every workload, including virtual desktops, in the data center, independent of the network topology and complexity.

This reference architecture underwent validation of design, environment adaptation, component and service build, integration, user workflow, and testing to ensure that all the objectives were met, the use cases were delivered properly, and that real-world application is achievable.

This VMware Workspace ONE and VMware Horizon 7 Enterprise Edition On-premises Reference Architecture illustrates how Workspace ONE can deliver a modern digital workspace that meets key business requirements and common use cases for the increasingly mobile workforce.

 

Workspace ONE Solution Overview

Workspace ONE is a simple and secure enterprise platform that delivers and manages any app on any device by integrating identity, application, and enterprise mobility management. It is available either as a cloud service or for on-premises deployment. The platform is composed of several components—VMware AirWatch, VMware Identity Manager, VMware Horizon 7, and the Workspace ONE mobile apps supporting the most common mobile platforms.

VMware Reference Architectures

VMware reference architectures are designed and validated by VMware and supporting partners to address common use cases, such as enterprise desktop replacement, remote access, and disaster recovery.

This reference architecture is intended to provide detailed configuration information and an example architecture for deploying all products in an integrated manner.

This Workspace ONE on-premises reference architecture presents high-level design and low-level configuration for the key features and integration points of Workspace ONE Enterprise Edition to form cohesive services to address typical business use cases.

VMware reference architectures offer customers:

  • Standardized, validated, repeatable components
  • Scalable designs that allow room for future growth
  • Validated and tested designs that reduce implementation and operational risks
  • Quick implementation, reduced costs, and minimized risk

This reference architecture provides detailed configuration information and example architecture. The result is a description of cohesive services that address typical business use cases.

This reference architecture does not provide performance data or stress testing metrics. However, it does provide a structure and guidance on architecting in repeatable blocks for scale. The principles followed include the use of high availability, load balancing, and ensuring that there are no single points of failure to provide a production-ready design.

Note: Links within this document refer to content on VMware Documentation and MyAirWatch. The content on the VMware Documentation site is openly accessible, but the content on the MyAirWatch site requires logging in to an account. You can create a free account to access that material.

Audience

This reference architecture guide helps IT architects, consultants, and administrators involved in the early phases of planning, designing, and deploying Workspace ONE, mobile, and Horizon 7 solutions.

You should have:

  • A solid understanding of the mobile device landscape
  • Deep experience regarding the capabilities and configuration of mobile operating systems
  • Familiarity with device management concepts
  • Knowledge of identity solutions and standards, such as SAML authentication
  • Understanding of enterprise communication and collaboration solutions, including Microsoft Office 365, Exchange, and SharePoint
  • A solid understanding of desktop and application virtualization
  • Familiarity with virtual desktops in VMware Horizon 7
  • A solid understanding of firewall policy and load-balancing configurations

Workspace ONE Platform

With this latest release, you can enjoy key features such as:

  • Self-service access to cloud, mobile, and Windows apps
    • After end users are authenticated through the Workspace ONE app, they can instantly access mobile, cloud, and Windows applications with one-touch mobile SSO.
  • Choice of any device, employee or corporate owned
    • Facilitate adoption of bring-your-own-device (BYOD) programs by putting choice in the hands of end users. Give the level of convenience, access, security, and management that makes sense for their work style.
    • Enable flexible application access policies, allowing some applications to be used prior to enrollment into device management, while requiring full enrollment for apps that need higher levels of security.
    • Provision, deliver, update, and retire applications in real time.
  • Secure productivity apps: mail, calendar, docs, and social
    • End users can use the included mail, calendar, contacts, documents, chat, and enterprise social capabilities, while policy-based security measures protect the organization from data leakage by restricting how attachments and files are edited and shared.
  • Data security and endpoint compliance with conditional access
    • By combining identity and device management, Workspace ONE can enforce access decisions based on a range of conditions, including strength of authentication, network, location, and device compliance.
    • Policy controls ensure that IT can protect against compromised devices.
  • Real-time app delivery and automation
    • Taking advantage of new capabilities in Windows, Workspace ONE allows desktop administrators to automate application distribution and updates. This automation, combined with virtualization technology, helps ensure application access as well as improve security and compliance.

Workspace ONE Platform Integration

VMware Identity Manager provides the solution’s identity-related components. These components include authentication using username password, two-factor authentication, certificate, Kerberos, mobile SSO, and inbound SAML from third-party VMware Identity Manager systems. VMware Identity Manager also provides SSO to entitled web apps and Windows apps and desktops delivered through either VMware Horizon or Citrix.

VMware Workspace ONE Logical Architecture Overview

Figure 5: VMware Workspace ONE Logical Architecture Overview

VMware AirWatch delivers the enterprise mobility management portion of the solution. VMware AirWatch allows device enrollment and uses profiles to enforce configuration settings and control of users’ devices. It also enables a mobile application catalog to publish public and internally developed applications to end users. You can also develop compliance policies to alert administrators to compromised devices or wipe a device that is running unapproved applications. You can integrate VMware AirWatch with enterprise directories, such as Active Directory, for authentication and user management. To facilitate mobile productivity, VMware AirWatch can integrate with email systems and content repositories.

The Workspace ONE native app is available for iOS, Android, and Windows 10. The app consolidates the VMware AirWatch and VMware Identity Manager catalogs into a single catalog to bring native mobile, SaaS-based and on-premises web applications, and virtual apps and desktops to users in a simple manner. Through SSO technology, Workspace ONE makes it easy for users to access the applications they need.

Workspace ONE supports adaptive management that allows users to download and use less sensitive or secure apps from the Workspace ONE catalog. When the user downloads a sensitive or secure app, the user is asked to go through the device enrollment process directly from within Workspace ONE. With the device enrolled, the higher degree of control and security makes it possible for the user to access a greater range of apps and data.

Horizon 7 Platform

With the introduction of Horizon 7 Enterprise Edition, VMware is drawing on the best of mobile and the cloud, offering greater simplicity, security, speed, and scale in delivering on-premises virtual desktops and applications with cloud-like economics and elasticity of scale.

Horizon 7 Logical Architecture Overview

Figure 6: Horizon 7 Logical Architecture Overview

With this latest release, customers can now enjoy key features such as:

  • JMP (Next-Generation Desktop and Application Delivery Platform) JMP (pronounced jump), which stands for Just-in-Time Management Platform, represents capabilities in VMware Horizon 7 Enterprise Edition that deliver Just-in-Time Desktops and Apps in a flexible, fast, and personalized manner. JMP is composed of the following VMware technologies:
    • VMware Instant Clone Technology for fast desktop and RDSH provisioning
    • VMware App Volumes for real-time application delivery
    • VMware User Environment Manager for contextual policy management

JMP allows components of a desktop or RDSH server to be decoupled and managed independently in a centralized manner, yet reconstituted on demand to deliver a personalized user workspace when needed. JMP is supported with both on-premises and cloud-based Horizon 7 deployments, providing a unified and consistent management platform regardless of your deployment topology. The JMP approach provides several key benefits, including simplified desktop and RDSH image management, faster delivery and maintenance of applications, and elimination of the need to manage “full persistent” desktops.

  • Just-in-Time Desktops Leverages Instant Clone Technology coupled with App Volumes to accelerate the delivery of user-customized and fully personalized desktops. 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.
  • VMware 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.
  • VMware User Environment Manager – Offers personalization and dynamic policy configuration across any virtual, physical, and cloud-based environment.
    • 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.
  • Horizon Smart Policies – Deliver a real-time, policy-based system that provides contextual, fine-grained control. IT can intelligently enable or disable client features based on user device, location, and more.
    • Conditions can be reevaluated when specific events occur, such as user reconnect, allowing the policies to be contextually applied and reassessed.
    • With True SSO, users benefit from single-click, password-free login to their Windows desktops and apps through a single digital workspace.
  • Blast Extreme ­– Provides a high-performance graphics experience accessible on billions of devices, including ultra-low-cost PCs. Purpose-built and optimized for the mobile cloud, this display technology is built on industry-standard H.264.
    • Multi-codec – Blast Extreme supports the JPG/PNG and H.264 codecs.
    • Multi-protocol – Supports both TCP and UDP transport protocols.
    • Adaptation – Automatically selects the appropriate codec based on endpoint and policy, and selects the appropriate transport protocol based on network conditions and policy.

Horizon 7 Platform Integration

VMware Horizon 7 Enterprise Edition extends the power of virtualization with virtual compute, virtual storage, and virtual networking and security to drive down costs, enhance the user experience, and deliver greater business agility.

Horizon 7 Enterprise Edition can leverage native storage optimizations from vSphere, including SE Sparse, VAAI, and storage acceleration, to lower storage costs while delivering a superior user experience.

Horizon 7 Enterprise Edition with vSAN Advanced for Desktop automates storage provisioning and leverages direct-attached storage resources to reduce storage costs for desktop workloads. Horizon 7 supports all-flash capabilities to better support more end users at lower costs across distributed locations.

Reference Architecture Design Methodology

To ensure a successful Workspace ONE deployment, it is important to follow proper design methodology. To start, you need to understand the business requirements, reasons, and objectives for undertaking the project. From there, you can identify the needs of the users and organize these needs into use cases with understood requirements. You can then align and map those uses cases against a set of integrated services provided by Workspace ONE.

Reference Architecture Design Methodology

Figure 7: Reference Architecture Design Methodology

A Workspace ONE design uses a number of components to provide the services that address the identified use cases. Before you can assemble and integrate these components to form a service, you must first design and build the components in a modular and scalable manner to allow for change and growth. We also must consider integration into the existing environment.

Then you can bring the parts together to deliver the integrated services to satisfy the use cases, business requirements, and the user experience.

As with any design process, the steps are cyclical, and any previous decision should be revisited to make sure a subsequent one has not impacted it.

Business Drivers and Use Cases

An end-user-computing (EUC) solution based on VMware Workspace ONE and VMware Horizon 7 can address a wide-ranging set of business requirements and use cases. In this reference architecture, the solution targets the most common requirements and use cases seen in customer deployments to date.

Addressing Business Requirements

A technology solution should directly address the critical business requirements that justify the time and expense of putting a new set of capabilities in place. Each and every design choice should center on a specific business requirement. Business requirements could be driven by the end user or by the team deploying EUC services.

The sections that follow describe the top common key business drivers addressed by the Workspace ONE solution.

Mobile Access

Requirement definition: Provide greater business mobility by providing mobile access to modern and legacy applications on laptops, tablets, and smartphones.

Workspace ONE solution: Workspace ONE provides a straightforward, enterprise-secure method of accessing all types of applications that end users need from a wide variety of platforms.

  • It is the first solution that brings together identity, device management, application catalogs, and mobile productivity.
  • Horizon 7 client technology supports all mobile and laptop devices as well as common operating systems.
  • Unified Access Gateway virtual appliances provide secure external access without the need for a VPN.
  • VMware NSX provides network least-privilege trust and VM isolation using micro-segmentation and identity-based firewalling for the Horizon 7 management, RDSH, and desktop environments.

Fast Provisioning and Access

Requirement definition: Allow fast provisioning of and secure access to line-of-business applications for internal users and third-party suppliers, while reducing physical device management overhead.

Workspace ONE solution: Workspace ONE can support a wide range of device access scenarios, simplifying the onboarding of end-user devices.

  • Adaptive management allows a user to download an app from a public app store and access some published applications. If users need to access more privileged apps, they are prompted to enroll their device from within the app itself rather than through an agent.
  • Horizon 7 Enterprise Edition can provision hundreds of desktops in minutes using Instant Clone Technology. Horizon 7 provides the ability to entitle groups or users to pools of desktops quickly and efficiently. Applications are delivered on a per-user basis using App Volumes.
  • Unified Access Gateway appliances provide a secure and simple mechanism for external users to access desktops customized using User Environment Manager.

Reduced Application Management

Requirement definition: Reduce application management overhead and reduce application provisioning time.

Workspace ONE solution: Workspace ONE provides end users with a single application catalog for native mobile, SaaS, and virtualized applications improves application management.

  • Workspace ONE provides a consolidated view of all applications hosted across different services with a consistent user experience across all platforms.
  • App Volumes provides a simple solution to managing and deploying applications. Applications can be deployed “once” to a single central file and accessed by thousands of desktops. This simplifies application maintenance, deployment, and upgrades.
  • VMware ThinApp® provides additional features to isolate or make applications portable across platforms.

Centralized and Secure Data and Devices

Requirement definition: Centralize management and security of corporate data and devices to meet compliance standards.

Workspace ONE solution: All components are designed with security as a top priority.

  • VMware AirWatch provides aggregation of content repositories, including SharePoint, network file shares, and cloud services. Files from these repositories can then be synced to AirWatch Content Locker for viewing and secure editing.
  • VMware AirWatch policies can also be established to prevent distribution of corporate files, control where files can be opened and by which apps, and prevent such functions as copying and pasting into other apps or printing.
  • Horizon 7 is an on-premises virtual desktop solution where user data, applications, and desktop activity do not leave the data center. Additional Horizon 7 and User Environment Manager policies restrict and control user access to data.
  • VMware vSphere is a market-leading trusted virtualization platform to run desktop or application workloads.
  • VMware NSX provides network-based services such as security, virtualization networking, routing, and switching in a single platform within a data center, regardless of the underlying physical network.

Comprehensive and Flexible Platform for Corporate-Owned or BYOD Strategies

Requirement definition: Allow users to access applications, especially the Microsoft Office 365 suite, and corporate data from their own devices.

Workspace ONE solution: The flexibility of BYOD can introduce challenges for enterprise IT related to device management. Workspace ONE and features like adaptive management simplify end-user enrollment and empower application access in a secure fashion to drive user adoption.

With Horizon 7, you move to a virtual desktop and published application solution, removing need to manage client devices, applications, or images. A thin client, zero client, or employee-owned device can be used in conjunction with VMware Horizon® Client™. IT now has the luxury of managing single images of virtual desktops in the data center.

Reduced Support Calls and Improved Time to Resolution

Requirement definition: Simplify and secure access to applications to speed up root-cause analysis and resolution of user issues.

Workspace ONE solution: Workspace ONE provides SSO capabilities to a wide range of platforms and applications. By leveraging SSO technology, password resets are unnecessary.

  • VMware Identity Manager provides a self-service single point of access to all applications and, in conjunction with True SSO, provides a platform for single sign-on. Users no longer need to remember passwords or request applications through support calls.
  • Both VMware AirWatch and VMware Identity Manager include dashboards and analytics to help administrators understand what a profile of application access and device deployment looks like in the enterprise. With greater knowledge of which applications users are accessing, you can more quickly identify issues with licensing or potential attempted malicious activities against enterprise applications.
  • Reacting to user issues is critical to any enterprise EUC solution. VMware vRealize® Operations Manager™ for Horizon provides a single pane of glass for monitoring and predicting the health of any entire Horizon 7 infrastructure. From user protocol performance to storage and compute utilization, vRealize Operations Manager for Horizon provides an extremely fast way to determine the root cause of issues that arise.

Multi-Site Deployment Business Drivers

There are many ways and reasons to implement a multi-site solution. The most typical setup and requirement is for a two-data-center strategy. The aim is to provide disaster recovery, with the lowest possible recovery time objective (RTO) and recovery point objective (RPO); that is, to keep the business running with the shortest possible time to recovery and with the minimum amount of disruption.

The overall business driver for disaster recovery is straightforward:

  • Keep the business operating during an extended or catastrophic technology outage.
  • Provide continuity of service.
  • Allow staff to carry out their day-to-day responsibilities.

With services, applications, and data delivered by Workspace ONE, that means providing continuity of service and mitigating against component failure, all the way up to a complete data center outage.

With respect to business continuity and disaster recovery, this reference architecture addresses the following common key business drivers: 

  • Cope with differing levels and types of outages and failures.
  • Develop predictable steps to recover functionality in the event of failures.
  • Provide essential services and access to applications and data delivered by Workspace One and Horizon 7 during outages.
  • Minimize interruptions during outages.
  • Provide the same or similar user experience during outages.
  • Provide mobile secure access.

The following table describes the strategy used for responding to each of these business drivers. In this table, the terms active/active and active/passive are used.

  • Active/active recovery mode means that the service is available from multiple data centers without manual intervention.
  • Active/passive recovery mode requires that the passive instance of the service be promoted to active status in the event of a service outage.

Business Driver 

Comments 

Provide essential services and access to applications and data delivered by Workspace ONE and Horizon 7 during outages.

 

Minimize interruptions during outages.

By designing an architecture where all intra-site components are deployed in pairs and all services are made highly available—with services able to be delivered from multiple sites, either in an active/active or active/passive manner—the highest service level possible is delivered, minimizing downtime in case of an outage.

Provide a familiar user experience during outages.

Replicating the parts that a user considers persistent (profile, user configuration, applications, and more) and reconstructing a desktop in the second data center using those parts, makes it possible to give users personalized environments.

VMware Identity Manager provides a common entry point to all types of applications, regardless of which data center is actively being used.

Cope with differing levels and types of outages and failures.

This reference architecture details a design for multi-site deployments to cope with catastrophic failures all the way up to a site outage. The design ensures that there is no single point of failure within a site.

Develop predictable steps to recover functionality in the event of failures.

The services are constructed from several components and designed in a modular fashion. A proper design methodology, as followed in this reference architecture, allows each component to be designed for availability, redundancy, and predictability. Any recoverability steps or processes for each component and the whole end-user service can then be planned and documented.

Provide mobile secure access.

 

Desktop mobility is a core capability in the Horizon 7 platform. As end users move from device to device and across locations, the solution reconnects end users to the virtual desktop instances that they are already logged in to, even when they access the enterprise from a remote location through the firewall. VMware Unified Access Gateway™ virtual appliances provide secure external access without the need for a VPN.

 

Table 1: Meeting Business Requirements with Multi-site Deployments

Use Cases

Use cases drive the design for any EUC solution and dictate which technologies are deployed to meet user requirements. Use cases can be thought of as common user scenarios. For example, a finance or marketing user might be considered a “normal office worker” use case.

Designing an environment includes building out the functional definitions for the use cases and their requirements. We define typical use cases that are also adaptable to cover most scenarios. We also define services to deliver the requirements of those use cases.

Workspace ONE Use Cases

This reference architecture includes the following common Workspace ONE use cases.

Use Case

Description

Mobile Task-Based Worker

Users who typically use a mobile device for a single task through a single application.

  • Mobile device is highly managed and used for only a small number of tasks, such as inventory control, product delivery, or retail applications.
  • Communications tools, such as email, might be restricted to only sending and receiving email with internal parties.
  • Device is typically locked down from accessing unnecessary applications. Access to public app stores is restricted or removed entirely.
  • Device location, full device wipe, and other features are typically used.

Mobile Knowledge Worker

Many roles fit this profile, such as a hospital clinician or an employee in finance, marketing, HR, health benefits, approvals, and travel.

  • These workers use their own personal device (BYOD), a corporate device they personally manage, or a managed corporate device with low restrictions.
  • Users are typically allowed to access email, including personal email, along with public app stores for personal apps.
  • Device is likely subject to information controls over corporate data, such as data loss prevention (DLP) controls, managed email, managed content, and secure browsing.
  • Users need access to SaaS-based applications for HR, finance, health benefits, approvals, and travel, as well as native applications where those applications are available.
  • Device is a great candidate for SSO because the need to access many diverse applications and passwords becomes an issue for users and the helpdesk.
  • Privacy is typically a concern that might prevent device enrollment, so adaptive management and clear communication regarding the data gathered and reported to VMware AirWatch is important to encourage adoption.

Contractor

Contractors might require access to specific line-of-business applications, typically from a remote or mobile location.

  • Users likely need access to an organization’s systems for performing specific functions and applications, but access might be for a finite time period or to a subset of resources and applications.
  • When the contractor is no longer affiliated with the organization, all access to systems must be terminated immediately and completely, and all corporate information must be removed from device.
  • Users typically need access to published applications or VDI-based desktops, and might use multiple devices not under company control to do so. Devices include mobile devices as well as browser-based devices.

Table 2: Workspace ONE Common Use Cases

Horizon 7 Use Cases

This reference architecture includes the following Horizon 7 use cases.

Use Case

Description

Static Task Worker

These workers are typically fixed to a specific location with no remote access requirement. Some examples include call center worker, administration worker, retail user, and so on. A static task worker:

  • Uses a small number of Microsoft Windows applications. They do not install their own applications and do not require SaaS application access.
  • Requires location-aware printing.

Mobile Knowledge Worker

This worker could be a hospital clinician, a company employee, or a finance or marketing role. This is a catch-all use case for many corporate use cases. A mobile knowledge worker:

  • Mainly uses applications from a corporate location but might access applications from mobile locations.
  • Uses a large number of core and departmental applications but does not install their own applications. Requires SaaS application access.
  • Requires the ability to view video and Flash content. Their GPU requirement is minimal, but GPU would improve user experience.
  • Requires access to USB devices.
  • Requires location-aware printing.
  • Requires two-factor authentication when accessing applications remotely.

Software Developer / IT (Power User)

Power users require administrator privileges to install applications. The operating system could be either Windows or a Linux OS, with many applications, some of which could require extensive CPU and memory resources. A power user:

  • Mainly uses applications from a corporate location but might access applications from mobile locations.
  • Uses a large number of core and departmental applications and installs their own applications. Requires SaaS application access.
  • Requires the ability to view video and Flash content.
  • Requires two-factor authentication when accessing applications remotely.

Multimedia Designer / Engineer

These users might require GPU-accelerated applications, have intensive CPU and memory workloads, or both. Examples are CAD/CAM designers, architects, video editors and reviewers, graphics artists, and game designers. A multimedia designer:

  • Mainly uses applications from a corporate location but might access applications from mobile locations.
  • Uses a large number of core and departmental applications and installs their own applications. Requires SaaS application access.
  • Has a GPU requirement with API support for DirectX 10+, video playback, and Flash content.
  • Requires two-factor authentication when accessing applications remotely.

Contractor

External contractors usually require access to specific line-of-business applications, typically from a remote or mobile location. A contractor:

  • Mainly uses applications from a corporate location but might access applications from mobile locations.
  • Uses a subset of core and departmental applications based on the project they are working on. Might require SaaS application access.
  • Has restricted access to clipboard, USB devices, and so on.
  • Requires two-factor authentication when accessing applications remotely.

Table 3: Horizon 7 Common Use Cases

Recovery Use Case Requirements 

With a focus on disaster recovery, the main emphasis falls on the availability and recoverability requirements of the differing types of users. For each of the previously defined use cases and their requirements, we can define the recovery requirements.

This reference architecture caters to three common disaster recovery classifications, which can be adapted to cope with most scenarios in a disaster recovery–enabled Workspace ONE environment.

Use Case and Recoverability Objective 

Description 

Active/Active 

RTO = Low 

RPO = Low 

  • Users require the lowest possible recovery time for the service (for example, health worker).
  • Mobile users might roam from continent to continent.
  • Users need to get served from the nearest geographical data center per continent.
  • Service consumed is available in both primary and secondary data centers without manual intervention.

Active/Passive 

RTO = Medium 

RPO = Medium 

  • Users normally work in a single office location.
  • Service consumed is pinned to a single data center.
  • Failover of the service to the second data center ensures business continuity.

Stretched Active/Passive 

RTO = Medium 

RPO = Medium 

  • Environment uses Horizon 7 full-clone desktops, and IT wants to implement disaster recovery.
  • 1:1 relationship between a user and a desktop.
  • Failover of the service to the second data center ensures business continuity.
  • Data centers are in a metro or campus network environment with low network latency between sites.

Table 4: Disaster Recovery Classifications

The RTO is defined as the time it takes to recover a given service. RPO is the maximum period in which data might be lost.

Low targets are defined as 30- to 60-second estimates. Medium targets are estimated at 45–60 minutes. These targets depend on the environment and the components included in the recovery service.

Service Definitions

From our business requirements, we outlined several typical use cases and their requirements. Taking the business requirements and combining them with one or more use cases enables the definition of a service.

The service, for a use case, defines the unique requirements and identifies the technology or feature combinations that satisfy those unique requirements. After the service has been defined, you can define the service quality to be associated with that service. These qualities include the performance, availability, security, and management and monitoring requirements to meet SLAs.

The detail required to build out the products and components comes later, after the services are defined and the required components are understood.

Do not treat the list of services as exclusive or prescriptive; each environment is different. Adapt the services to your particular use cases. In some cases, that might mean adding additional components, while in others it might be possible to remove some that are not required.

You could also combine multiple services together to address more complex use cases. For example, you could combine a Workspace ONE service with a Horizon 7 service and a recovery service.

Example of Combining Multiple Services for a Complex Use Case

Figure 8: Example of Combining Multiple Services for a Complex Use Case

Workspace ONE Use Case Services

A use case service identifies the features required for a specific type of user. For example, a mobile task worker might use a mobile device for a single task through a single application. The Workspace ONE use case service for this worker could be called the mobile device management service. This service uses only a few of the core Workspace ONE components. The following table lists the core components referenced in these use cases.

Component

Function

VMware AirWatch

Enterprise mobility management

VMware Identity Manager

Identity platform

Workspace ONE app

End-user access to apps

VMware Horizon

Virtual desktops and Remote Desktop Services (RDS) published applications delivered either through Horizon Cloud or Horizon 7

VMware Boxer

Secure email clients

VMware AirWatch® Browser™

Secure web browser

AirWatch Content Locker

Mobile content repository

VMware Enterprise Systems Connector (VMware AirWatch Cloud Connector + VMware Identity Manager Connector)

Directory sync to enterprise directories

VMware Unified Access Gateway

VMware AirWatch tunnel, and content gateway

VMware AirWatch® Secure Email Gateway™

Email proxy service

Table 5: Core Components of Workspace ONE

Mobile Device Management Service

Overview: Many organizations have deployed mobile devices and have lightweight management capabilities, like simple email deployment and device policies, such as a PIN requirement, device timeouts, and device wiping. But they lack a comprehensive and complete management practice to enable a consumer-simple, enterprise-secure model for devices.

Use Cases: Mobile Task -Based Workers

Unique Requirements

Components

Provide device management beyond simple policies

  • Workspace ONE native app
  • VMware Identity Manager authentication
  • VMware Enterprise Systems Connector

Enable adaptive management capabilities

  • Workspace ONE native app
  • Adaptive management
  • Workspace services device enrollment

Table 6: Unique Requirements of Mobile Task Workers

Blueprint

The following figure shows a high-level blueprint of a Workspace ONE Standard deployment and the available components.

Mobile Device Management Service Blueprint

Figure 9: Mobile Device Management Service Blueprint (Dimmed Boxes Are Not Needed for This Service)

Mobile Productivity Service

Overview: Organizations with a more evolved device management strategy are often pushed by end users to enable more advanced mobility capabilities in their environment. Requested capabilities include SSO and multifactor authentication, and access to productivity tools. However, from an enterprise perspective, providing this much access to corporate information means instituting a greater degree of control, such as blocking native email clients in favor of managed email, requiring syncing content with approved repositories, and managing which apps can be used to open files.

Use Cases: Mobile Knowledge Workers, Contractors

Unique Requirements

Components

Multifactor authentication

  • VMware Verify™

SSO

  • VMware Identity Manager and VMware AirWatch

Managed email

  • VMware Boxer

Enterprise content synchronization

  • AirWatch Content Locker

Secure browsing

  • AirWatch Browser

Table 7: Unique Requirements of Mobile Knowledge Workers and Contractors

Blueprint

The following figure shows a high-level blueprint of a Workspace ONE Advanced deployment and the available components.

Mobile Productivity Service Blueprint

Figure 10: Mobile Productivity Service Blueprint (Dimmed Boxes Are Not Needed for This Service)

Mobile Application Workspace Service

Overview: Recognizing that some applications are not available as a native app on a mobile platform and that some security requirements dictate on-premises application access, virtualized applications and desktops become a core part of a mobility strategy. Building on the mobile productivity service, and adding access to VMware Horizon–based resources, enables this scenario.

Many current VMware Horizon users benefit by adding the Workspace ONE catalog capabilities as a single, secure point of access for their virtual desktops and applications.

Use Cases: Contractors, Mobile Knowledge Workers

Unique Requirements

Components

Access to virtual apps and desktops

  • Horizon Cloud or Horizon 7
  • Enterprise Systems Connector

Table 8: Unique Requirements of Contractors and Mobile Knowledge Workers

Blueprint

The following figure shows a high-level blueprint of a Workspace ONE Enterprise deployment and the available components.

Mobile Application Workspace Service Blueprint

Figure 11: Mobile Application Workspace Service Blueprint

Horizon 7 Use Case Services

Horizon 7 use case services address a wide range of user needs. For example, a Business Process Application service can be created for static task workers, who require only a few Windows applications. In contrast, a High-Performance Workspace service can be created for multimedia designers who require graphics drivers that use hardware acceleration.

 

The following core components are used across the various use cases.

Component

Function

Horizon 7

Virtual desktops and RDSH-published applications

App Volumes

Application deployment

User Environment Manager

User profile, IT settings, and configuration for environment and applications

vRealize Operations for Horizon

Management and monitoring

vSphere

Infrastructure platform

vSAN

Storage platform

NSX

Networking and security platform

Table 9: Core Components of Horizon 7

Business Process Application Service

Overview: Windows applications are delivered as published applications provided by farms of RDSH servers. The RDSH servers are instant clones to provide space and operational efficiency. Applications are delivered through App Volumes. Individual or conflicting applications are packaged with ThinApp and are available through the VMware Identity Manager catalog. User Environment Manager applies profile settings and folder redirection.

Use Case: Static Task Worker

Unique Requirements

Components

Small number of Windows applications

  • Horizon 7 RDSH-published applications (a good fit for a small number of applications)
  • App Volumes AppStacks

Requires location-aware printing

  • ThinPrint
  • User Environment Manager

Table 10: Unique Requirements of Static Task Workers

Service Qualities

Performance

Availability

Security

Management and Monitoring

Basic

Medium

Basic

(no external access)

Basic

Blueprint

Business Process Application Service Blueprint

Figure 12: Business Process Application Service Blueprint

Mobile Secure Workspace Service

Overview: The core Windows 10 desktop is an instant clone, which is kept to a plain Windows OS, allowing it to address a wide variety of users. The majority of applications are delivered through App Volumes, with core and different departmental versions. Individual or conflicting applications are packaged with ThinApp and are available through the VMware Identity Manager catalog. User Environment Manager applies profile settings and folder redirection. Although Windows 10 was used in this design, Windows 7 could be substituted.

Use Cases: Mobile Knowledge Worker, Contractors

Unique Requirements

Components

Large number of core and departmental applications

  • Horizon 7 instant-clone virtual desktop (a good fit for larger numbers of applications)
  • App Volumes AppStacks for core applications and departmental applications

Require access from mobile locations

  • Unified Access Gateway, Blast Extreme

Two-factor authentication when remote

  • Unified Access Gateway, True SSO

Video content and Flash playback

  • URL content redirection, Flash redirection
  • Access to USB devices
  • Restricted access to clipboard, USB, and so on (for example, for contractors)
  • User Environment Manager, Smart Policies, application blocking

Table 11: Unique Requirements of Mobile Knowledge Workers and Contractors

Service Qualities

Performance

Availability

Security

Management and Monitoring

Medium

High

Medium

high (contractors)

Medium

Blueprint

Mobile Secure Workspace Service Blueprint

Figure 13: Mobile Secure Workspace Service Blueprint

Dedicated Power Workspace Service

Overview: Similar to the construct of the Mobile Secure Workspace service with the addition of an App Volumes writable volume. Writable volumes allow users to install their own applications and have them persist across sessions.

Use Case: Software Developer / IT (Power User)

Unique Requirements

Components

Windows extensive CPU and memory

  • Horizon 7 instant-clone virtual desktop

User-installed applications

  • App Volumes writable volume

Table 12: Unique Requirements of Software Developers and Power Users

Service Qualities

Performance

Availability

Security

Management and Monitoring

Medium

High

High

Medium

 

Blueprint

Dedicated Power Workspace Service Blueprint

Figure 14: Dedicated Power Workspace Service Blueprint

Developer Workspace Service

Overview: The core desktop is a full clone of Linux. Applications can be pre-installed into the master VM, and users can also add their own applications to their individual clones. Desktops are persistent to the user.

Use Case: Software Developer/IT (Power User)

Unique Requirements

Components

Linux extensive CPU and memory

  • Horizon 7 Linux full clone

Table 13: Unique Requirements of Software Developers and Power Users

Service Qualities

Performance

Availability

Security

Management and Monitoring

Medium

Medium

Medium

Basic

 

Blueprint

Developer Workspace Service Blueprint

Figure 15: Developer Workspace Service Blueprint

High-Performance Workspace Service

Overview: Similar to the Dedicated Power Workspace service but has more CPU and memory, and can use hardware-accelerated rendering with NVIDIA GRID graphics cards installed in the vSphere servers (vGPU).

Use Case: Multimedia Designer

Unique Requirements

Components

GPU accelerated

  • NVIDIA vGPU-powered

User-installed applications

  • App Volumes writable volume

Hardware H.264 encoding

  • Blast Extreme

Table 14: Unique Requirements of Multimedia Designers

Service Qualities

Performance

Availability

Security

Management and Monitoring

High

High

Medium

High

 

Blueprint

High-Performance Workspace Service Blueprint

Figure 16: High-Performance Workspace Service Blueprint

Recovery Services

To ensure availability, recoverability, and business continuity, the design of the services also needs to consider disaster recovery.

We can define recovery services and map them to the previously defined use-case services. Some of these use case services could be mapped to a different recovery service, depending on the exact mix of components being used.

Recovery services are designed to operate in either an active/active or an active/passive mode and should be viewed from the users’ perspective.

  • In active/passive mode, loss of an active data center instance or pod of Horizon 7 servers requires that the passive instance of the service be promoted to active status for the user.
  • In active/active mode, the loss of a data center instance or pod of Horizon 7 servers does not impact service availability for the user because the remaining instance or instances continue to operate independently and can offer the end service to the user.

In the use cases, a user belongs to a home site and can have an alternative site available to them. Where user pinning is required, an active/passive approach results in a named user having a primary site they always connect to or get redirected to during normal operations.

Also a number of components are optional to a service, depending on what is required. Blueprints for multi-site VMware Identity Manager, App Volumes, and User Environment Manager data are detailed after the main active/passive and active/active recovery services.

VMware Identity Manager/Workspace ONE Recovery Service

VMware Identity Manager provides a number of key capabilities for Workspace ONE implementations. Among them are:

  • Secure point of access for users – Branded as Workspace ONE, which provides browser-based access to different types of applications, including SaaS-based web applications (such as Salesforce, Dropbox, and Concur), VMware Horizon–based applications and desktops, RDSH-based applications and desktops, ThinApp packaged apps, and Citrix-based applications and desktops. The catalog simplifies application access for end users.
  • Enterprise identity management – Syncs and extends on-premises directory credentials (such as Active Directory) to SaaS and native mobile applications.
  • Enterprise SSO – Ensures that users have a single identity to log in with for internal, external, and published applications.
  • A self-service app store – Allows end users to identify and be entitled to applications easily while providing enterprise security and compliance controls to ensure that the right users have access to the right applications.

When adopting these capabilities, it is important to provide resilience and failover capability both within and between sites to ensure business continuity.

VMware Identity Manager can be architected in an active/passive manner, with a failover process recovering the service in the standby site.

VMware Identity Manager/Workspace ONE Recovery Blueprint

Figure 17: VMware Identity Manager/Workspace ONE Recovery Blueprint

Horizon 7 Active/Passive Recovery Service 

Requirement: The use case service is run from a specific data center but can be failed over to a second data center in the event of an outage.

Overview: The core Windows desktop is an instant clone or linked clone, which is preferably kept to a vanilla Windows OS, allowing it to address a wide variety of users. The core could also be a desktop or session provided from an RDSH farm of linked clones or instant clones.

Although applications can be installed in the master image OS, the preferred method is to have applications delivered through App Volumes, with core and department-specific applications included in various AppStacks. Individual or conflicting applications are packaged with VMware ThinApp and are available through the VMware Identity Manager catalog.

If the use case requires the ability for users to install applications themselves, App Volumes writable volumes can be assigned.

User Environment Manager applies the profile, IT settings, user configuration, and folder redirection.

Use case services accommodated: Business Process Application service, Dedicated Power Workspace service, High-Performance Workspace service. Table 6 details the recovery requirements and the corresponding Horizon 7 component that addresses each requirement.

Requirement 

Comments 

Windows desktop or RDSH available in both sites 

  • Horizon 7 pools or farms are created in both data centers.
  • Master VM can be replicated to ease creation.
  • Cloud Pod Architecture (CPA) is used for user entitlement and to control consumption.

Native applications 

Applications are installed natively in the base Windows OS. No replication is required because native applications exist in both data center pools.

Attached applications

(optional)

Applications contained in App Volumes AppStacks are replicated using App Volumes storage groups.

User-installed applications

(optional)

App Volumes writable volumes.

  • RTO = 60–90 minutes 
  • RPO = 1–2 hours (array dependent) 

IT settings 

User Environment Manager IT configuration is replicated to another data center.

  • RTO = 30–60 seconds 
  • RPO = Approximately 5 minutes 

User data and configuration 

User Environment Manager user data is replicated to another data center.

  • RTO = 30–60 seconds 
  • RPO = Approximately 2 hours 

SaaS applications 

VMware Identity Manager is used as a single-sign-on workspace and is present in both locations to ensure continuity of access.

Mobile access 

Unified Access Gateway, Blast Extreme 

Table 15: Active/Passive Recovery Service Requirements

At a high level, this service consists of a Windows environment delivered by either an instant- or linked-clone desktop or RDSH server, with identical pools created at both data centers. With this service, applications can be natively installed in the OS, provided by App Volumes AppStacks, or some combination of the two. User profile and user data files are made available at both locations and are also recovered in the event of a site outage.

Active/Passive Recovery Service Blueprint 

Figure 18: Active/Passive Recovery Service Blueprint 

Horizon 7 Active/Active Recovery Service 

Requirement: This use case service is available from multiple data centers without manual intervention.

Overview: Windows applications are delivered as natively installed applications in the Windows OS, and there is little to no reliance on the Windows profile in case of a disaster. User Environment Manager provides company-wide settings during a disaster. Optionally, applications can be delivered through App Volumes AppStacks, with core and department-specific applications included in various AppStacks.

This service generally requires the lowest possible RTO, and the focus is to present the user with a desktop closest to his or her geographical location. For example, when traveling in Europe, the user gets a desktop from a European data center; when traveling in the Americas, the same user gets a desktop from a data center in the Americas.

Horizon 7 services accommodated: Mobile Secure Workspace service. Table 5 details the recovery requirements and the corresponding Horizon 7 component that addresses each requirement.

Requirements

Products/Solutions/Settings

Lowest possible RTO during a disaster 

No reliance on services that cannot be immediately failed over.

Windows desktop or RDSH available in both sites 

  • Horizon 7 desktop and application pools are created in both data centers.
  • Master VM can be replicated to ease creation.
  • Cloud Pod Architecture (CPA) is used to ease user entitlement and consumption.

Native applications 

Applications are installed natively in the base Windows OS. No replication is required because native applications exist in both data center pools.

Attached applications

(optional)

Applications contained in App Volumes AppStacks are replicated using App Volumes storage groups.

IT settings 

User Environment Manager IT configuration is replicated to another data center. The following RTO and RPO targets apply during a data center outage when a recovery process is required:

• RTO = 30–60 seconds 

• RPO = 30–60 seconds 

User data and configuration 

(optional)

User Environment Manager user data is replicated to another data center. The following RTO and RPO targets apply during a data center outage when a recovery process is required:

• RTO = 30–60 seconds 

• RPO = Approximately 2 hours 

Mobile access 

Unified Access Gateway, Blast Extreme 

Table 16: Active/Active Recovery Service Requirements 

At a high level, this service consists of a Windows environment delivered by a desktop or an RDSH server available at both data centers. With this service, applications can be natively installed in the OS, attached using App Volumes AppStacks, or some combination of the two. If required, the user profile and user data files can be made available at both locations and can also be recovered in the event of a site outage.

Active/Active Recovery Service Blueprint

Figure 19: Active/Active Recovery Service Blueprint

App Volumes Active/Passive Recovery Service

Although applications can be installed in the base OS, they can alternatively be delivered by App Volumes AppStacks. An AppStack is used to attach applications to either the Horizon 7 desktop or the RDSH server that provides Horizon 7 published applications.

Applications are attached either to the desktop, at user login, or to the RDSH server as it boots. Because AppStacks are read-only to users and are infrequently changed by IT, AppStacks can be replicated to the second, and subsequent, locations and are available for assignment and mounting in those locations as well.

App Volumes writable volumes are, by contrast, used for content such as user-installed applications, and are written to by the end user. Writable volumes must be replicated and made available at the second site. Due to the nature of the content, writable volumes can have their content updated frequently by users. These updates can affect the RPO and RTO achievable for the overall service. Operational decisions can be made as to whether to activate the service in Site 2 with or without the writable volumes to potentially reduce the RTO.

App Volumes Active/Passive Recovery Blueprint

Figure 20: App Volumes Active/Passive Recovery Blueprint

App Volumes Active/Active Recovery Service

As can be seen in the active/passive App Volumes blueprint, App Volumes AppStacks can be replicated from one site to another and made available, actively, in both because AppStacks require read-only permissions for the user.

The complication comes with writable volumes because these require both read and write permissions for the user. If a service does not include writable volumes, the App Volumes portion of the service can be made active/active.

App Volumes Active/Active Recovery Blueprint

Figure 21: App Volumes Active/Active Recovery Blueprint

User Environment Manager Profile Data Recovery Service

User Environment Manager provides profile management by capturing user settings for the operating system, applications, and user personalization. The captured settings are stored on file shares that need to be replicated to ensure site redundancy.

Although profile data can be made available to both data centers, there is a failover process in the event of the loss of Site 1 that can impact the RTO and RPO.

Operational decisions can be made in these scenarios as to whether the service in Site 2 would be made available with reduced functionality (for example, available with the Windows base, the applications, and the IT configuration but without the user-specific settings).

User Environment Manager Profile Recovery Blueprint

Figure 22: User Environment Manager Profile Recovery Blueprint

Architecture Principles and Concepts

A Workspace ONE design uses a number of complementary components to provide a variety of highly available services to address the identified use cases. Before we can assemble and integrate these components to form the desired service, we first need to design and build the infrastructure required.

The components in Workspace ONE, such as VMware Identity Manager, VMware AirWatch, and VMware Horizon are available as on-premises and cloud-hosted products.

For this reference architecture, the approach taken is to install the main components of Workspace ONE on-premises. Depending on the use cases that need to be covered, integration to cloud-hosted components might be included in the solution.

Workspace ONE Logical Architecture

The Workspace ONE platform is composed of VMware Identity Manager and VMware AirWatch. Although each product can operate independently, integrating them is what enables the Workspace ONE product to function.

VMware Identity Manager and VMware AirWatch are built to provide tight integration between identity and device management. This integration has been simplified in recent versions to ensure that configuration of each product is relatively straightforward.

Although VMware Identity Manager and VMware AirWatch are the core components in a Workspace ONE deployment, you can deploy a variety of other components, depending on your business use cases. As is shown in the following figure, you can use AirWatch Secure Email Gateway for access to an on-premises exchange server or use VMware Unified Access Gateway to provide the VMware Tunnel™ or VPN-based access to internal resources. Refer to the Architecture section in the AirWatch documentation of the full range of components that apply to a deployment.

Sample Workspace ONE Architecture

Figure 23: Sample Workspace ONE Architecture

Following is a description of the components shown in the Workspace ONE architecture diagram:

  • Workspace ONE native mobile app  OS-specific versions of the native app are available for iOS, Android, and Windows 10. The Workspace ONE app presents a unified application catalog across VMware Identity Manager resources and native mobile apps, allows users to easily find and install enterprise apps, and provides an SSO experience across resource types.
  • VMware AirWatch On-premises installation of VMware AirWatch. VMware AirWatch consists of several core components, which can be installed on a single server. VMware AirWatch acts as the mobile device management (MDM), mobile content management (MCM), and mobile application management (MAM) platform.
  • VMware Identity Manager Acts as an identity provider by syncing with Active Directory to provide SSO across SAML-based applications, VMware Horizon–based applications and desktops, and VMware ThinApp packaged apps. VMware Identity Manager is also responsible for enforcing authentication policy based on networks, applications, or platforms.
  • VMware Enterprise Systems Connector Combination of two different services (the former AirWatch Cloud Connector and VMware Identity Manager Connector) bundled within a single Windows-based installer. The Enterprise Systems Connector connects resources located in different security zones (namely, the DMZ and the LAN).
  • AirWatch Cloud Connector (ACC) component – Runs in the internal network, acting as a proxy that securely transmits requests from VMware AirWatch to the organization’s critical back-end enterprise infrastructure components. Organizations can leverage the benefits of VMware AirWatch® Mobile Device Management™, running in any configuration, together with those of their existing LDAP, certificate authority, email, and other internal systems.
  • VMware Identity Manager Connector component – Performs directory sync and authentication between an on-premises Active Directory and the VMware Identity Manager service. A legacy Linux-based virtual appliance is also available.
  • Email integration – VMware AirWatch supports integration with email services, such as Microsoft Exchange, GroupWise, IBM Notes (formerly Lotus Notes), and G Suite (formerly Google Apps for Work). You can integrate email in three different ways: through AirWatch Secure Email Gateway, PowerShell integration, or G Suite integration. AirWatch Secure Email Gateway requires a server to be configured in the data center. PowerShell communicates directly with Exchange ActiveSync on Exchange 2010 or later or Microsoft Office 365. VMware AirWatch integrates directly with the Google Cloud services and does not need additional servers.
  • Content integration The VMware AirWatch® Mobile Content Management™ solution helps organizations address the challenge of securely deploying content to a wide variety of devices using a few key actions. An administrator can leverage the AirWatch Console to create, sync, or enable a file repository. After configuration, this content deploys to end-user devices with AirWatch Content Locker. Access to content can be either read-only or read-write.
  • VMware Unified Access Gateway Virtual appliance that allows Internet-based access to internal, on-premises resources, such as on-premises Horizon 7 desktops or published applications, and on-premises web servers or content.

Workspace ONE Capabilities

Workspace ONE features provide enterprise-class security without sacrificing convenience and choice for end users:

  • Mobile SSO – One-touch SSO technology available for all platforms that Workspace ONE is supported on. The implementation on each OS is based on features provided by the underlying OS. For iOS, one-touch SSO uses technology known as the key distribution center (KDC). For Android, the authentication method is called mobile SSO for Android. And for Windows 10, it is called cloud certificate.
  • Secure browsing – Using AirWatch Browser instead of a native browser or third-party browser ensures that access to sensitive web content is secure and manageable.
  • Data loss prevention (DLP) Forces documents or URLs to open only in approved applications to prevent accidental or purposeful distribution of sensitive information.
  • Device enrollment Process by which a device is brought under management in a VMware AirWatch environment. Enrollment allows the device to be managed, device profiles and applications to be distributed, and content delivered or removed. Enrollment also allows extensive reporting based on the devices’ check-in to the VMware AirWatch service.
  • Adaptive management – Process by which an end user can install the Workspace ONE app on a device, log in with credentials, and have access to some applications without device enrollment. Where other applications require device enrollment, the Workspace ONE app can initiate enrollment for the user.
  • Conditional access – Both VMware Identity Manager and VMware AirWatch have ways to evaluate compliance. When users register their devices with Workspace ONE, samples containing data used to evaluate compliance are sent to the AirWatch cloud service on a scheduled basis. The evaluation of this sample data ensures that the device meets the compliance rules set by the administrator in the AirWatch Console. If the device goes out of compliance, corresponding actions configured in the AirWatch Console are taken.
    VMware Identity Manager includes an access policy option that you can configure to check the VMware AirWatch server for device compliance status when users sign in from the device. The compliance check ensures that users are blocked from signing in to an application or using SSO to the VMware Identity Manager portal if the device is out of compliance. When the device is compliant again, the ability to sign in is restored. You can enforce these actions based on the network users are on, the platform they are using, or the applications being accessed. In addition to checking VMware AirWatch for device compliance, VMware Identity Manager can evaluate compliance based on network range of the device, type of device, operating system of the device, and credentials.
  • Unified application catalog – Combines VMware Identity Manager and VMware AirWatch application catalogs and presents them on the Workspace ONE app Catalog tab.
  • Resource types – Workspace ONE supports a variety of applications exposed through the VMware Identity Manager and VMware AirWatch catalogs, including SaaS-based SAML apps, VMware Horizon apps and desktops, and ThinApp packaged apps delivered through VMware Identity Manager, and native mobile applications through the VMware AirWatch catalog.
  • VMware Horizon 7 – Platform for VDI and published desktops (VDI or RDS-based desktops published through VMware Horizon) and published apps (virtual applications published through VMware Horizon).

Horizon 7 Enterprise Edition Logical Architecture

From a data center perspective, several components and servers must be deployed to create a functioning Horizon 7 Enterprise Edition environment to deliver the desired services.

Horizon 7 Enterprise Edition Logical Architecture

Figure 24: Horizon 7 Enterprise Edition Logical Architecture

Following is a description of the components shown in the Horizon 7 architecture diagram:

  • VMware Identity Manager – Is an Identity-as-a-Service (IDaaS) offering, providing application provisioning, a self-service catalog, conditional access controls, and single sign-on (SSO) for SaaS, web, cloud, and native mobile applications.
  • Connection Server Acts as a broker for client connections. Authenticates users through Windows Active Directory and directs the request to the appropriate virtual machine, physical PC, or Microsoft RDSH server.
  • Instant Clone Technology – Provides single-image management with automation capabilities. You can rapidly create instant-clone desktop pools and automated RDSH server farms that contain thousands of VMs.
  • Unified Access Gateway – Functions as a secure gateway for users who want to access remote desktops and applications from outside the corporate firewall.
  • App Volumes Manager – Orchestrates application delivery by managing assignments of application volumes (AppStacks and writable volumes) to users, groups, and target computers.
  • Microsoft SQL Servers – Microsoft SQL database servers are used to host several databases used by the management components of Horizon 7 Enterprise Edition.
  • vRealize Operations Manager for Horizon – Provides end-to-end visibility into the health, performance, and efficiency of virtual desktop and application environments from the data center and the network, all the way through to devices.
  • File servers – Store user files, profile information, and more.
  • VMware ESXi™ hosts – Physical servers running vSphere.
  • vSAN storage – Delivers high-performance, flash-optimized, hyper-converged storage using server-attached flash devices or hard disks to provide a flash-optimized, highly resilient, shared datastore.
  • NSX for vSphere – Provides network-based services such as security, virtualization networking, routing, and switching in a single platform. With micro-segmentation, you can set application-level security policies based on groupings of individual workloads, and you can isolate each virtual desktop from all other desktops as well as protecting the Horizon 7 management servers.
  • VMware vCenter ServerManages the vSphere hosts and VMs. Also provides provisioning tasks and is used by Connection Servers and Composer to create VMs and clones, and App Volumes to mount AppStacks and user writeable volumes.

Horizon 7 Pod and Block

One key concept in a Horizon 7 environment design is the use of pods and blocks, which gives us a repeatable and scalable approach.

A pod is made up of a group of interconnected Connection Servers that broker desktops or published applications. A pod can broker up to 20,000 sessions (10,000 recommended), including desktop and RDSH sessions. Multiple pods can be interconnected using Cloud Pod Architecture (CPA) for a maximum of 140,000 sessions. For numbers above that, separate CPAs can be deployed. For more information, see the VMware Knowledge Base article VMware Horizon 7 Sizing Limits and Recommendations (2150348).

A pod is divided into multiple blocks to provide scalability. Each block is made up of one or more resource vSphere clusters, and each block has its own VMware vCenter Server®, Composer server (where linked clones are to be used), and VMware NSX® Manager™ (where NSX is being used). The number of virtual machines (VMs) a block can typically host depends on the type of Horizon 7 VMs used:

  • 5,000 instant-clone VMs (without App Volumes)
  • 4,000 linked-clone or full-clone VMs (without App Volumes)
  • 2,000 VMs if App Volumes AppStacks are attached

Horizon 7 Pod and Block Design

Figure 25: Horizon 7 Pod and Block Design

To add more resource capacity, we simply add more resource blocks. We also add an additional Connection Server for each additional block to add the capability for more session connections.

Depending on the types of VMs (instant clones, linked clones, full clones, using App Volumes) a resource block could be up to 5,000, 4,000 or 2,000 VMs. Typically, we have multiple resource blocks and up to seven Connection Servers in a pod capable of hosting 10,000 sessions. For numbers above that, we deploy additional pods.

As you can see, this approach allows us to design a single block capable of thousands of sessions that can then be repeated to create a pod capable of handling 10,000 sessions. Multiple pods grouped using Cloud Pod Architecture can then be used to scale the environment as large as needed.

Important: A single pod and the Connection Servers in it must be located within a single data center and cannot span locations. Multiple View pods and locations must be interconnected using Cloud Pod Architecture (CPA).

This guide focuses on the architecture of a complete Horizon 7 Enterprise Edition environment but also concentrates on the design required to build and scale the first block.

For scalability and operational efficiency, it is normally a best practice to have a separate vSphere cluster to host all the management components. This structure keeps the VMs that run services like vCenter Server, NSX Manager, Connection Server, Unified Access Gateway, and databases separate from the desktop and RDSH server VMs. Other Horizon 7 Enterprise Edition components are generally designed to follow this approach to ensure scalability. We detail the design of each of the components later in this document.

Although this separation of management components is generally recommended, management components can be co-hosted on the same vSphere cluster as the end-user resources, if desired. If you place everything on the same vSphere cluster, you must configure the setup to ensure resource prioritization for the management components. Sizing of resources (for example, virtual desktops) must also take into account the overhead of the management servers.

For the purposes of this guide, we focus on a relatively simple environment composed of a single resource block and a separate management block.

Horizon 7 Multi-site Architecture Principles

This reference architecture documents and validates the deployment of all features of Horizon 7 Enterprise Edition across two data centers.

The architecture has the following primary tenets:

  • Site redundancy – Eliminate any single point of failure that can cause an outage in the service.
  • Data replication – Ensure that every layer of the stack is configured with built-in redundancy or high availability so that the failure of one component does not affect the overall availability of the desktop service.

To achieve site redundancy, 

  • Services built using Horizon 7 are available in two data centers that are capable of operating independently.
  • Users are entitled to equivalent resources from both the primary and secondary data center.
  • Some services are available from both data centers (active/active).
  • Some services require failover steps to make the secondary data center the live service (active/passive).

To achieve data replication, 

  • Any component, application, or data required to deliver the service in the second data center is replicated to a secondary site.
  • The service can be reconstructed using the replicated components.
  • The type of replication depends on the type of components and data, and the service being delivered.
  • The mode of the secondary copy being active or passive depends on the data replication and service type.

Besides the principles outlined in this section, this reference architecture also adheres to some architectural guidelines that address the recoverability targets defined in the Recovery Services section of the Service Definitions chapter.

Active/Passive Architecture

Active/passive architecture uses two or more pods of Connection Servers, with at least one pod located in each data center. They are joined together using Cloud Pod Architecture configured with global entitlements. This strategy effectively aligns a named user to a given data center. Essentially, this is the same architecture as active/active, but the global entitlements and user home sites are configured differently.

Active/Passive Architecture

Figure 26: Active/Passive Architecture

Active/Active Architecture

Active/active architecture uses two or more pods of Connection Servers, with at least one pod located in each data center. The pods are joined using Cloud Pod Architecture, which is configured with global entitlements that allow named users to access either site at any given point in time.

Active/Active Architecture

Figure 27: Active/Active Architecture

Stretched Active/Active Architecture (Unsupported)

This architecture is unsupported and is only shown here to stress why it is not supported. Connection Servers within a given site must always run on a well-connected LAN segment and therefore cannot be running actively in multiple geographical locations at the same time.

Unsupported Stretched Active/Active Architecture

Figure 28: Unsupported Stretched Active/Active Architecture

Multi-site Logical Architecture

The following diagram illustrates at a high level a logical architecture that contains all the major components. This architecture is designed to meet the business requirements as defined under Business Drivers and Requirements.

Multi-site Logical Architecture

Figure 29: Multi-site Logical Architecture

In this diagram, only the global virtual IPs (VIPs) and names at the very top would be used for user access. These are horizon.company.com and identity.company.com. Global namespaces make it easier to handle user redirection during outages because they give access to either site through the same URL.

The site-specific VIPs (vidm-a.company.com, hzn-a, vidm-b, and so on) are the local load-balanced names for each of the different server components. End users would never enter these URLs. Administrators would use these URLs only when configuring targets for the global VIPs.

General Multi-site Best Practices

There are numerous ways to implement a disaster recovery architecture, but some items can be considered general best practices.

Components That Must Always Run with a Primary Instance

Even with an active/active usage model across two data centers, one of the data centers holds certain roles that are not multi-master defined. The following components must run with a primary instance in a given site: 

  • VMware Identity Manager.
  • User profile and data shares containing User Environment Manager user data.
  • Active Directory FSMO roles (specifically, PDC Emulator, because it is required to make changes to domain-based DFS namespaces).
  • Microsoft SQL Server Always On availability groups (if used).

Be sure to secure those resources that are not multi-master by nature or that cannot be failed over automatically. Procedures must be put in place to define the steps that need to be taken to recover these resources.

For this reference architecture design, we chose to place the primary availability group member in Site 1 as well as all AD FSMO roles on a domain controller. We made this choice because we had a good understanding of the failover steps required if either Site 1 or Site 2 failed.

Component Replication and Roaming Users

Use Workspace ONE components to create effective replication strategies and address the needs of users who roam between sites:

  • Create a disaster plan up front that defines what a disaster means in your organization. The plan should specify if a 1:1 mapping in terms of resources is required, or what portion of the workforce is required to keep the organization operational.
  • Replicate desktop and server (RDSH) master image templates between sites to avoid having to build the same templates on both sites. You can use a vSphere content library or perform a manual replication of the resources needed across the whole implementation.
  • With Horizon 7 use Cloud Pod Architecture and avoid metro-cluster with vSAN stretched cluster unless you have a persistent desktop model in the organization that cannot easily be transformed into a nonpersistent use case.
  • With regard to initial user placement, even with a roaming profile use case, a given user must be related to user profile data (User Environment Manager user data), meaning that a relationship must be established between a user account and a data center. This also holds true when planning how users in the same part of the organization (such as sales) should be split between sites to avoid an entire function of the company being unable to work should a disaster strike.
  • For a roaming profile use case, where User Environment Manager is used to control the user profile data, VMware recommends that FlexEngine be used whenever possible in combination with folder redirection. This keeps the core profile to a minimum size and optimizes login times in the case where a profile is loaded across the link between the two data centers.
  • Use Microsoft SQL Server failover cluster instances and Always On availability groups for VMware Identity Manager where possible. This is not required for VMware vCenter Server, the Connection Server event database, and vCenter Server Update Manager. We used Microsoft SQL Server 2016, but Microsoft SQL Server 2014 is also supported.

Component Design: VMware AirWatch Architecture

VMware AirWatch is a key pillar of a Workspace ONE implementation. It is responsible for device enrollment, a mobile application catalog, policy enforcement regarding device compliance, and integration with key enterprise services, such as email, content, and social media. VMware AirWatch is available as an on-premises or cloud-hosted product. VMware AirWatch features include:

  • A device management platform – Allows full life-cycle management of a wide variety of devices, including phones, tablets, and ruggedized and special-purpose devices.
  • Application deployment capabilities – Provides automatic deployment or self-service application access for employees.
  • User and device profile services – Ensure that configuration settings for users and devices comply with enterprise security requirements and simplify end-user access to applications.
  • Productivity tools – Include an email client with secure email functionality, a content management tool for securely storing and managing content, a web browser to ensure secure access to corporate information and tools, and enterprise social media applications for collaboration and chat.

Design Overview

VMware AirWatch can be implemented using an on-premises or a SaaS-based model. This reference architecture focuses on an on-premises design and deployment.

VMware AirWatch is composed of separate services that can be installed on a single- or multiple-server architecture to meet security and load requirements. Service endpoints can be spread across different security zones, with those that require external, inbound access located in a DMZ and the administrative console located in a protected, internal network, as shown in the following figure.

Syncing with internal resources such as Active Directory or a Certificate Authority can be achieved directly from the core components (Device Services and Admin Console) or through a separate cloud connector, which can be implemented using either the Enterprise Systems Connector or an AirWatch Cloud Connector. The separate connector can run within the LAN in outbound-only connection mode, meaning the connector receives no incoming connections from the DMZ. The main components of VMware AirWatch are described in the following table.

 

Component

Description

AirWatch Admin Console

Administration console for configuring policies within VMware AirWatch, to monitor and manage devices and the environment.

AirWatch Device Services

Services that authenticate users and communicate with managed devices. VMware AirWatch relies on this component for:

  • Device enrollment
  • Application provisioning
  • Delivering device commands and receiving device data
  • Hosting the AirWatch Self-Service Portal

API Endpoint

Collection of RESTful APIs, provided by VMware AirWatch, that allow external programs to use the core product functionality by integrating the APIs with existing IT infrastructures and third-party applications.

For deployments of up to 50,000 devices, the AirWatch API endpoint is installed on both the Console and Device Services servers, with the API Site URL pointing to the Console server by default.

If you anticipate performing third-party API integrations in the future, or if you want to make this component publicly accessible, then you should configure the API Site URL to point instead to the Device Services server. 

These requirements depend on how you use the APIs, with heavy use resulting in different sizing numbers. Because API use is situational, VMware AirWatch does not provide a standard recommendation for cases of heavy API use. Refer to the sizing disclaimers in the specific sections based on deployment size.

AirWatch Cloud Messaging Service (AWCM)

Service used in conjunction with the Enterprise Systems Connector to provide secure communication to your back-end systems. Enterprise Systems Connector uses AWCM to communicate with the AirWatch Console.

AWCM also streamlines the delivery of messages and commands from the AirWatch Console by eliminating the need for end users to access the public Internet or utilize consumer accounts, such as Google IDs. It serves as a comprehensive substitute for Google Cloud Messaging (GCM) for Android devices and is the only option for providing Mobile Device Management (MDM) capabilities for Windows rugged devices.

AWCM is typically installed on the Device Services server for deployments of up to 50,000 devices.

VMware Enterprise Systems Connector

Components that perform directory sync and authentication using an on-premises resource such as Active Directory or a trusted Certificate Authority.

Directory sync and authentication can be implemented using either the VMware Identity Manager Connector component or the AirWatch Cloud Connector (ACC) component.

Database

Microsoft SQL Server database that stores VMware AirWatch device and environment data.

All relevant application configuration data, such as profiles and compliance policies, persist and reside in this database. Consequently, the majority of the application’s back-end workload is processed here.

Memcached Server

A distributed data caching application that reduces the workload on the VMware AirWatch database. This server is intended for deployments of more than 5,000 devices.

Table 17: VMware AirWatch Components

Design Decision: Although either an on-premises or a SaaS implementation could deliver the required capabilities, in this reference architecture, an on-premises VMware AirWatch design is used. The implementation is separated into the three main components:

  • VMware AirWatch Admin Console
  • VMware AirWatch Device Services
  • VMware Enterprise Systems Connector (Cloud Connector)

The AirWatch Cloud Messaging Service is installed as part of the AirWatch Device Services server, and the API Endpoint is installed as part of the Admin Console server.

Simple AirWatch Logical Architecture

Figure 30: Simple AirWatch Logical Architecture

Database

All critical data and configurations for VMware AirWatch are stored in the database, and this is the data tier of the solution. AirWatch databases are based on the Microsoft SQL server platform. Application servers receive requests from the console and device users and process the data and results. No persistent data is maintained on the application servers (device and console services), but user and device sessions are maintained for a short time.

In this reference architecture, Microsoft SQL Server 2016 was used and its cluster offering Always On availability groups, which is supported with VMware AirWatch. This allows the deployment of multiple instances of each of the VMware AirWatch components, pointing to the same database protected by an availability group, with an availability group listener as the connection target for all instances.

Windows Server Failover Clustering (WSFC) can also be used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic.

VMware AirWatch runs on an external SQL database. Prior to running the VMware AirWatch database installer, have your database administrator prepare an empty external database and schema. Licensed users can use a Microsoft SQL Server 2012, SQL Server 2014, or SQL Server 2016 database server to set up a high-availability database environment.

For recommendations on hardware sizing for Microsoft SQL Servers, see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

Design Decision: An external Microsoft SQL database is implemented for this design.

VMware Enterprise Systems Connector

The Enterprise System Connector is composed of two components, the AirWatch Cloud Connector (ACC) and the VMware Identity Manager Connector. The installer serves as the unified connector package for both of these components for Workspace ONE, AirWatch, and identity uses.

The ACC and the VMware Identity Manager Connector have complementary purposes. Depending on the requirements, only the ACC component can be installed, or both the ACC and the VMware Identity Manager Connector can be installed.

Installing both components of the Enterprise Systems Connector is recommended for most Workspace ONE customers. In addition to ACC features, the full installation includes support for the following features:

  • Virtual apps and desktops in Workspace ONE
  • RSA SecurID authentication
  • Integrated Windows authentication
  • Multiple trusted or untrusted Active Directory domains with VMware Identity Manager
  • VMware Identity Manager with multiple directory-organization group configurations in AirWatch
  • Identity-centric integration features

The ACC and the VMware Identity Manager Connector can be installed on the same server instance or on separate server instances. If both components are co-located, give the server instance sufficient hardware resources to cope with the combined load.

For recommended hardware sizing of components, see On-Premises Architecture Hardware Assumptions in the Architecture section of the AirWatch Documentation.

AirWatch Cloud Connector Component

The ACC provides the ability to integrate VMware AirWatch with back-end enterprise systems. The ACC runs in the internal network, acting as a proxy that securely transmits requests from VMware AirWatch to the organization's enterprise infrastructure components. This allows organizations to leverage the benefits of AirWatch Mobile Device Management (MDM), running in any configuration, together with those of their existing LDAP, Certificate Authority, email, and other internal systems.

The ACC integrates with the following internal components:

  • Email Relay (SMTP)
  • Directory Services (LDAP/AD)
  • Email Management Exchange 2010 (PowerShell)
  • BlackBerry Enterprise Server (BES)
  • Lotus Domino Web Service (HTTPS)
  • Syslog (Event log data)

The ACC also allows the following PKI Integration add-ons:

  • Microsoft Certificate Services (PKI)
  • Simple Certificate Enrollment Protocol (SCEP PKI)
  • Third-party certificate services (on-premises only)

VMware Identity Manager Connector Component

The VMware Identity Manager Connector provides directory integration, user authentication, and integration with resources such as Horizon 7. Using the VMware Identity Manager Connector component provides the following additional capabilities to a deployment:

  • VMware Identity Manager Connector-based authentication methods such as password, RSA Adaptive Authentication, RSA SecurID, and RADIUS
  • Kerberos authentication for internal users
  • Integration with the following resources:
    • Horizon 7 desktop and application pools
    • VMware Horizon Cloud Hosted desktops and applications
    • Citrix-published resources

Design Decision: Both the ACC and the VMware Identity Manager Connector components of the VMware Enterprise Systems Connector will be installed.

Memcached

Memcached is a distributed data caching application available for use with VMware AirWatch environments that reduces the workload on the database. Memcached replaces the previous caching solution, AW Cache, and is recommended for deployments of more than 5,000 devices.

Once enabled in the AirWatch Console, Memcached begins storing system setting values and organization group tree information as they are accessed by VMware AirWatch components. When a request for data is sent, VMWare AirWatch automatically checks for the results stored in memory by Memcached before checking the database, thereby reducing the database workload. If this process fails, results data is retrieved from the database and stored in Memcached for future queries. As new values are added and existing values are changed, the values are written to both Memcached and the database.

Note that all key/value pairs in Memcached expire after 24 hours.

You can deploy multiple Memcached servers, with each caching a portion of the data, to mitigate against a single server failure degrading the service. With two servers, 50 percent of the data resides on server 1 and 50 percent on server 2, with no replication across servers. A hash table tells the services what data is stored on which server.

If server 1 experiences an outage for any reason, only 50 percent of the cache is impacted. The tables would be rebuilt on the second server as services failover to the database and look to cache those gathered items.

For recommendations on hardware sizing of Memcached servers, see On-Premises Architecture Hardware Assumptions in the Architecture section of the AirWatch Documentation.

Load Balancing

To remove a single point of failure, you can deploy more than one instance of the different VMware AirWatch components behind an external load balancer. This strategy not only provides redundancy but also allows the load and processing to be spread across multiple instances of the component. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for setup of multiple nodes in a high-availability (HA) or master/slave configuration.

The AirWatch Cloud Connector traffic is load-balanced by the AirWatch Cloud Messaging component. It does not require a separate load balancer. Multiple AirWatch Cloud Connectors in the same organization group that connect to the same cloud messaging server for high availability can all expect to receive traffic (an active-active configuration). How traffic is routed is determined by the component and depends on the current load.

Configure the VMware Identity Manager connector for failover and redundancy by deploying multiple connector instances in a connector cluster that is fronted by a load balancer. If one of the instances shuts down, the connector is still available. A load balancer is required only in situations where an inbound connection to the connector is needed, mainly if Kerberos authentication is required.

To set up failover, install and configure the first connector instance, create a directory that uses it as the identity provider, and add the connector to the load balancer. Then deploy additional connector instances and associate them with the Identity Provider page of the first connector before adding them to the load balancer. As a result, multiple connector instances are all associated with the same directory.

After setting up failover, the connector is highly available. Traffic is distributed to the connector instances in the cluster based on the load-balancer configuration. Specifically, authentication is highly available. If one of the connector instances shuts down, authentication is still available because one of the other connector instances is used. For directory sync, however, in the event of a connector instance failure, you need to manually select another connector instance as the sync connector, because directory sync can be enabled on only one connector at a time.

For more information, see Configuring High Availability for the Identity Manager Connector in VMware Enterprise Systems Connector Installation and Configuration.

For more information on load balancing recommendations for the different VMware AirWatch components, see On-Premises Architecture Load Balancer Considerations in the Architecture section of the AirWatch Documentation.

Scalability and Availability

VMware AirWatch core components can be deployed in a single, shared server design, but this is only really recommended for proof of concept engagements. For production use, to satisfy load demands and to meet most network architecture designs, the core application components are usually installed on two separate, dedicated servers (Admin Console and Device Services).

For a high-availability environment and to meet load demands of large deployments, multiple instances of each one of these components can be deployed on dedicated servers behind a load balancer.

In larger environments, which generally include more than 50,000 devices, the API and AWCM services should also be located on separate, dedicated servers to remove their load from the Device Services and Admin Console servers.

Multiple instances of the Enterprise Systems Connector or ACC can be deployed in the internal network for a high-availability environment. The load for this service is balanced without the need for an external load balancer.

VMware AirWatch can be scaled horizontally to meet demands regardless of the number of devices. For server numbers, hardware sizing, and recommended architectures for deployments of varying sizes, see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation. Note that the guide shows only the number of application server components required for each sizing scenario to cope with the load demand. It does not include additional servers in those numbers to account for redundancy.

Due to the amount of data flowing in and out of the AirWatch database, proper sizing of the database server is crucial to a successful deployment. For guidance on sizing the database server resources, CPU, RAM, and disk IO requirements, see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

This reference architecture is designed to accommodate up to 50,000 devices. Multiple nodes of each of the components (Device Services, Admin Consoles, AirWatch Cloud, Enterprise Systems Connectors) are recommended to meet the demand. To guarantee the resilience of each service within a single site, additional application servers are added. For example, four Device Services nodes are used instead of the three that would be required to meet only the load demand.

Design Decisions:

  • Four instances of the VMware AirWatch Device Services servers are deployed in the DMZ. Three are required to handle the load and a fourth is added for redundancy. These servers include the following components:
    • VMware AirWatch Device Services
    • VMware AirWatch Cloud Messaging service
  • Three instances of the VMware AirWatch Admin Console server are installed in the internal network. Two are required based on load and a third is added for redundancy. These servers include the following components:
    • VMware AirWatch Admin Console
    • VMware AirWatch API Server
  • Three instances of the VMware Enterprise Systems Connector are deployed in the internal network. Two are required based on load and a third is added for redundancy.
  • Two Memcached servers are installed in the internal network to reduce load on the SQL database.

Scaled and Load Balanced VMware AirWatch Components

Figure 31: Scaled and Load Balanced VMware AirWatch Components

This figure shows a scaled environment suitable for up to 50,000 devices.

  • AirWatch Devices Services servers are located in the DMZ, and a load balancer distributes the load.
  • AirWatch Admin Console Services servers are hosted in the internal network with a load balancer in front of them.
  • VMware Enterprise Systems Connector servers are hosted in the internal network and can use an outbound-only connection without the need for an external load balancer.

For this reference architecture, split DNS was used; that is, the same fully qualified domain name (FQDN) is used both internally and externally for user access to the AirWatch Device Services server. Split DNS is not a strict requirement for a VMware AirWatch on-premises deployment but does improve the user experience.

Multi-site Design

VMware AirWatch servers are the primary endpoint for management and provisioning of end user devices. These servers should be deployed to be highly available within a site and deployed in a secondary data center for failover and redundancy. A robust back-up policy for application servers and database servers can minimize the steps required for restoring a VMware AirWatch environment in another location.

You can configure disaster recovery (DR) for your VMware AirWatch solution using whatever procedures and methods meet your DR policies. VMWare AirWatch has no dependency on your DR configuration, but we strongly recommend you have some type of failover procedures for DR scenarios. VMWare AirWatch components can be deployed to accommodate most of the typical disaster recovery scenarios.

VMware AirWatch consists of the following core components that make up the service and need to be designed for redundancy:

  • VMware AirWatch Device Services
  • VMware AirWatch Admin Console
  • VMware Enterprise Systems Connector
  • VMware AirWatch Memcached
  • SQL database server

VMware AirWatch Application Servers and Enterprise Systems Connectors

To provide site resilience, each site requires its own group of VMware AirWatch application and connector servers to allow the site to operate independently without reliance on another site. One site runs as an active deployment, while the other has a passive deployment.

Within each site, sufficient application servers must be installed to provide local redundancy and withstand the load on its own. The Device Services servers are hosted in the DMZ, while the Admin Console server resides in the internal network. Each site has a local load balancer that distributes the load between the local Device Services servers, and a failure of an individual server is handled with no outage to the service or requirement to fail over to the backup site.

A global load balancer is used in front of each site’s load balancer.

At each site, Enterprise System Connector servers are hosted in the internal network and can use an outbound-only connection.

For recommendations on server quantities and hardware sizing of Device Services and Admin Console servers, see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

Multi-site Database

As previously stated, VMware AirWatch supports Microsoft SQL Server 2012 (and later) and its cluster offering Always On availability groups. This allows the deployment of multiple instances of Device Services and AirWatch Console servers pointing to the same database protected by an availability group, with an availability group listener as the single database connection target for all instances.

For this design an active/passive database instance is configured using SQL Server Always On. This allows the failover to the secondary site if the primary site is unavailable. Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic, though not instantaneous.

An Always On implementation with the following specifications was chosen:

  • No shared disks are used.
  • The primary database instance is running in Site 1 during normal production.

Within a site, Windows Server Failover Clustering (WSFC) is used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic. For details of the implementation we used, see Appendix G: VMware AirWatch Configuration for Multi-site Deployments.

Failover to a Second Site

A VMware AirWatch multi-site design allows administrators to maintain constant availability of the different AirWatch services in case a disaster renders the original active site unavailable.

The following diagram shows a sample multi-site architecture.

Multi-site AirWatch Architecture

Figure 32: Multi-site AirWatch Architecture

To achieve failover to a secondary site, manual intervention might be required for two main layers of the solution:

  • Database - Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic. If necessary, steps should be taken to manually control which site has the active SQL node.
  • Device Services - The global load balancer controls which site it directs traffic to. During normal operation it directs traffic to the local load balancer in front of the Device Service Servers in Site 1. In a failover the global load balancer should be changed to direct traffic to the equivalent local load balancer in Site 2.

Prerequisites

This section details the prerequisites for the VMware AirWatch configuration:

  • Network Configuration – Verify that the following requirements are met:
    • Static IP address and DNS Forward (A) are used.
    • Inbound firewall port 443 is open so that external users can connect to the VMware AirWatch instance or the load balancer.
  • Active Directory – VMware AirWatch supports Active Directory configurations on Windows 2008 R2, 2012, 2012 R2, and 2016, including:
    • Single AD domain
    • Multidomain, single forest
    • Multi-forest with trust relationships
    • Multi-forest with untrusted relationships (requires external connector configuration)
    • Active Directory Global Catalog optional for Directory Sync

For this reference architecture, Windows 2016 Active Directory was used.

Installation and Initial Configuration

VMware AirWatch is delivered as separate installer for the database and application servers. The database installer must be run before installing any of the application servers. For more information on installing VMware AirWatch see the VMware AirWatch Installation Guide.

At a high level, the following tasks should be completed:

  • Database:
    • Create the AirWatch Database.
    • Run the AirWatch Database Installer.
  • Application Servers (Console and Device Services):
    • Run the Application Installer on each application server.
    • Select the appropriate services for the component you are installing.
  • Install and configure the Memcached servers.
  • Install the Enterprise System Connector.
  • Configure Active Directory:
    • Create a connection to Active Directory.
    • Select a bind account with permission to read from AD.
    • Choose groups and users to sync.
    • Initiate a directory sync.
  • Set up Apple Push Notification service (APNs) for iOS devices and a notification service for Android.

Integration with VMware Identity Manager

You must integrate VMware AirWatch and VMware Identity Manager in Workspace ONE for several reasons. Workspace ONE uses VMware Identity Manager for authentication and SaaS and VMware Horizon application access. Workspace ONE uses VMware AirWatch for device enrollment and management. The integration process between the two solutions is detailed in Integrating AirWatch with VMware Identity Manager in Guide to Deploying VMware Workspace ONE

Resource Types: Apps and Desktops

A Workspace ONE implementation can include many types of applications used in the enterprise.

SaaS Apps

SaaS apps include hosted apps such as Concur, Salesforce, or other cloud-based applications that are often authenticated through standards such as SAML or WSFed to provide an SSO experience for end users. Often browser-based, these applications are published through VMware Identity Manager. The cloud application catalog in VMware Identity Manager includes templates with many preconfigured parameters to make federating with the SaaS provider easier. For other providers, if a template is not included, a wizard guides you through configuring the app and entitling users.

Administrator Adding a New SaaS Application to the Catalog

Figure 33: Administrator Adding a New SaaS Application to the Catalog

Cloud Application Catalog for End Users

Figure 34: Cloud Application Catalog for End Users

ThinApp-Packaged Apps

ThinApp is a Windows application virtualization solution that can accelerate deployment by isolating applications from the underlying operating system to eliminate application conflict. The apps are packaged for distribution from file shares in the enterprise. In a Workspace ONE implementation, they can be published to Windows-based systems through VMware Identity Manager and deployed to physical or virtual machines. The VMware Identity Manager Connector must be deployed to enable using ThinApp apps in a Workspace ONE deployment.

VMware Horizon Apps and Desktops

The capability to deliver virtual apps and desktops continues to be a significant value for Workspace ONE users. VMware Identity Manager can be integrated with a VMware Horizon implementation to expose the entitled apps and desktops to end users. Through Horizon Client for native mobile platforms, access to these resources can be easily extended to mobile devices.

You must deploy the VMware Identity Manager Connector to provide access to Horizon 7 resources from the VMware Identity Manager cloud-hosted service. The connector enables you to sync entitlements to the service. It requires a means of accessing the resources from the Internet, such as VMware Unified Access Gateway.

Virtual Application Configuration

Figure 35: Virtual Application Configuration

Native Mobile Apps

Native mobile apps from the Apple App Store, Google Play, and the Microsoft Windows Store have brought about new ways of easily accessing tools and information to make users more productive. A challenge has been making the available apps easy to find, install, and control. VMware AirWatch has long provided a platform for distribution, management, and security of these apps. Apps can be published from the app stores themselves or, for internally developed apps, they can be uploaded to the VMware AirWatch service for distribution to end users.

VMware Native Mobile Apps

Figure 36: VMware Native Mobile Apps

Unified App Catalog

When VMware AirWatch and VMware Identity Manager are integrated so that apps from both platforms can be enabled for end users, the option to use the Unified Catalog in VMware Identity Manager is enabled. This catalog pulls entitlements from both platforms and displays them appropriately in the Workspace ONE native app on a mobile device. The Workspace ONE client determines which apps to display on which platform. For example, iOS apps appear only on devices running iOS, and Android apps appear only on Android devices. 

Unified Catalog in VMware Identity Manager

Figure 37: Unified Catalog in VMware Identity Manager

Conditional Access

With the Workspace ONE conditional access feature, administrators can create access policies that go beyond the evaluation of user identity and valid credentials. Combining VMware AirWatch and VMware Identity Manager, administrators can evaluate the target resource being accessed, the source network from which the request originated, and the type and compliance status of the device. With these criteria, access policies can provide a more sophisticated authentication challenge only when needed or deny access when secure conditions are not met.

Using the AirWatch Console to Create Access Policies

Configuration of compliance starts in the AirWatch Console. Compliance policies are created by determining a criterion to check, such as a jail-broken or rooted device, an action to take, such as an email to an administrator or a device wipe, an escalation to further actions if the device is not returned to compliance within a set time, and an assignment to devices or users. Examples of rules are listed in the following table.

 

Compliance Policy

Description

Application Lists

A device is out of compliance with the policy for one or more of the following reasons:

  • Blacklisted apps are installed on the device.
  • Non-whitelisted apps are installed on the device.
  • Required apps are not installed.
  • The version of the installed app is different from the one defined in the policy.

Last Compromised Scan

A device complies with this policy if the last compromised scan occurred within the timeframe defined in the policy.

Passcode

A device complies with this policy if a passcode is set in the device by the user. The corresponding rule provides information on the passcode and encryption status of the device.

Device roaming

A device is out of compliance with this policy if the device is roaming.

Copy of Windows

A device complies with this policy if the Windows OS installed in the device is genuine.

Antivirus

If this policy is assigned to a device, the compliance status of the device depends on the usage of the antivirus application installed in the device.

Roaming Cell Data Usage

This policy, when assigned to a device, checks the device’s data usage when it is in roaming.

Free Disk Space

This policy, when assigned to a device, checks and restricts the devices disk space usage.

SIM Card Change

A device is out of compliance with this policy if the SIM card is changed.

Device Model and OS Version

A device complies with this policy if the model and OS of the device meet the condition that is defined in the policy. The corresponding rule provides information on the OS version, model, IMEI number, model number, and capacity of the device.

Device Compromised Status

A device complies with this policy if the status (compromised or not compromised) of the device meets the condition that is defined in the policy. The policy runs again if the beacon compromised status is different (changes from jail-broken to not, or the reverse).

Interactive Certificate Profile Expiry

A device is out of compliance with this policy if the interactive certificate profile expires within the number of days defined in the policy. The corresponding sample gives information about the certificates.

Device Last Check-In

A device complies with this policy if it has checked in at least once within the number of hours or days set by the administrator. The policy runs based on the scheduler and not on the rules.

MDM EULA Acceptance

A device complies with this policy if the user accepts the EULA. The policy runs based on the scheduler and does not depend on the rules.

NA

This rule provides information about the profiles installed in the device. It does not impact any compliance policies.

Firewall Status

A device is out of compliance with this policy if the firewall is disabled.

Automatic Updates

A device is out of compliance with this policy if automatic updates are disabled.

Laptop Encryption

A device is out of compliance with this policy if the device is not encrypted.

Table 18: Access Policy Rules

Using the AirWatch REST API to Extend Device Compliance Parameters

With the AirWatch REST API, the definition of a device’s compliance status can be extended beyond what is available within the AirWatch Console by leveraging an integration with one or more partners from the extensive list of VMware Mobile Security Alliance (MSA) partners. For more information, see Mitigate Mobile Threats with Best-of-Breed Security Solutions.

To use the device posture from VMware AirWatch with VMware Identity Manager, you must enable the Device Compliance option when configuring the AirWatch-VMware Identity Manager integration. The Compliance Check (with AirWatch) function must also be enabled.

Enable Compliance Check and Authentication Through AirWatch

Figure 38: Enable Compliance Check and Authentication Through AirWatch

After you enable the compliance check and authentication through VMware AirWatch, you can add a rule that defines what kind of compliance parameters are checked and what kind of authentication methods are used.

Device Compliance Policy

Figure 39: Device Compliance Policy

The device’s universally unique identifier (UDID) must also be captured in VMware AirWatch and used in compliance configuration. This feature works with mobile SSO for iOS, mobile SSO for Android, and certificate cloud deployment authentication methods.

Note: Before you use the Device Compliance authentication method, you must use a method that obtains the device UDID. Evaluating device compliance before obtaining the UDID does not result in a positive validation of the device’s status.

Multifactor Authentication

VMware Identity Manager supports chained, two-factor authentication. The primary authentication methods can be username and password or mobile SSO. You can combine these authentication methods with RADIUS, RSA Adaptive Authentication, and VMware Verify as secondary authentication methods to achieve additional security for access control.

Standalone MAM and Adaptive Management

Workspace ONE supports a variety of device and application management approaches. Standalone mobile application management (MAM) allows a user to download the Workspace ONE app from public app stores and immediately take advantage of entitled apps and corporate-published native mobile apps. The benefits of this approach include:

  • IT can distribute corporate-approved public mobile apps to unmanaged devices through the Workspace ONE app catalog.
  • With the Workspace ONE app installed, users can use SSO to access other VMware apps, including AirWatch Browser and AirWatch Content Locker, or any custom app built using the AirWatch SDK.
  • When an unmanaged device is out of compliance (for example, jail-broken), the system quickly takes action to protect company data. When a violation is detected, all company data is removed from the Workspace ONE app, AirWatch productivity apps (for example, AirWatch Content Locker), and any custom app built using the AirWatch SDK.

Triggering the Enrollment Process from the Workspace ONE App

For apps that require a higher level of security assurance, users can enroll their device in VMware AirWatch directly from the Workspace ONE app, instead of downloading VMware AirWatch® Agent™. All entitled apps are listed in the catalog. Apps that require enrollment are marked with a lock icon. When the user tries to download an app with a­ lock icon, the enrollment process is triggered. For example, users can download a conferencing app, such as WebEx, without enrollment. But they are prompted to enroll when they try to download, for example, Salesforce1, from the catalog.

Adaptive Management

Figure 40: Adaptive Management

Enabling Adaptive Management

Enabling adaptive management is done on an application-by-application basis within the AirWatch Console. Within an application profile, an administrator can choose to require management of a device prior to allowing use of that app.

AirWatch Application Deployment

Figure 41: AirWatch Application Deployment for Adaptive Management

Mobile Single Sign-On

One of the hallmark features of the Workspace ONE experience is mobile SSO technology, which provides the ability to sign in to the app once and gain access to all entitled applications, including SaaS apps. This core capability can help address security concerns and password-cracking attempts and vastly simplifies the end-user experience for a mobile user. A number of methods enable this capability on both VMware Identity Manager and VMware AirWatch. SAML becomes a bridge to the apps, but each native mobile platform requires different technologies to enable SSO.

iOS SSO

Kerberos-based SSO is the recommended SSO experience on managed iOS devices. VMware Identity Manager offers a built-in Kerberos adapter, which can handle iOS authentication without the need for device communication to your internal Active Directory servers. In addition, AirWatch can distribute identity certificates to devices, eliminating the requirement to maintain an on-premises certificate authority (CA).

Alternatively, enterprises can use an internal key distribution center (KDC) for SSO authentication, but this typically requires the provisioning of an on-demand VPN. Either option can be configured in the Standard Deployment model, but the built-in KDC must be used in the Simplified Deployment model that is referenced in the VMware Workspace ONE Quick Start Guide.

Mobile SSO for Android

Workspace ONE offers universal Android mobile SSO, which allows users to sign in to enterprise apps securely without a password. Android mobile SSO technology requires the use of VMware AirWatch® Tunnel™ to authenticate users against SaaS applications.

Windows 10 SSO

Certificate-based SSO is the recommended experience for managed Windows desktops and laptops. An Active Directory Certificate Services or other CA is required to distribute certificates. VMware AirWatch can integrate with an on-premises CA through AirWatch Cloud Connector or an on-demand VPN.

Configuration of mobile SSO for iOS, Android, and Windows 10 devices can be found in the VMware Workspace ONE Quick Start Guide.

Email Integration

Workspace ONE offers a great number of choices when it comes to devices and email clients. Although this flexibility allows a user to choose the email client they prefer, it also potentially exposes the enterprise to data leakage due to a lack of control after email messages reach the device. To address these considerations, VMware AirWatch supports multiple methods of connecting devices to an email infrastructure.

One challenge is that many organizations are moving to cloud-based email services, such as Microsoft Office 365 and G Suite (formerly Google Apps for Work). These services provide fewer email control options than the on-premises models that the enterprise has worked with. Previously, AirWatch Secure Email Gateway was deployed inside a corporate firewall and handled many aspects of secure email delivery to devices. 

This section looks at the connectivity models and the pros and cons of each.

AirWatch Secure Email Gateway Proxy Model

The AirWatch Secure Email Gateway proxy server is a separate server installed in-line with your existing email server to proxy all email traffic going to mobile devices. Based on the settings you define in the AirWatch Console, the AirWatch Secure Email Gateway proxy server allows or blocks email for every mobile device it manages, and it relays traffic only from approved devices. No devices are allowed to communicate directly with the corporate email server.

AirWatch Secure Email Gateway Architectures

Figure 42: AirWatch Secure Email Gateway Architectures

Direct PowerShell Model

In this model, VMware AirWatch adopts a PowerShell administrator role and issues commands to the Exchange ActiveSync infrastructure to permit or deny email access based on the policies defined in the AirWatch Console. PowerShell deployments do not require a separate email proxy server, and the installation process is simpler.

Microsoft Office 365 Email Architecture

Figure 43: Microsoft Office 365 Email Architecture

Supported Email Infrastructure and Models

Use the following table to compare these models and the mail infrastructures they support.

Deployment Model

Configuration Mode

Mail Infrastructure

Proxy model

AirWatch Secure Email Gateway (proxy)

Microsoft Exchange 2010, 2013, and 2016

IBM Domino with Lotus Notes

Novel GroupWise (with EAS)

Google Apps for Work

Direct model

PowerShell model

Microsoft Exchange 2010, 2013, and 2016

Microsoft Office 365

Direct model

Google model

Google Apps for Work

Table 19: Supported Email Deployment Models

Microsoft Office 365 requires additional configuration for the AirWatch Secure Email Gateway proxy model. AirWatch recommends the direct model of integration with cloud-based email servers.

The following table summarizes the pros and cons of the deployment features of AirWatch Secure Email Gateway and PowerShell to help you choose which deployment is most appropriate.

 

Pros

Cons

AirWatch Secure Email Gateway

Real-time compliance

Attachment encryption

Hyperlink transformation

Additional servers needed

Office 365 must be federated with Workspace ONE to prevent users from directly connecting to Office 365

PowerShell

No additional on-premises servers required for email management

 

No real-time compliance sync

Not recommended for deployments larger than 100,000 devices

VMware Boxer required to containerize attachments and hyperlinks in AirWatch Content Locker and AirWatch Browser

Table 20: AirWatch Secure Email Gateway and PowerShell Feature Comparison

Key Design Considerations

VMware recommends using AirWatch Secure Email Gateway for all on-premises email infrastructures with deployments of more than 100,000 devices. For smaller deployments or cloud-based email, PowerShell is another option.

For more information on design considerations for mobile email management, see the most recent VMware AirWatch Mobile Email Management Guide in AirWatch Resources.

Design Decision: Because this design includes Microsoft Office 365 email, the PowerShell model is used with VMware Boxer. Although this decision limits employee choice of mail client and removes native email access in the Mobile Productivity service, it provides the best protection available against data leakage.

Next Steps

  • Configure Microsoft Office 365 email through PowerShell.
  • Configure VMware Boxer as an email client for deployment as part of device enrollment.

Conditional Access Configured for Microsoft Office 365 Basic Authentication

By default, Microsoft Office 365 basic authentication is vulnerable because credentials are entered in the app itself rather than being submitted to an identity provider (IdP) in a browser, as with modern authentication. However, with Workspace ONE, you can easily enhance the security and control over Microsoft Office 365 with an active flow.

You can now control access to Office 365 active flows based on the following access policies in VMware Identity Manager:

  • Network range
  • Device OS type
  • Group membership
  • Email protocol
  • Client name

Office 365 in Workspace One

Microsoft Office 365 Active Flow Conditional Access Policies

Figure 44: Microsoft Office 365 Active Flow Conditional Access Policies

Content Integration

Mobile content management (MCM) can be critical to device deployment, ensuring that content is safely stored in enterprise repositories and available to end users when and where they need it with the appropriate security controls. The MCM features found in AirWatch provide users with the content they need while also providing the enterprise with the security control it requires.

Content Management Overview

  1. AirWatch-managed content repository – VMware AirWatch administrators with the appropriate permissions can upload content to the repository and have complete control over the files that are stored in it. 
  2. The synchronization process involves two components:
    • AirWatch Content Gateway – This node provides secure access to content repositories or internal file shares. You can deploy it as a service on VMware Unified Access Gateway virtual appliance or use a standalone installer.
    • Corporate file server – This pre-existing repository can reside within an organization’s internal network or on a cloud service. Depending on an organization’s structure, the VMware AirWatch administrator might not have administrative permissions for the corporate file server.
  3. AirWatch Content Locker – After this app is deployed to end-user devices, users can access content that conforms to the configured set of parameters.
  4. Personal content repository – End users have complete control over the files stored here. End users can add files on their devices from any supported web browser through the Self-Service Portal in AirWatch Content Locker, and from their personal computer through AirWatch Content Locker Sync.

Mobile Content Management with VMware AirWatch

Figure 45: Mobile Content Management with VMware AirWatch

You can integrate AirWatch Content Locker with a large number of corporate file services, including Box, Google Drive, network shares, various Microsoft services, and most websites that support Web Distributed Authoring and Versioning (WebDAV). It is beyond the scope of this document to list all of them.

For full design considerations for mobile content management, see the most recent VMware AirWatch Mobile Content Management Guide in AirWatch Resources.

Data Protection in AirWatch Content Locker

AirWatch Content Locker provides a considerable amount of control over the types of activities that a user can perform with documents that have been synced to a mobile device. Applications must be developed using AirWatch Software Development Kit (SDK) features or must be wrapped to use these restrictions. The following table lists the data loss prevention features that can be controlled.

 

Feature Name

Description

Enable Copy and Paste

Allows an application to copy and paste on devices

Enable Printing

Allows an application to print from devices

Enable Camera

Allows applications to access the device camera

Enable Composing Email

Allows an application to use the native email client to send email

Enable Data Backup

Allows wrapped applications to sync data with a storage service such as iCloud

Enable Location Services

Allows wrapped applications to receive the latitude and longitude of the device

Enable Bluetooth

Allows applications to access Bluetooth functionality on devices

Enable Screenshot

Allows applications to access screenshot functionality on devices

Enable Watermark

Displays text in a watermark in documents in the AirWatch Content Locker

Limit Documents to Open Only in Approved Apps

Controls the applications used to open resources on devices

Allowed Applications List

Lists the applications that are allowed to open documents

Table 21: Data Loss Prevention Features

Content Gateway

Content Gateway provides a secure and effective method for end users to access internal repositories. Users are granted access only to their approved files and folders based on the access control lists defined in your internal repository through AirWatch Content Locker. To prevent security vulnerabilities, Content Gateway servers support only Server Message Block (SMB) v2.0 and SMBv3.0. SMBv2.0 is the default. Content Gateway offers basic and relay-endpoint architecture models for deployment.

Content Gateway can be deployed as a standalone Windows or Linux service, or as a service within VMware Unified Access Gateway 3.1 and later. For more information, see Content Gateway on Unified Access Gateway in Deploying and Configuration VMware Unified Access Gateway.

Key Design Considerations

Because this environment is configured with Microsoft Office 365, SharePoint-based document repositories are configured as part of the AirWatch Content Locker implementation. DLP controls are used in the Mobile Productivity service and Mobile Application Workspace profiles to protect corporate information.

In this reference architecture, Unified Access Gateway is used to provide Content Gateway services. Unified Access Gateway is chosen as the standard edge gateway appliance for Workspace ONE services, including VMware Horizon and content resources.

Data Loss Prevention

Apps that have been built for VMware AirWatch deployment can take advantage of app wrapping, which applies policies to a mobile app without changing the app itself. The app can also take advantage of controls designed to make accidental, or even purposeful, distribution of sensitive information more difficult. DLP settings include the ability to disable copy and paste, prevent printing, disable the camera or screenshot features, or require adding a watermark to content when viewed on a device. You can configure these features on a platform level with iOS- or Android-specific profiles applied to all devices, or you can associate a specific application for which additional control is required.

VMware AirWatch applications, including VMware Boxer, AirWatch Content Locker, and AirWatch Browser, are built to the AirWatch SDK, conform to the AirWatch platform, and can natively take advantage of these capabilities. Other applications can be wrapped to include such functionality, but typically are not enabled for it out of the box.

AirWatch Data Loss Prevention Settings

Figure 46: AirWatch Data Loss Prevention Settings

Another set of policies can restrict actions a user can take with email. For managed email clients such as VMware Boxer, restrictions can be set to govern copy and paste, prevent attachments from being accessed, or force all hyperlinks in email to use a secure browser, such as AirWatch Browser.

VMware Boxer Content Restriction Settings

Figure 47: VMware Boxer Content Restriction Settings

Component Design: VMware Identity Manager Architecture

VMware Identity Manager is a key component of VMware Workspace ONE. Among the capabilities of VMware Identity Manager are:

  • Workspace ONE native mobile apps  Includes native apps for iOS, Android, and Windows 10 that present a unified application catalog across VMware Identity Manager resources and native mobile apps, simplify finding and installing enterprise apps, and provide an SSO experience across resource types.
  • Simple application access for end users – Provides access to different types of applications, including SaaS-based web applications (such as Salesforce, Dropbox, Concur, and many others), Horizon 7–based applications and desktops, RDSH-published applications and desktops, ThinApp apps, and Citrix-based applications and desktops.
  • Self-service app store – Allows end users to search for and select entitled applications in a simple way, while providing enterprise security and compliance controls to ensure that the right users have access to the right applications.
  • Enterprise single sign-on – Simplifies business mobility with an included identity provider (IdP) or integration with existing on-premises identity providers so that you can aggregate SaaS, native mobile, and Windows 10 apps into a single catalog. Users have a single identity regardless of whether they log in to an internal, external, or virtual-based application.
  • Enterprise identity management with adaptive access – Establishes trust between users, devices, and the hybrid cloud for a seamless user experience and powerful conditional access controls that leverage VMware AirWatch device enrollment and SSO adaptors.
  • Conditional access – Includes an access policy option to check the VMware AirWatch server for device compliance when users sign in. Users are blocked from signing in to an application or using SSO to the app catalog until the device becomes compliant.
    You can enforce these actions based on the network users are on, the platform they are using, or the applications being accessed. In addition to checking VMware AirWatch for device compliance, VMware Identity Manager can evaluate compliance based on IP address range, type of device, operating system, and credentials.
  • A wealth of resource types – Delivers SaaS-based SAML apps, VMware Horizon apps and desktops, and ThinApp-packaged apps to the unified Workspace ONE app catalog. (Native mobile apps are delivered through the VMware AirWatch.)

User Workspace Delivered by VMware Identity Manager

Figure 48: User Workspace Delivered by VMware Identity Manager

Design Overview

VMware Identity Manager can be implemented using on-premises or SaaS-based implementation models.

In a SaaS-based implementation, a VMware Identity Manager Connector virtual appliance synchronizes user accounts from Active Directory to the VMware Identity Manager service. Applications can then be accessed from a cloud-based entry point.

In an on-premises deployment, VMware Identity Manager is available as either a Linux-based virtual appliance or as a service installed in a Windows VM. The Windows-based installer is a component of the VMware Enterprise Systems Connector, which also contains the AirWatch Cloud Connector (ACC). For this reference architecture, we used the Linux-based virtual appliance.

VMware Identity Manager can also be integrated with the rest of the Horizon 7 Enterprise components to provide access to Horizon 7 desktops and published applications. The VMware Identity Manager VM handles authentication and provides SSO services to applications and desktops.

Syncing resources such as Active Directory and Horizon 7 and can be done either by using a separate VMware Identity Manager Connector or by using the built-in connector of an on-premises VMware Identity Manager VM. The separate connector can run inside the LAN in outbound-only connection mode, meaning the connector receives no incoming connections from the DMZ.

VMware Identity Manager Logical Design

Figure 49: VMware Identity Manager Logical Design

The main components of Identity Manager on-premises are:

  • VMware Identity Manager appliance – Runs the main VMware Identity Manager service.
  • VMware Identity Manager Connector – Responsible for directory sync and authentication between on-premises resources such as Active Directory, Horizon 7, and the VMware Identity Manager service. You can deploy the connector as a Linux-based virtual appliance or by running the Windows-based installer included in the Enterprise Systems Connector.

Design Decision: Although both the on-premises and the SaaS implementations could deliver the required capabilities, in this reference architecture, an on-premises VMware Identity Manager design is used. Separate VMware Identity Manager connectors are also used.

Database

VMware Identity Manager can be set up with an internal or external database to store and organize server data. A PostgreSQL database is embedded in the VMware Identity Manager virtual appliance, but this internal database is not recommended for use with production deployments.

To use an external database, have your database administrator prepare an empty external database and schema before you use the VMware Identity Manager Setup wizard to connect to the external database. Licensed users can use an external Microsoft SQL Server 2012, 2014, or 2016 database server to set up a high-availability external database environment. For more information, see Configure VMware Identity Manager to Use an External Database in Installing and Configuring VMware Identity Manager.

The database requires 64 GB of disk space for the first 100,000 users, and another 20 GB for each additional 10,000 users. For guidance on hardware sizing for Microsoft SQL Servers, see System and Network Configuration Requirements in Installing and Configuring VMware Identity Manager.

Design Decision: To make our configuration match that of most enterprises, an external Microsoft SQL database is implemented.

Scalability and Availability

VMware Identity Manager has been tested to 100,000 users per single virtual appliance installation. For a high-availability environment, at least three VMware Identity Manager appliances should be configured to ensure availability in the event of a failure of an appliance or ESXi host. After initial configuration, the virtual appliance is cloned twice and deployed with new IP addresses and host names.

In this reference architecture, Microsoft SQL Server 2016 was used along with its cluster offering Always On availability groups, which is supported with VMware Identity Manager. This allows the deployment of multiple instances of VMware Identity Manager, pointing to the same database protected by an availability group with an availability group listener as the single Java Database Connectivity (JDBC) target for all instances.

Windows Server Failover Clustering (WSFC) can also be used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic.

VMware Identity Manager Availability

Figure 50: VMware Identity Manager Availability

For more information on how to set up VMware Identity Manager in a high-availability configuration, see Configuring Failover and Redundancy in Installing and Configuring VMware Identity Manager.

For guidance on server quantities and hardware sizing of VMware Identity Manager servers and VMware Identity Manager Connectors, see System and Network Configuration Requirements in Installing and Configuring VMware Identity Manager.

Design Decisions:

To provide high availability,

  • Three VMware Identity Manager 3.x appliances are deployed in the DMZ.
  • Two VMware Identity Manager 3.x Connectors are deployed inside the corporate LAN, configured to use an outbound-only connection mode.
  • An external SQL Server 2016 database server is installed on a two-node Windows Server Failover Cluster, which uses a SQL Server Always On availability group.

Load Balancing

To remove a single point of failure, we can deploy more than one instance and use a third-party load balancer. This strategy not only provides redundancy but also allows the load and processing to be spread across multiple instances of the component. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for setup of multiple nodes in an HA or master/slave configuration.

The following figure illustrates how load balancers distribute the load to a cluster of VMware Identity Manager appliances in the DMZ. VMware Identity Manager Connector virtual appliances are hosted in the internal network and use an outbound-only connection mode.

VMware Identity Manager Load Balancing and External Access

Figure 51: VMware Identity Manager Load Balancing and External Access

Split DNS is a requirement for VMware Identity Manager; that is, the same fully qualified domain name (FQDN) for VMware Identity Manager must be used both internally and externally for user access.

See Deploying the VMware Identity Manager Machine Behind a Load Balancer in Installing and Configuring VMware Identity Manager.

Multi-site Design

VMware Identity Manager is the primary entry point for end users to consume all types of applications, including SaaS, web, Horizon 7 virtual desktops and published applications, Citrix XenApp, and mobile apps. Therefore, it should be deployed to be highly available within a site, and also deployed in a secondary data center for failover and redundancy.

The failover process that makes the secondary site’s VMware Identity Manager appliances active requires a change at the global load balancer to direct traffic of the namespace to the desired instance. You must also clear the caches on the original primary data center, as described in the topic Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

VMware Identity Manger consists of the following layers, which make up the service and need to be designed for redundancy:

  • VMware Identity Manger appliances and connectors
  • Database
  • Unified app catalog that can contain SaaS, web, Horizon 7 published applications, Horizon 7 virtual desktops, Citrix XenApp, and mobile apps

VMware Identity Manager Appliances and Connectors

To provide site resilience, each site requires its own group of VMware Identity Manager virtual appliances to allow the site to operate independently, without reliance on another site. One site runs as the active VMware Identity Manager, while the second site has a passive group. The determination of which site has the active VMware Identity Manager is usually controlled by the global load balancer’s namespace entry or a DNS entry, which sets a given instance as the target for the namespace in use by users.

Within each site, VMware Identity Manager must be installed with a minimum of three appliances. This provides local redundancy and ensures that services such as Elasticsearch function properly. The VMware Identity Manager appliances are hosted in the DMZ network. For more information, see Deploying VMware Identity Manager in the DMZ.

A local load balancer distributes the load between the local VMware Identity Manager instances, and a failure of an individual appliance is handled with no outage to the service. Each local site load balancer is also load-balanced with a global load balancer.

At each site, two VMware Identity Manager Connector virtual appliances are hosted in the internal network and can use an outbound-only connection mode. These connectors point to the global load balancer.

Multi-site Database

VMware Identity Manager 2.9 (and later) supports Microsoft SQL Server 2012 (and later) and its cluster offering Always On availability groups. This allows us to deploy multiple instances of VMware Identity Manager, pointing to the same database protected by an availability group with an availability group listener as the single Java Database Connectivity (JDBC) target for all instances.

VMware Identity Manager is supported with an active/passive database instance with failover to the secondary site if the primary site is unavailable. Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic, though not instantaneous.

For this design, an Always On implementation with the following specifications was chosen: 

  • No shared disks are used.
  • The primary database instance is running in Site 1 during normal production.

Within a site, Windows Server Failover Clustering (WSFC) is used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic.

This architecture is depicted in the following figure.

Multi-site VMware Identity Manager Architecture

Figure 52: Multi-site VMware Identity Manager Architecture

For this design, VMware Identity Manager was configured as follows:

  • It uses an active-hot standby deployment.
  • VMware Identity Manager nodes in Site 1 form an Elasticsearch cluster and an Ehcache cluster. Nodes from Site 2 form a separate Elasticsearch cluster and Ehcache cluster.

    Elasticsearch and Ehcache are embedded in the VMware Identity Manager virtual appliance. Elasticsearch is a search and analytics engine used for auditing, reports, and directory sync logs. Ehcache provides caching capabilities.

    • Only the active site can service user requests.
    • An active VMware Identity Manager group exists in the same site as the primary replica for the Always On availability group.
  • The design uses a single identity provider with nodes from both sites.

Important: To implement this strategy, you must perform all the tasks described in the section Setting Up a Secondary Data Center, in Installing and Configuring VMware Identity Manager.

Note: All JDBC connection strings for VMware Identity Manager appliances should point to the SQL Server availability group listener (AGL) and not directly to an individual SQL Server node. For detailed instructions about deploying and configuring the VMware Identity Manager, creating SQL Server failover cluster instances, creating an Always On availability group, and configuring VMware Identity Manager appliances to point to the AGL, see the Appendix F: VMware Identity Manager Configuration for Multi-site Deployment.

If your organization has already deployed Always On availability groups, consult with your database administrator (DBA) about the requirements for the database used with VMware Identity Manager.

The SQL Server Always On setup can be configured to automatically fail over and promote the remaining site’s database to become the primary.

Prerequisites

This section details the prerequisites for the VMware Identity Manager configuration.

vSphere and ESXi

Although several versions are supported, we used vSphere 6.5.

NTP

The Network Time Protocol (NTP) must be correctly configured on all hosts and time-synchronized to an NTP server. You must turn on time sync at the ESXi host level, using an NTP server to prevent a time drift between virtual appliances. If you deploy multiple virtual appliances on different hosts, consider disabling the Sync to Host option for time synchronization. Instead, configure the NTP server in each virtual appliance directly to make sure that there is no time drift between virtual appliances.

Network Configuration

  • Static IP address and DNS Forward (A) and Reverse (PTR) records.
  • Inbound firewall port 443 is open so that users outside the network can connect to the VMware Identity Manager instance or the load balancer.

Active Directory

VMware Identity Manager 3.0 and later supports Active Directory configurations on Windows 2008 R2, 2012, 2012 R2, and 2016, including:

  • Single AD domain
  • Multidomain, single forest
  • Multiforest with trust relationships
  • Multiforest with untrusted relationships (requires external connector configuration)
  • Active Directory Global Catalog optional for Directory Sync

For this reference architecture, Windows 2016 Active Directory was used.

Installation and Initial Configuration

The major steps for on-premises installation and initial configuration of VMware Identity Manager are depicted in the following diagram.

VMware Identity Manager Install and Configure Steps

Figure 53: VMware Identity Manager Install and Configure Steps

The VMware Identity Manager appliance and additional VMware Identity Manager Connector appliances are delivered as an OFV template and deployed using the vSphere Web Client. For information on deploying these appliances, see Install the VMware Identity Manager OVA File and Installing Additional Connector Appliances in Installing and Configuring VMware Identity Manager.

Initial connector settings include administrator, root, SSH passwords, and choice of internal or external database.

Initial server settings include license installation, setting or adding additional required user attributes (objectGUID, for instance, if planning to use Office 365), and setting an SMTP server.

Active Directory configuration involves creating a connection to Active Directory, selecting a bind account with permission to read from AD, choosing groups and users to sync, and initiating a directory sync.

Final configuration updates include setting the device FQDN, installing SSL certificates, configuring load balancers, and enabling logging. Other configurations to complete include joining the appliance or connector to the appropriate AD domain (for ThinApp and Horizon 7 access), configuring additional authentication methods, and finally, any custom branding to apply corporate logos and color schemes to the catalog.

For detailed information on each step, see About Installing and Configuring VMware Identity Manager in Installing and Configuring VMware Identity Manager, and see Deploying VMware Identity Manager in the DMZ.

Next Steps: Providing Access to Resources

Through its Workspace ONE app catalog, VMware Identity Manager centralizes access to resources such as web-based SaaS applications, internal web applications, ThinApp-packaged apps, and Horizon 7–based desktops and applications, as well as RDSH-published applications and desktops.

Based on the types of applications to be delivered to end users, the catalog is configured to integrate with the relevant services.

Workspace ONE Native Mobile Apps

For many users, their first end-user experience of Workspace ONE is likely through the Workspace ONE native mobile app. Available for each OS, the Workspace ONE app allows users to leverage the best technologies on each platform and experience a consistent look and feel across mobile apps and browsers. Features like Apple Touch ID on an iOS device or Windows Hello on Windows 10 can be used.

The app provides:

  • A unified app catalog composed of VMware Identity Manager and VMware AirWatch application types that have been enabled for a user or a device.
  • A launcher to access SaaS and VMware Horizon virtual desktops and apps and ThinApp-packaged apps, making discovery easy for end users.
  • The ability to search across an enterprise’s entire deployment of app resources to find apps.
  • SSO technology for simple user access to resources without requiring users to remember each site’s password.

Workspace ONE App for Windows 10

Figure 54: Workspace ONE App for Windows 10

The Workspace ONE native app is available from the various app stores and can be deployed through VMware AirWatch as part of a device enrollment process.

Component Design: Horizon 7 Enterprise Edition Architecture

As was mentioned in the Architectural Principles and Concepts chapter, we follow a pod and block approach to design and implement View in Horizon 7. This allows us to design, size, and validate in repeatable sized blocks. In this chapter, we detail the design of the first resource block and all components required to implement the View component. Also included are details of architecture design for VMware vRealize® Operations for Horizon®, which provides end-to-end visibility of Horizon and its supporting infrastructure.

View allows us to create and broker connections to Windows virtual desktops, Linux virtual desktops, Remote Desktop Server (RDS)–hosted applications and desktops, and physical machines.

This core part of View in Horizon 7 includes the following components and features:

Component

Description

Connection Server

An enterprise-class desktop management server that securely brokers and connects users to desktops running on vSphere VMs, physical PCs, blade PCs, or RDSH servers.

Horizon Administrator

A web application that is part of the Connection Server, allowing administrators to configure the server, deploy and manage desktops, control user authentication, initiate and examine system events, and carry out analytical activities.

VMware Instant Clone Technology

Provides single-image management with automation capabilities. You can rapidly create automated pools or farms of instant-clone desktops or RDSH servers from a master image.

The technology reduces storage costs and streamlines desktop management by enabling automatic updating and patching of hundreds of images from the master image. Instant Clone Technology accelerates the process of creating cloned VMs over the previous Composer linked-clone technology. In addition, instant clones require less storage and are less expensive to manage and update.

Composer

A server that works with the Connection Servers and a vCenter Server. Composer is the legacy method that enables scalable management of virtual desktops by provisioning from a single master image using linked-clone technology.

Horizon Agent

A software service installed on the guest OS of all VMs, physical systems, or RDSH servers that allows them to be managed by Connection Servers.

Horizon Client

Client-device software that allows a physical device to access a virtual desktop or RDSH-published application in a Horizon 7 deployment. You can optionally use an HTML client for devices for which installing software is not possible.

Unified Access Gateway

Virtual appliance that provides a method to secure connections in access scenarios requiring additional security measures, such as over the Internet. (See Design Component: Unified Access Gateway Architecture for design and implementation details.)

RDSH servers

Provide published applications and session-based remote desktops to end users.

vSphere and vCenter Server

The vSphere product family includes ESXi and vCenter Server, and it is designed for building and managing virtual infrastructures. The vCenter Server system provides key administrative and operational functions, such as provisioning, cloning, and VM management features, which are essential for VDI.

Table 22: View Components of Horizon 7

Design Overview

A successful deployment of Horizon 7 depends on good planning and a robust understanding of the platform. This section discusses the design options and details the design decisions that were made to satisfy the design requirements.

The core elements of View include:

  • Connection Server
  • Composer (only required where linked-clone pools will be deployed)
  • Horizon Agent
  • Horizon Client

The following figure shows the high-level logical architecture of these core elements. Other components are shown for illustrative purposes.

Horizon 7 Logical Architecture

Figure 55: Horizon 7 Logical Architecture

Scalability and Availability

One key design principle is to remove single points of failure in the deployment.

vCenter Server

vCenter Server is the delimiter of a resource block. As outlined in Horizon 7 Pod and Block, the number of recommended VMs per vCenter Server (and therefore per resource block) depends on the types of VMs in use:

  • 5,000 instant-clone VMs (without App Volumes)
  • 4,000 linked-clone or full-clone VMs (without App Volumes)
  • 2,000 VMs if App Volumes AppStacks are attached

A single vCenter Server can handle 25,000 VMs, but that would introduce a single point of failure that could affect too large a number of objects. It would also have performance implications because a single vCenter Server could become a bottleneck in provisioning tasks.

Design Decision: 1 x vCenter Server is deployed per Horizon 7 block of approximately 2,000 VMs. 2,000 was chosen because this resource block hosts a mix of VM types, including the use of App Volumes AppStacks.

Connection Server

A single Connection Server supports a maximum of 4,000 sessions (Blast Extreme or PCoIP). 2,000 is recommended as a best practice.

For more information, see the VMware Knowledge Base article VMware Horizon 7 Sizing Limits and Recommendations (2150348).

To satisfy the requirements that the proposed solution be robust and be able to handle failure, we deploy (n+1).

Design Decision: 2 x Connection Servers (n+1) are deployed to satisfy the requirement of one resource block capable of hosting up to 2,000 sessions while also providing high availability. Additional Connection Servers can be added if a larger block size is chosen.

For more information, see Appendix B: Horizon 7 Configuration.

Composer Server

The Composer server is required only when using linked clones. Instant clones do not require a Composer server.

Each Composer server is paired with a vCenter Server, so in a block architecture where we have one vCenter Server per 4,000 linked-clone VMs, we would also have a Composer server.

High availability is provided by VMware vSphere® High Availability (HA), which restarts the Composer VM in the case of a vSphere host outage. VM monitoring with vSphere HA can also attempt to restart the VM in the case of an operating system crash. If the VMware View Composer service becomes unavailable, all existing desktops can continue to work just fine. While vSphere HA is restarting the Composer VM, the only impact is on any provisioning tasks within that block (image refreshes or recomposes, creating new linked-clone pools).

Design Decision: Although we did not use Composer in this reference architecture, if you choose to use Composer, deploy one Composer server per block of approximately 4,000 linked-clone VMs.

Load Balancing of Connection Servers

For high availability and scalability, it is recommended that multiple Connection Servers be deployed in a load-balanced replication cluster.

Connection Servers broker client connections, authenticate users, and direct incoming requests to the correct endpoint. Although the Connection Server helps form the connection, it typically does not act as part of the data path after the connection is established.

The load balancer serves as a central aggregation point for traffic flow between clients and Connection Servers, sending clients to the best-performing and most available Connection Server instance. Using a load balancer with multiple Connection Servers also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and changes in the configuration without impacting users.

Connection Server Load Balancing

Figure 56: Connection Server Load Balancing

Connection Servers require the load balancer to have a session persistence setting. This is sometimes referred to as persistent connections or sticky connections, and ensures data stays directed to the relevant Connection Server. For more information, see the VMware Knowledge Base article Load Balancing for VMware Horizon View (2146312).

Design Decision: A load balancer is placed in front of the Connection Servers for both internal connections and external connections through the Unified Access Gateway appliances. The source IP is configured for the persistence or affinity type.

External Access

Secure external access for users accessing resources is provided through integration of Unified Access Gateway (formerly called Access Point) appliances using load balancers to provide scalability and allow for redundancy. A Unified Access Gateway appliance can be used in front of Connection Servers to provide access to on-premises Horizon 7 desktops and published applications. For details about which ports are used with Unified Access Gateway appliances and load balancers, see Component Design: Unified Access Gateway Architecture.

For the full detail and diagrams of all the possible ports for different protocols and between all components, see this Network Ports in VMware Horizon 7 or the KB article VMware View ports and network connectivity requirements.

Multi-site Design Using Cloud Pod Architecture

A key component in this reference architecture, and what makes Horizon 7 Enterprise Edition truly scalable and able to be deployed across multiple locations, is Cloud Pod Architecture (CPA).

CPA introduces the concept of a global entitlement (GE) through joining multiple View pods together into a federation. This feature allows us to provide users and groups with a global entitlement that can contain desktop pools or RDSH-published applications from multiple different View pods that are members of this federation construct.

This feature provides a solution for many different use cases, even though they might have different requirements in terms of accessing the desktop resource.

The following figure shows a logical overview of a basic two-site CPA implementation, as deployed in this reference architecture design.

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

Cloud Pod Architecture

Figure 57: Cloud Pod Architecture 

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

As well as being able to have desktop pool members from different pods in a global entitlement, this architecture also allows for a property called scope. Scope allows us to define where new sessions should or could be placed and also allows users to connect to existing sessions (disconnected state) when contacting any of the pod members in the federation.

For this reference architecture, the following global entitlements were used.

GE Setting 

Value 

Name 

Roaming 

Scope 

All Sites (ANY) 

Entitlements 

VMWEUC\All_Sales_People 

Use home site 

Disabled 

Table 23: Global Entitlement Settings for Roaming User Use Case

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

This fits with our requirements because our global load balancer (F5 BIG-IP DNS/GTM) is configured to point the user to an available pod closest to their current geographical location.

If a member of the group VMWEUC\All_Sales_People is closest to Site 1, a session is brokered with the pod in Site 1. The same logic applies if that same member is closest to Site 2.

GE Setting 

Value 

Name 

PowerUser 

Scope 

Within Site 

Entitlements 

VMWEUC\Site1-PowerUsers 

VMWEUC\Site2-PowerUsers 

Use home site 

Enabled 

Entitled user must have home site 

Enabled 

Table 24: Global Entitlement Settings for Power User Use Case

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

The configuration above 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 above two groups is as shown in the following table. 

Group

Domain 

Site

Site1-PowerUsers 

VMWEUC 

Site 1 

Site2-PowerUsers 

VMWEUC 

Site 2 

Table 25: Initial Placement in Different Data Centers

With this configuration, and under normal operating conditions, 

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

Home Site Override – Preparing for Failover 

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

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

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

Name

Domain

Site 

Site1-PowerUsers 

VMWEUC 

Site 2 

Site2-PowerUsers 

VMWEUC 

Site 1 

Table 26: Override Configurations to Use During an Outage

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

Note: This change should only be made for the group impacted by a data center outage. At no point in time would both the override options be configured as depicted in the table above; 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.

Authentication

One of the methods of accessing Horizon 7 desktops and applications is through VMware Identity Manager. This requires integration between Connection Servers and VMware Identity Manager using the SAML 2.0 standard to establish mutual trust, which is essential for single sign-on (SSO) functionality. When SSO is enabled, users who log in to VMware Identity Manager with Active Directory credentials can launch remote desktops and applications without having to go through a second login procedure. If you set up the True SSO feature, users can log in using authentication mechanisms other than AD credentials. See Using SAML Authentication and see Setting Up True SSO in the View Administration guide for details.

Design Decision: SAML authentication is allowed on the Connection Servers. The Connection Servers are configured to allow VMware Identity Manager to be a dynamic SAML authenticator.

True SSO

Many user authentication options are available for logging in to VMware Identity Manager or Workspace ONE. Active Directory credentials are only one of these many authentication options. Ordinarily, using anything other than AD credentials would prevent a user from being able to single-sign-on to a Horizon 7 virtual desktop or published application. After selecting the desktop or published application from the catalog, the user would be prompted to authenticate again, this time with AD credentials.

True SSO provides users with single sign-on to Horizon 7 desktops and applications regardless of the authentication mechanism used. True SSO uses SAML, where Workspace ONE is the Identity Provider (IdP) and the Horizon 7 server is the Service Provider (SP). True SSO generates unique, short-lived certificates to manage the login process. This enhances security because no passwords are transferred within the data center.

True SSO Overview

Figure 58: True SSO Overview

True SSO requires a new service—the enrollment server—to be installed using the Horizon 7 installation media. The enrollment server can be installed on a dedicated Windows 2016 server, or it can co-exist on the server running the MS Certificate Authority service.

Design Overview

For True SSO to function, several components must be installed and configured within the environment. This section discusses the design options and details the design decisions that satisfy the requirements.

Note: For more information on how to install and configure True SSO, see Setting Up True SSO in the View Administration guide.

Enrollment Server

The enrollment server is responsible for receiving certificate signing requests from the Connection Server and then passing them to the Certificate Authority to sign using the relevant certificate template.

The enrollment server is a lightweight service that can be installed on a dedicated Windows 2016 server, or it can co-exist with the MS Certificate Authority.

A single enrollment server can easily handle all the requests from a single pod.

To satisfy the requirements that the proposed solution be robust and able to handle failure, we deploy n+1 enrollment servers.

Design Decision: 2 enrollment servers are deployed within a pod to satisfy the requirement of 2,000 sessions and high availability. Each enrollment server is hosted on a dedicated Windows 2016 VM.

Two enrollment servers are deployed in the environment, and the Connection Servers are configured to communicate to both deployed enrollment servers. The enrollment servers can be configured to communicate with two Certificate Authorities. By default, the enrollment servers use the Active / Failover method of load balancing. This can be changed to round robin if required.

True SSO Availability and Redundancy

Figure 59: True SSO Availability and Redundancy

Design Decision: The default mode of Active / Failover is sufficient to meet the requirements and is left in its default state.

The enrollment servers reside within the management block and are placed in the management cluster. vSphere HA and DRS can be used to ensure the maximum availability of the enrollment servers. DRS rules are configured to ensure that the devices do not reside on the same ESXi host. This enhances High Availability.

Virtual Machine Build

Connection Servers and Composer servers run as Windows services. Specifications are detailed in Appendix A: VM Specifications. Each server is deployed with a single network card, and static IP address information is required for each server.

Design Decision: Windows Server 2016 is used for the OS build as the latest supported version. IP address information is allocated for each server.

Physical Hosting

The Connection Server and Composer VMs are part of the management block and are placed on the management vSphere hosts. vSphere HA and DRS can be used to ensure maximum availability.

Protocol

Horizon 7 is a multi-protocol solution. Three remoting protocols are available when creating desktop pools or RDSH-published applications—RDP, PCoIP, and the new Blast Extreme protocol.

Design Decision: For this design, we leverage Blast Extreme. This display protocol supports multiple codecs (JPG/PNG and H.264), both TCP and UDP from a transport protocol perspective, and the ability to do hardware encoding with NVIDIA GRID vGPU. This protocol has full feature and performance parity with PCoIP and is optimized for mobile devices, which can decode video using the H.264 protocol in hardware.

Configuration

Blast Extreme is configured through Horizon 7 when creating a pool. The Blast Extreme display protocol is integrated directly into the Connection Server so that no separate installation is required. The protocol can also be selected directly on the Horizon Client side when a user selects a desktop pool. Blast Extreme can also use TCP port sharing with Unified Access Gateway so firewall configuration and port requirements can be simplified.

Prerequisites

In order to use the Blast Extreme display protocol, the following must be in place:

  • Horizon 7 infrastructure.
  • Horizon 4.x Client must be used to connect.

Key Design Considerations

  • Use H.264 when possible (most modern devices have the ability to hardware-decode H.264).
  • TCP 443 port sharing with Unified Access Gateway simplifies port requirements.
  • Even if a pool is forced to Blast Extreme, devices such as PCoIP zero clients will connect using PCoIP.
  • Horizon 4.x Client must be used to connect.
  • See the Blast Extreme Display Protocol in VMware Horizon 7 whitepaper for more information, including optimization tips.

VMware vRealize Operations for Horizon

Traditionally management and monitoring of enterprise environments involved monitoring a bewildering array of systems, requiring administrators to switch between multiple consoles to support the environment.

VMware vRealize Operations for Horizon provides end-to-end visibility into Horizon 7 and its supporting infrastructure, enabling administrators to:

  • Meet service-level agreements (SLAs)
  • Reduce the first time to resolution (FTR)
  • Improve user satisfaction
  • Proactively monitor the environment and resolve issues before they affect users
  • Optimize resources and lower management costs
  • Monitor reporting
  • Create custom dashboards

Architectural Components

vRealize Operations for Horizon consists of multiple components. These components are described here, and design options are discussed and determined.

vRealize Operations for Horizon Logical Architecture

Figure 60: vRealize Operations for Horizon Logical Architecture

Broker Agent

The broker agent is a Windows service that runs on a Connection Server host that collects Horizon 7 inventory information, and then sends that information to the vRealize Operations for Horizon Adapter.

  • The broker agent collects information from the event database and sends it to the Horizon adapter.
  • The broker agent is installed on one Connection Server host in each Horizon 7 pod.
  • Only one broker agent exists in each Horizon 7 pod.
  • Connection Server 6.0.1 or later is required. We used Connection Server 7.3.2.
  • .NET Framework 4.5 is required.

Design Decision: The broker agent is configured to collect information from the event database. It is deployed to a single Connection Server within the pod.

Horizon Adapter

The adapter passes data from the agents to vRealize Operations Manager for analysis and visualization. It also obtains inventory information from the broker agent and collects metrics and performance data from desktop agents. Horizon adapters do not support vSphere HA. In the event of a failure, data will not be collected until the issue is resolved and the adapter is brought back online.

Design Decision: Install the Horizon adapter on one of the cluster nodes.

Desktop Agent

The vRealize Operations for Horizon desktop agent runs on each remote desktop or RDSH server VM in the Horizon 7 environment. The desktop agent is included in the Horizon agent installer. It collects metrics and performance data and sends that data to the Horizon adapter. Metrics collected by the desktop agent include:

  • Desktop and application objects
  • Users’ login time and duration
  • Session duration
  • Resource and protocol information

Design Decision: The desktop agent is installed as part of the standard Horizon Agent and is enabled during installation.

Design Overview

vRealize Operations for Horizon facilitates proactive monitoring and management of a Horizon environment and can also proactively monitor vSphere and display all information, alerts, and warnings for compute, storage, and networking.

vRealize Operations for Horizon consists of two components: the vRealize Operations Manager appliance and the Horizon adapter. Other adapters can be added to the core vRealize Operations Manager appliance to gather information from other sources; for example, the VMware vRealize® Operations for Published Applications™ adapter retrieves information from Citrix environments and displays it within the vRealize Operations Manager dashboards.

Design Decision: To meet our requirements in this reference architecture, the latest version of the vRealize Operations Manager (6.5) appliance and the Horizon adapter (6.5) are used.

Deployment Options

vRealize Operations Manager can be deployed on either Windows or Linux. It can also be deployed as a self-contained appliance.

vRealize Operations Manager can be deployed as a single node, as part of a cluster, or as a cluster with remote nodes

  • Single node – A single-node deployment does not provide high availability and is limited in the number of objects it can support.
  • Cluster – A cluster can consist of up to eight nodes (appliances). This provides flexibility and the ability to scale to suit most enterprise deployments while providing high availability.
  • Cluster + remote node – A remote node is deployed on a remote site or data center to capture information before compressing and passing it back to the cluster for processing. Remote nodes can also be used within the same data center as the cluster and have adapters installed on them instead of the cluster nodes, freeing the cluster nodes to handle the analytical processing.

Design Decision: The vRealize Operations Manager appliances are deployed as part of a cluster to meet the requirements.

Scalability

vRealize Operations for Horizon can scale to support very high numbers of Horizon sessions. To assess the requirements for your environment, see vRealize Operations Manager 6.5 Sizing Guidelines (KB 2148829).

Design Decision: To support the number of RDSH sessions per host and VDI desktops per session, and to meet requirements for high availability, a three-medium-node cluster is deployed.

Firewall Ports

To support a successful installation, the following firewall ports must be open bidirectionally between:

  • Connection Server (broker agent) and the vRealize Operations node: TCP 3091, 3101, and 3100
  • Horizon Agents and the vRealize Operations node: TCP 3091 and 3099

 See Create an Instance of the Horizon Adapter in the VMware vRealize Operations for Horizon Installation guide for more detail.

Component Design: App Volumes Architecture

The App Volumes just-in-time application model separates IT-managed applications and application suites into administrator-defined application containers and introduces an entirely different container used for persisting user changes between sessions.

App Volumes Just-in-Time Application Model

Figure 61: App Volumes Just-in-Time Application Model

Design Overview

App Volumes serves two functions. The first is delivery of applications that are not in the master VM image for VDI and RDSH. App Volumes groups applications into AppStacks based on the requirements of each use case. An AppStack is a group of applications that are captured together. The AppStacks can then be assigned to a user, group, OU, or machine and mounted each time the user logs in to a desktop. For VDI use cases, AppStacks can be mounted either on-demand or at login. With RDSH use cases, because AppStacks are assigned to the machine account, the AppStacks are mounted when the App Volumes service starts.

App Volumes also provides user-writable volumes for a limited number of users. Writable volumes provide a mechanism to capture user-installed applications that are not, or cannot be, delivered by AppStacks. This reduces the likelihood that persistent desktops would be required for a use case. The user-installed applications follow the user as they connect to different virtual desktops.

The following table lists the components of App Volumes.

 

Component

Description

App Volumes Manager

  • Console for management of App Volumes, including configuration, creation of AppStacks, and assignment of AppStacks and writable volumes
  • Broker for App Volumes Agent for the assignment of applications and writable volumes

App Volumes Agent

  • File system and registry abstraction layer running on the target system
  • Virtualizes file system writes as appropriate (when used with an optional writable volume)

AppStack Volume(s)

  • Read-only volume containing applications
  • One or more AppStack per user or machine
  • Deploys apps to VDI or RDSH

Writable volume

  • Read-write volume that persists changes written in the session, including user-installed applications and user profile
  • One writable volume per user
  • Only available with user or group assignments

Provisioning VMs

  • Clean Windows VM with App Volumes Agent
  • Provisions and updates applications into an AppStack

Table 27: App Volumes Components

Infrastructure Overview

The App Volumes infrastructure comprises the following components:

  • Virtual desktops or RDSH servers running the App Volumes Agent
  • Load balancer to manage connections to the App Volumes Manager servers
  • Pair of App Volumes Manager servers to handle brokering and management
  • vCenter Server to manage vSphere hosts for attaching and detaching AppStacks and writable volumes
  • Highly available SQL Server for hosting App Volumes Manager data
  • Active Directory environment for assigning AppStacks and writable volumes

App Volumes Logical Architecture

Figure 62: App Volumes Logical Architecture

Key Design Considerations

  • Always use at least two App Volumes Managers.

Note: Requires a shared SQL Server.

  • Any kernel mode applications should reside in base image and not in an AppStack.
  • Use storage groups (if you are not using VMware vSAN) to aggregate load and IOPS. 

Note: AppStacks are very read intensive.

  • Place AppStacks on storage that is optimized for read (100 percent read).
  • Place writable volumes on storage optimized for random IOPS (50/50 read/write).
  • Do not assign more than 8–10 AppStacks per user or device.
  • Always use the Mount on Host setting, which speeds up the mount and login process and reduces the overall load on vCenter Server. This option issues the API calls directly to the host on which the virtual desktop or RDSH server resides.

Scalability and Availability of App Volumes Managers

The App Volumes Managers are the primary point of management and configuration, and they broker volumes to agents. For a production environment, deploy at least two App Volumes Manager servers. The App Volumes Manager is stateless—all of the data required by App Volumes is located in a SQL database. Deploying at least two App Volumes Manager servers ensures the availability of App Volumes services and distributes the user load.

Design Decision: Two VMware App Volumes Manager servers were deployed with a load balancer.

Load Balancing

For high performance and availability, an external load balancer is required to balance connections between App Volumes Managers. The main concern with App Volumes Managers is handling login storms. For App Volumes 2.13, each App Volumes Manager can handle up to 1,000 users, but the exact number can vary, depending on the load and the specifics of each environment. It is recommended that you test the load and size the number of App Volumes Manager servers appropriately. To size this design, we assumed each App Volumes Manager was able to handle 1,000 users.

Design Decision: A load balancer is placed in front of the App Volumes Manager servers. The load balancer properly distributes load and keeps the services available in the event of an issue with one of the managers.

Database

VMware App Volumes 2.13 uses a Microsoft SQL Server database to store all of the configuration, assignment, and metadata. This database is a critical aspect of the design, and it must be accessible to all of the App Volumes Managers.

Design Decision: The SQL database was placed on a highly available SQL Server, which was installed on a Windows Server Failover Cluster. An Always On availability group achieves automatic failover, and both of the App Volumes Managers point to the availability group listener for the SQL Server.

AppStack Storage

App Volumes uses a construct of storage groups. A storage group is a collection of datastores that are used to serve AppStacks or distribute writable volumes. In App Volumes 2.13, the AppStacks within a storage group can be replicated among its peers to ensure all AppStacks are available. Having a common datastore presented to all hosts in all vCenter Servers allows AppStacks to be replicated across vCenter Servers and datastores.

Note: This design utilizes VMware vSAN, which provides a single highly available datastore per VMware vSphere cluster.

Design Decision: Storage groups are used in this design because there are separate vSAN datastores for the instant-clone pools. AppStacks are automatically replicated between the two datastores by the storage group.

Multi-site Design

There are two deployment options for the App Volumes database across multiple sites.

  • Separate databases – This option uses a separate SQL Server database at each site.

    The App Volumes Managers at each site point to the local database instance and have only machine managers registered for vCenter Servers from their own site.

    Windows Server Failover Clustering (WSFC) and SQL Server Always On availability groups can be used within a site to provide local high availability.

  • Clustered database – This option uses an Always On availability group to stretch the database instance across two sites.

    The App Volumes Managers at both sites point to the availability group listener rather than an SQL Server node or a clustered instance. The App Volumes Managers at both sites also have machine managers for vCenter Servers from both Site 1 and Site 2, including mapping their corresponding datastores.

    Local site availability of the database can be achieved by using an SQL Server failover cluster instance (FCI), which is installed on a WSFC cluster.

The separate-databases approach is much simpler to implement than setting up a clustered database for both sites. It also allows for easy scaling if you have more than two sites. Additionally, if the latency between App Volumes Manager and SQL Server is higher than 15 milliseconds, VMware recommends that you use separate databases. The disadvantage is that user-based entitlements to AppStacks must be replicated in both sites. This process can be automated, as described in Appendix E: Configuration for a VMware App Volumes Multi-Site Deployment.

With both strategies,

  • At least two App Volumes Managers are used in each site for local redundancy and scalability.
  • Storage groups are used to replicate AppStacks.
  • Replication across sites is achieved when one of the datastores is a member of storage groups from each of the sites and is visible to at least one vSphere host from each site.
  • These common datastores are used as swing targets for cross-site replication and are marked as non-attachable.

App Volumes with Separate Database Instances

For this reference architecture, the decision was made to use separate database instances rather than using a clustered database across sites. With this option, you can still use Always On availability groups, but each site has its own availability group to achieve automatic failover within a site. To make user-based entitlements for AppStacks available between sites, you can either manually reproduce the entitlements at each site or use a PowerShell script, which VMware provides.

App Volumes Multi-Site Separate-Databases Option

Figure 63: App Volumes Multi-Site Separate-Databases Option

To implement this design, 

  • Separate instances of App Volumes are deployed in each site.
  • Each site has its own namespace for the local App Volumes Managers. This is generally a local load balancer virtual IP that targets the individual managers. App Volumes Agents must be configured to use the appropriate local namespace.
  • A separate database is used for each site; that is, you have a separate WSFC cluster and an SQL Server Always On availability group listener for each site.
  • A local load balancer in each site is generally used to provide a local namespace for the site’s App Volumes instance.
  • Operational procedures must be put in place for reproducing user entitlements in the other site. VMware provides a PowerShell script that replicates entitlements. See the Appendix E: Configuration for a VMware App Volumes Multi-Site Deployment.

In this model, each site works independently, with its own set of App Volumes Managers and its own database instance. During an outage, the remaining site can provide access to AppStacks with no intervention required. For detailed information on the failover steps required and the order in which they need to be executed, refer to Failover with Separate Databases.

Configuration with Separate Databases

When installing and configuring the App Volumes Managers in a setup like this, each site uses a standard SQL Server installation.

  1. Install the first App Volumes Manager in Site If using Always On availability groups to provide a local highly available database, use the local availability group listener for Site 1 when configuring the ODBC connection.

    Important: For step-by-step instructions on this process, see Appendix E: Configuration for a VMware App Volumes Multi-Site Deployment

  2. Complete the App Volumes Manager wizard and add the vCenter Servers for Site 1 as machine managers, including mapping their corresponding datastores.
  3. Continue with installing the subsequent App Volumes Managers for Site 1. Add them as targets to the local load balancer virtual IP.
  4. Repeat steps 1–3 for Site 2 so that the App Volumes Managers in Site 2 point to the local availability group listener for Site 2, and register the local vCenter Servers for Site 2 as machine managers.
  5. For details on setting up storage groups for replicating AppStacks from site to site, see the Recovery Service Integration section of the Service Integration Design chapter.
  6. Configure and run the PowerShell script for replicating AppStack entitlements between the sites, as described in Appendix E: Configuration for a VMware App Volumes Multi-Site Deployment

With this design, the following is achieved: 

  • AppStacks are made available in both sites.
  • AppStacks are replicated from site to site through storage groups defined in App Volumes Manager and through the use of a common datastore that is configured as non-attachable.
  • User-based entitlements for AppStacks are replicated between sites.
  • A writable volume is normally active in one site for a given user.
  • Writable volumes can be replicated from site to site using processes such as array-based replication. An import operation might be required on the opposite site. The order and details for these steps are outlined in Appendix D: Horizon 7 Recovery Services Test Plan.
  • Entitlements for writable volumes are available between sites.

Failover with Separate Databases

In this model, each site works independently, with its own set of App Volumes Managers and its own database instance. During an outage, the remaining site can provide access to AppStacks with no intervention required.

  • The AppStacks have previously been copied between sites using non-attachable datastores that are members of both sites’ storage groups.
  • The entitlements to the AppStacks have previously been reproduced, either manually or through an automated process.

In use cases where writable volumes are being used, there are a few additional steps:

  1. Mount the replicated datastore that contains the writable volumes.
  2. Perform a rescan of that datastore. If the datastore was the default writable volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.
  3. (Optional) If the datastore is not the default writable volume location, perform an Import Writable Volumes operation from the App Volumes Manager at Site 2. All assignments to writable volumes are successfully added, but to the new valid location.

App Volumes with a Clustered Database

This option uses an SQL Server Always On availability group listener that is common across both sites. One site is the primary instance and the second site the secondary. Database failover is needed if the primary instance fails, and failover can be automatic.

App Volumes Multi-Site Clustered Database Option

Figure 64: App Volumes Multi-Site Clustered Database Option

If you choose this option, it means using an Always On availability group with an availability group listener to which all App Volumes Manager instances are pointed for their database (ODBC) configuration. This setup is similar to the VMware Identity Manager configuration, except that the App Volumes Managers from both sites can be active at the same time.

The use of an Always On availability group effectively shares the configuration between all App Volumes Manager instances, resulting in user-based entitlements being available across sites as well as the two vCenter Server instances being configured in the same context.

Each site has a local load balancer that provides a local namespace for the site’s App Volumes instance. This is consumed by a global load balancer, which provides a global namespace that is common across both sites.

Configuration with a Clustered Database

When installing and configuring the App Volumes Managers in a setup like this, it is recommended to perform the following tasks in the specified order:

  1. Install the first App Volumes Manager in the primary site where the primary SQL Server failover cluster instance (FCI) is running using the availability group listener when configuring the ODBC connection.
  2. Complete the App Volumes Manager wizard and add vCenter Servers from both Site 1 and Site 2 as machine managers, including mapping their corresponding datastores.
  3. Continue with installing the subsequent managers in the same site as the first manager.
  4. Repeat steps 1–3 for Site 2 so that the App Volumes Managers in Site 2 point to the availability group listener.
  5. For details on setting up storage groups for replicating AppStacks from site to site, see the Recovery Service Integration section of the Service Integration Design chapter.

For details on configuration of a clustered database for App Volumes, see Appendix E: Configuration for a VMware App Volumes Multi-site Deployment.

With this design, the following is achieved: 

  • Global load balancing directs the App Volumes Agent (and therefore, the user) to the corresponding App Volumes Manager used with the user’s associated site. This allows for the configuration of the App Volumes Agent with the same namespace across master images.
  • AppStacks are made available in both sites.
  • The AppStacks are replicated from site to site through storage groups defined in App Volumes Manager, and through the use of a common datastore that is configured as non-attachable.
  • User-based entitlements for AppStacks are readily available between sites.
  • A writable volume is only active in one site for a given user.
  • Writable volumes can be replicated from site to site using processes such as array-based replication. During an outage, you must perform a restore operation to mount the datastore that contains the replicated writable volumes. You must then use App Volumes Manager to rescan the datastore.
  • Entitlements for writable volumes are available between sites.

Failover with a Clustered Database

When performing a failover, the App Volumes Manager marks the vCenter Server in the site that has failed as being offline. Full functionality can still be achieved in the failover site.

  • The configuration is shared through the Always On availability group for the database.
  • The AppStacks have previously been copied between sites using non-attachable datastores that are members of both sites’ storage groups.

The only operation required during a site outage—and then, only if it is Site 1 that fails—is manually forcing the SQL Server Always On availability group to promote the secondary SQL Server FCI to become the primary. For instructions, see Perform a Forced Manual Failover of an Availability Group (SQL Server).

In use cases where writable volumes are being used, there are a few additional steps:

  1. Mount the replicated datastore that contains the writable volumes.
  2. Perform a rescan of that datastore. If the datastore was the default writable volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.
  3. (Optional) If the datastore is not the default writable volume location, perform an Import Writables operation from the App Volumes Manager at Site 2.

The following figure shows how virtual desktops and RDSH-published applications can point to an internal load balancer that distributes the load to two App Volumes Managers.

App Volume Managers Load Balancing

Figure 65: App Volume Managers Load Balancing

In the following list, the numbers correspond to numbers in the diagram.

  1. No additional configuration is required on the App Volumes Manager servers.
  2. Load balancing of App Volumes Managers should use the following:
  • Ports = 80, 443
  • Persistent or session stickiness = Hash all Cookies
  • Timeout = 6 minutes
  • Scheduling method = round robin
  • HTTP headers = X-Forward-For
  • Real server check = HTTP

Installation and Initial Configuration

Installation prerequisites are covered in more detail in the System Requirements section of the VMware App Volumes User Guide. The following table lists the versions used in this reference architecture.

Component

Requirement

Hypervisor

VMware vSphere 6.5

Virtual Center

VMware vCenter 6.5

App Volumes Manager

Windows Server 2016

Active Directory

2016 Functional Level

SQL Server

SQL Server 2016

App Volumes Agent

Windows 10 and Windows Server 2016

Table 28: App Volumes Installation Prerequisites

Refer to the VMware App Volumes User Guide for installation procedures. This document outlines the initial setup and configuration process.

After installation is complete, you must perform the following tasks to start using App Volumes:

  • Complete the App Volumes Initial Configuration Wizard (https://avmanager).
  • To optimize the speed of AppStack attachments, it is recommended that mount on host is set. This requires user accounts with same username and password on all resource vSphere hosts.
  • Install the App Volumes Agent on one or more clients and point the agent to the App Volumes Manager address (load-balanced address).
  • Select a clean provisioning system and provision an AppStack. See Working with AppStacks in the VMware App Volumes User Guide for instructions.
  • Assign the AppStack to a test user and verify it is connecting properly.
  • Assign a writable volume to a test user and verify it is connecting properly.

Component Design: User Environment Manager Architecture

User Environment Manager provides profile management by capturing user settings for the operating system and applications. Unlike traditional application profile management solutions, User Environment Manager does not manage the entire profile. Instead it captures settings that the administrator specifies. This reduces login and logout time because less data needs to be loaded. The settings can be dynamically applied when a user launches an application, making the login process more asynchronous. User data is managed through folder redirection.

User Environment Manager

Figure 66: User Environment Manager

VMware User Environment Manager is a Windows-based application that consists of the following components.

Component

Description

Active Directory Group Policy

  • Mechanism for configuring User Environment Manager.
  • ADMX template files are provided with the product.

NoAD Mode XML file

An alternative to using Active Directory Group Policy for configuring User Environment Manager. With NoAD mode, you do not need to create a GPO, write logon and logoff scripts, or configure Windows Group Policy settings.

 

Configuration share

  • A central share (SMB) on a file server, which can be a replicated share (DFS-R) for multi-site scenarios as long as the path to the share is the same for all client devices.
  • Is read only to users.
  • If using DFS-R, it must be configured as hub and spoke. Multimaster replication is not supported.

 

Profile Archives share

  • File shares (SMB) to store the users’ profile archives and profile archive backups.
  • Is used for read and write by the users.
  • Archives should be placed on a share close to the computer where the User Environment Manager FlexEngine runs for best performance.

UEM FlexEngine

The User Environment Manager Agent that resides on the virtual desktop or RDSH server VM being managed.

Application Profiler

Utility that creates a User Environment Manager Flex configuration file from an application by determining where the application stores configuration data in the registry and file system. User Environment Manager can manage settings for applications that have a valid User Environment Manager Flex configuration file in the configuration share.

Helpdesk Support Tool

  • Allows support personnel to reset or restore user settings.
  • Enables administrators to open or edit profile archives.
  • Allows analysis of profile archive sizes.
  • Log file viewer.

Self-Support

Optional self-service tool to allow users to manage and restore their configuration settings on an environment setting or application.

Table 29: User Environment Manager Components

User Environment Manager Logical Architecture

Figure 67: User Environment Manager Logical Architecture

User Profile Strategy

A Windows User Profile is made of multiple components, including local data, user data, and the user registry.

User Environment Manager User Profile Strategy

Figure 68: User Environment Manager User Profile Strategy

In conjunction with User Environment Manager, mandatory, roaming, or local profiles, and folder redirection can be used to redirect user data.

Design Decision: Mandatory profiles and folder redirection are used. A mandatory user profile is a preconfigured roaming user profile that specifies settings for users. With mandatory user profiles, a user can modify their desktop, but the changes are not saved when the user logs out. Because all settings are managed by User Environment Manager, there is no need to persist these settings on log out.

See Appendix B: Horizon 7 Configuration for condensed instructions for creating mandatory profiles. Further instruction can be found on the Microsoft website.

Infrastructure

User Environment Manager requires little infrastructure. AD GPOs are used to specify User Environment Manager settings, and SMB shares are used to host the configuration data and profile data. The User Environment Manager Management Console is used by administrators to configure settings.

User Environment Manager Infrastructure

Figure 69: User Environment Manager Infrastructure

Key Design Considerations

  • Use DFS-R or file server clustering to provide HA to configuration and user shares.
  • Use loopback processing when applying the GPO settings to computer objects.

Multi-site Design

User Environment Manager data consists of the following types. This data is typically stored on separate shares and can be treated differently for availability: 

  • IT configuration data – IT-defined settings that give predefined configuration for the user environment or applications
  • Profile archive (user settings and configuration data) – The individual end user’s customization or configuration settings

It is possible to have multiple sets of shares to divide the user population into groupings. This can provide separation, distribute load, and give more options for recovery. By creating multiple User Environment Manager configuration shares, you create multiple environments. You can use a central installation of the Management Console to switch between these environments and export and import settings between environments. You can also use User Environment Manager group policies to target policy settings to specific groups of users, such as users within a particular Active Directory OU.

To meet the requirements of having User Environment Manager IT configuration data and user settings data available across the two sites, this design uses Distributed File System Namespace (DFS-N) for mapping the file shares. 

Although we used DFS-N, you are not required to use DFS-N. Many different types of storage replication and common namespaces can be used. The same design rules apply.

IT Configuration Share 

For IT configuration file shares, DFS-Namespace (DFS-N) is fully supported.

Note: The configuration share should allow users only to read and not to write or make any changes. Only administrators should be able to make changes to the content of the share.

Supported DFS Topology for User Environment Manager IT Configuration Share

Figure 70: Supported DFS Topology for User Environment Manager IT Configuration Share

Profile Archive Shares 

For user settings file shares, DFS-Namespace is fully supported.

Supported DFS Topology for User Environment Manager User Settings Share

Figure 71: Supported DFS Topology for User Environment Manager User Settings Share

Switching to another file server in the event of an outage requires a few simple manual steps:

  1. Manually disable the active DFS-N folder target.
  2. Enable the passive DFS-N folder target.
  3. Remove the read-only option on the target.

Supported DFS Topology for the User Environment Manager User Settings Share

Figure 72: Supported DFS Topology for the User Environment Manager User Settings Share (Failover State) 

The management console can be installed on as many computers as desired. If the management console is not available after a disaster, you can install the management console on a new management server or on an administrator’s workstation and point that installation to the User Environment Manager configuration share.

Installation

You can install and configure User Environment Manager in a few easy steps:

  • Create SMB file shares for configuration data and user data.
  • Import ADMX templates for User Environment Manager.
  • Create Group Policy settings for User Environment Manager.
  • Install FlexEngine agent on virtual desktop or RDSH server VMs to be managed.
  • Install the User Environment Manager Management Console and point to the configuration share.
  • Use Easy Start to do initial configuration of many common Windows environment and application settings. Easy Start provides many application templates, including for various versions of Microsoft Office.

Refer to the User Environment Manager Administrator’s Guide for detailed installation procedures. Also see the Quick-Start Tutorial for User Environment Manager. We used User Environment Manager 9.2.1.

Next Steps

After installing User Environment Manager, perform the following tasks to verify functionality:

  • Install User Environment Manager Agent on one or more virtual desktop or RDSH server VMs to be managed.
  • Set a few customizations (for example, desktop shortcuts for VLC, Notepad++).
  • Log in to the virtual desktop or RDSH-published application and verify that User Environment Manager has made the requested changes.
  • Check the user log to verify that User Environment Manager is working, or troubleshoot if it is not working as expected. The logs folder is in the SMB share specified for user data.

Component Design: Unified Access Gateway Architecture

VMware Unified Access Gateway is an optional component in a Workspace ONE deployment. It allows secure remote access from outside the corporate network to internally hosted resources.

Unified Access Gateway can be used for multiple use cases, including:

  • Remote access to Horizon 7 desktops and applications
  • Reverse proxying of web servers such as VMware Identity Manager
  • Access to on-premises legacy applications that use Kerberos or header-based authentication with identity bridging from SAML or certificates
  • Provision of VMware AirWatch or Workspace ONE per-app tunnels and the Tunnel Proxy to allow mobile applications secure access to internal services
  • Access from VMware Content Locker to internal file shares or SharePoint repositories by running the Content Gateway service

Unified Access Gateway is typically deployed within the corporate DMZ and acts as a proxy host for connections to your company’s resources. Unified Access Gateway directs authenticated requests to the appropriate resource and discards any unauthenticated requests.

VMware Unified Access Gateway Logical Architecture

Figure 73: VMware Unified Access Gateway Logical Architecture

Unified Access Gateway also provides options for additional authentication methods from the DMZ:

  • Smart card support
  • Security certificates
  • SAML pass-through support
  • RADIUS support

Design Decisions:

To meet the design requirements for Horizon 7, Unified Access Gateway appliances are deployed in front of the Horizon 7 Connection Servers.

Unified Access Gateway will also be deployed to provide per-App tunnel and to run the Content Gateway as part of the AirWatch service.

Design Overview

A successful deployment of Unified Access Gateway is dependent on good planning and a robust understanding of the platform. The following sections discuss the design options and details the design decisions that are made to satisfy the design requirements.

Scalability

Unified Access Gateway gives two sizing options during deployment.

 

Item

Standard

Large

CPU (Cores)

2

4

Memory (GB)

4

16

Recommended use

For VMware AirWatch deployments with fewer than 10,000 connections

For VMware AirWatch deployments with more than 10,000 connections

Sizing

1 appliance per 2,000 Horizon server connections

 

1 appliance per 10,000 VMware AirWatch service sessions

1 appliance per 2,000 Horizon server connections

 

1 appliance per 50,000 VMware AirWatch service sessions

Table 30: Unified Access Gateway Sizing

To satisfy the requirements that the proposed solution be robust and able to handle failures, we deploy n+1 appliances.

Design Decisions:

2 x standard size, Unified Access Gateway appliances are deployed to satisfy the requirement of 2,000 Horizon 7 sessions and high availability (n+1).

3 x large size, Unified Access Gateway appliances are deployed to satisfy the requirement for 50,000 devices using both Contented Gateway and per-App Tunnel (total of 100,000 sessions) and high availability (n+1).

Load Balancing 

It is highly recommended that users connect to Unified Access Gateway using a load-balanced virtual IP (VIP). This ensures that user load is evenly distributed across all available Unified Access Gateway appliances. Using a load balancer also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and changes in the configuration without impacting users.

Additionally, it is recommended that connections from the Unified Access Gateway appliances to the Connection Servers also be load balanced, although this is not required.

The following figure illustrates how Unified Access Gateway appliances and load balancers can be used together to provide secure access and failover.

Connection Server Load Balancing and External Access

Figure 74: Connection Server Load Balancing and External Access

Although the diagram illustrates the use of split DNS, this is not a requirement for Connection Server traffic. Split DNS does, however, provide certain advantages because users can use the same host name internally and externally. In the following list, the numbers correspond to numbers in the diagram.

  1. No additional configuration is required on the Connection Servers.
  2. Load balancing of Connection Servers should use the following settings:
    • Ports = 443, 389
    • Persistent or session stickiness = Source IP
    • Timeout = 30 minutes
    • Real server check = HTTPS
  3. Deploy the Unified Access Gateway appliances using a Horizon script (see Unified Access Gateway Deployment and Initial Configuration).
  4. Load balancing of Unified Access Gateway appliances for traffic destined for Connection Servers:
    • Ports = 443
    • Persistent or session stickiness = Source IP
    • Add an HTTP redirector
    • Real server check = HTTPS, URL =/favicon.ico, Method = GET

Unified Access Gateway Load Balancing

Figure 75: Unified Access Gateway Load Balancing

Only the initial XML API (authentication, authorization, and session management) connection is load-balanced; Blast Extreme, PCoIP, or RDP connections connect directly to the Unified Access Gateway appliance that brokered the initial XML API connection. For load balancing to function correctly, a connection must maintain persistence/affinity of the session. To facilitate this, there are a few methods that can be implemented in the environment to support session persistence/affinity as outlined in Load Balancing across VMware Unified Access Gateway Appliances:

  • Source IP address
  • Multiple port number groups
  • Multiple virtual IP addresses (VIPs)

Design Decision: A load balancer is placed both in front of the Unified Access Gateway appliances and between the appliances and the Connection Servers. Source IP is used as the method to support session persistence/affinity.

Network Deployment Options

Unified Access Gateway can be deployed with one, two, or three network interface controllers (NICs). The decision is determined by your network requirements and discussions with the security teams to ensure compliance with company policy.

Single NIC

In a single-NIC deployment, all traffic (Internet, backend, and management) uses the same network interface.

Unified Access Gateway Single-NIC Deployment

Figure 76: Unified Access Gateway Single-NIC Deployment

Dual NIC

A dual-NIC deployment separates the Internet traffic onto its own NIC, while the management and backend network data still share a NIC. This type of deployment is suitable for production environments.

Unified Access Gateway Dual-NIC Deployment

Figure 77: Unified Access Gateway Dual-NIC Deployment

Three NIC

A three-NIC deployment separates the Internet traffic onto its own NIC, and separates management and backend network data onto dedicated networks. This type of deployment is suitable for production environments.

Unified Access Gateway Three-NIC Deployment

Figure 78: Unified Access Gateway Three-NIC Deployment

Design Decision: To meet the requirements of separating Internet traffic from management and backend data, the Unified Access Gateway appliances are deployed in a dual-NIC mode.

Authentication Options

Unified Access Gateway supports multiple authentication options, for example, pass-through, RSA SecurID, RADIUS, certificate, and smart card. Pass-through authentication forwards the XML API request from the HTTPS web server and passes it to the Connection Server through the XML API Tunnel within the Unified Access Gateway. Other authentication types enable authentication at the Unified Access Gateway, before passing an authenticated session to a Connection Server.

This is depicted in the following diagrams:

Unified Access Gateway Pass-Through Authentication

Figure 79: Unified Access Gateway Pass-Through Authentication

Unified Access Gateway Two-Factor Authentication

Figure 80: Unified Access Gateway Two-Factor Authentication

Design Decision: Because connections to Horizon 7 will be authenticated at VMware Identity Manager and True SSO is used, the Unified Access Gateway must be configured with pass-through authentication. Otherwise True SSO would fail.

Multi-site Design

For this reference architecture, Unified Access Gateway virtual appliances were deployed in each of the sites in front of the Connection Servers to avoid any single point of failure.

Each Unified Access Gateway is deployed with a dual NIC configuration. The northbound connection is placed in the DMZ. The southbound connection is for the back-end network that in this case is also used for management purposes. Other deployment options are available for Unified Access Gateway, including single NIC.

The Unified Access Gateway pair for Connection Servers sits behind the F5 BIG-IP Local Traffic Manager (LTM) module that points user requests to an available Unified Access Gateway. Only the initial handshake over TLS is load balanced, but the actual client connection (Blast Extreme or PCoIP) is directed to the Unified Access Gateway the user gets connected to.

Affinity is based on source IP address and is configured only on the LTM layer because the Global Traffic Manager (GTM) flow checks only whether the LTM module of a given site is available or not. No affinity or session management occurs at the GTM layer; it is simply doing the initial placement based on geo-location of the user for external access. For internal access, the user is directed to one of the sites based on their client subnet value as defined by the VLAN (port group) associated with the desktop pool.

This allows for the control of the traffic flow for on-premises users because they are in known internal subnets and can be directed accordingly. For example, if GTM sees a connection associated with a subnet in Site 1, it directs the requests to Site 1 unless that site’s LTM instance is not responding to requests.

Prerequisites for Deployment

To facilitate a successful installation of Unified Access Gateway, various prerequisites must be in place prior to performing an installation. The following sections detail the prerequisites and deployment options available that satisfy the design requirements of this reference architecture.

Note: Only the options that satisfy the design requirements are described here. Other options are available and documented within the Unified Access Gateway documentation.

Virtual Appliance Requirements

Each Unified Access Gateway appliance has the following requirements:

  • 4 GB RAM
  • 2 vCPUs
  • 1–3 NICs
  • 20 GB disk space

Deployment Options

In this section, we briefly discuss the two supported methods of deploying Unified Access Gateway and then detail the optimal solution to satisfy the design requirements.

  • vSphere OVF template and administration console – With this option, you run the OVF (Open Virtualization Format) wizard and respond to various deployment questions. This method requires responses from an IT administrator during deployment. If you use this method, the Unified Access Gateway is not production-ready on first boot and requires post-deployment configuration using the administration console. The required configuration tasks can be performed either manually or by importing a configuration file from another Unified Access Gateway appliance.
  • PowerShell script – The PowerShell method ensures that the Unified Access Gateway virtual appliance is production-ready on first boot. This method uses the VMware OVF Tool command-line utility in the background. The IT administrator updates an INI file with the required configuration settings and then deploys the Unified Access Gateway by entering a simple deployment command in PowerShell (.\uagdeploy.ps1 .\<name>.ini) .

Design Decision: The PowerShell method is used because it satisfies most deployment scenarios and does not require the IT administrator to manually enter settings during the deployment.

To download the PowerShell script and sample INI files, see Using PowerShell to Deploy VMware Unified Access Gateway.

Required Deployment Information

Before deploying a Unified Access Gateway appliance, you must verify that certain prerequisites are met and provide the following information to deploy the appliance.

Certificates

Certificates are used to secure communications between the endpoint and the Unified Access Gateway and between the Unified Access Gateway and Connections Servers. If you plan to use the included self-signed certificate for the Connection Server, you will need to obtain the thumbprint information stored within the certificate.

Password Requirement

Unified Access Gateway requires the IT administrator to define two passwords during installation: The first secures access to the REST API, and the second secures access to the Unified Access Gateway appliance console. The passwords must meet the minimum requirements listed in the Unified Access Gateway documentation

vCenter Network Profiles

Regardless of the type of deployment chosen, vCenter Server network profiles are required for each network that the Unified Access Gateway is attached to. The network profile provides the following information:

  • Default gateway
  • Subnet mask
  • Subnet
  • DNS servers
  • DNS domain

IP Address and Fully Qualified Domain Name (FQDN)

As previously discussed, the Unified Access Gateway in this scenario is configured with two NICs:

  • Internet-facing IP address and external FQD
  • Back-end and management IP address and FQDN

Connection Server Information

This section details settings that are specific to a Unified Access Gateway and Horizon 7 installation.

  • Connection Server address – Unified Access Gateway must be able to contact the Connection Servers. In this deployment scenario, we use a load balancer (LB) to distribute the load evenly between the Connection Servers. The FQDN of the virtual IP (VIP) associated with the load balancer is specified during deployment of the Unified Access Gateway.
  • Connection Server thumbprint information if using self-signed certificates – If the Connection Servers are using certificates from a trusted CA, you can ignore this section. If your Connection Servers are using self-signed certificates or have a certificate from an untrusted CA, locate the thumbprint information stored within the certificate. Each thumbprint must be defined during deployment so that the Unified Access Gateway can trust connections to the Connection Server.

To find the thumbprint information, open the certificate on the Connection Server and look on the Details tab.

Certificate Thumbprint

Figure 81: Certificate Thumbprint

Unified Access Gateway Deployment and Initial Configuration

To meet with the design requirements, Unified Access Gateway is deployed based on the key decisions made.

The following table summarizes the key decision points.

Decision Point

Design Decision

Scalability

Two Unified Access Gateway appliances (n+1) were deployed to satisfy the requirement of 2,000 sessions and high availability.

Deployment method

The PowerShell method was used.

Load balancing

A load balancer was placed both in front of the Unified Access Gateway appliances and between the Unified Access Gateway appliances and the Connection Servers. SSL ID was used as the method to support session persistence and affinity.

For specific details on load balancing settings, see the Load Balancing section.

Authentication

Connections to Connection Servers were authenticated at VMware Identity Manager, and True SSO was used. Therefore, the Unified Access Gateway appliances were configured with pass-through authentication; otherwise True SSO would fail. This is the default authentication configuration for a Unified Access Gateway appliance.

Network architecture

To meet the requirements of separating Internet traffic from management and backend data, the Unified Access Gateway was deployed in dual-NIC mode.

Table 31: Unified Access Gateway Deployment Decisions

Deployment Steps

Follow these high-level steps in the order listed.

  1. Download and install the latest OVF Tools from my.vmware.com.
  2. Download the latest Unified Access Gateway OVA file from my.vmware.com.
  3. Go to Using PowerShell to Deploy VMware Unified Access Gateway. Download the latest version of the ZIP file and extract the contents. (At time of writing, this is uagdeploy-320-v5.zip).
  4. Make a copy and edit one of the sample INI files (such as uag2-advanced.ini).
  5. Enter your information as required for the [General] and [SSLCert] sections.
  6. Edit the edge service sections as required (for example the [Horizon] section).
  7. Run the script in PowerShell using the following command:
    .\uagdeploy.psl .\<filename>.ini 
  8. After the process is complete, wait a few minutes for the Unified Access Gateway appliance to boot completely.

You can monitor this process in the vSphere Web Client to see when the assigned IP address is reported on the summary page for the VM.

Log in to the Unified Access Gateway administration console to check the status of the configuration and service and to add or change the configuration. If you change any settings, such as adding a new edge service, remember to export the settings and update your INI file to reflect your changes.

For more information on deploying with the PowerShell method and the vSphere OVF Template method, see:

Firewall Rules

For a list of the firewall rules to consider when deploying Unified Access Gateway within a DMZ for access to Horizon 7 resources, see the tables in the NSX Distributed Firewall Rules for Horizon 7 section of Appendix C: NSX Manager Installation and Configuration. The required ports depend on the display protocols you plan to use.

For more information, including diagrams depicting the traffic flow, network ports, and different display protocols, see Network Ports in VMware Horizon 7.

Management Block

The Unified Access Gateway appliances reside within the management block and are placed in the management cluster. HA and DRS can be used to ensure the maximum availability of the appliances. DRS rules are configured to ensure that the devices do not reside on the same ESXi host; this strategy enhances high availability.

vSphere and Environment Infrastructure Design

VMware vSphere is the foundation that runs all the infrastructure and components. It also runs all the end services or resources that the users consume. All editions of Horizon 7 come bundled with vSphere for Desktops. Additionally, VMware vSAN Advanced is included in VMware Horizon 7 Advanced Edition and Horizon 7 Enterprise Edition.

This chapter describes how components of vSphere were used in this reference architecture, including the design for vSAN and NSX. 

  • vSAN pools its server-attached HDDs and SSDs to create a distributed shared datastore that abstracts the storage hardware and provides hyper-converged storage optimized for VMs without the need for external SAN or NAS.
  • NSX provides network-based services such as security, virtualization networking, routing, and switching in a single platform.

As might be expected, several environment resources are required to support a Workspace ONE deployment, including Active Directory, DNS, DHCP, security certificates, databases, and load balancers. For any external component that Workspace ONE depends on, the component must be designed to be scalable and highly available, as described in this chapter.

This lets us build in a hyper-converged hardware model based on a physical server as the building block. The server provides not only the compute and memory but also the storage in a modular fashion.

vSphere and vSAN High-Level Architecture

Figure 82: vSphere and vSAN High-Level Architecture

Horizon 7 deployments benefit from granular, elastic storage capacity that scales without forklift upgrades. Instead of having to add an entire storage array when more desktops are needed, we can simply add more disks, flash storage, or another vSphere host.

Although this reference architecture utilizes the benefits of an all-flash vSAN, traditional storage (such as SAN or NAS) is of course also still supported.

vSphere

This document does not try to cover vSphere design and installation. That is well documented in resources including the VMware vSphere documentation. Best practices around vSphere ESXi configuration and vSAN networking should be followed.

As outlined in the Architectural Principles, a Horizon 7 environment uses a pod and block design. A separate vSphere cluster is used to host the management server components. These server components could equally be placed on an existing vSphere cluster with sufficient capacity.

Each block then has one or more vSphere clusters to host and run resources such as virtual desktops and RDSH servers.

For the ESXi clusters hosting the Connection Server, other management servers, and vCenter Server VMs, vSphere DRS rules should be enabled to prevent the servers that perform identical operations from running on the same ESXi host. This prevents multiple VM failures if a host fails and these VMs exist on the failed physical ESXi host.

VM/Host Rules

Rule Setting

Type

Virtual Machines

Connection Server rule

Enabled

Separate VMs

horizon1
horizon2

Unified Access Gateway rule

Enabled

Separate VMs

uag1
uag2

vRealize Operations for Horizon rule

Enabled

Separate VMs

v4h1

v4h2

v4h3

VMware Identity Manager rule

Enabled

Separate VMs

idm1
idm2

idm3

VMware Identity Manager Connector rule

Enabled

Separate VMs

connector1

connector2

connector3

AirWatch Device Services rule

Enabled

Separate VMs

awdev1

awdev2

awdev3

awdev4

AirWatch Console Services rule

Enabled

Separate VMs

awcon1

awcon2

awcon3

AirWatch Memcached rule

Enabled

Separate VMs

memcached1

memcached2

App Volumes Manager rule

Enabled

Separate VMs

appvolumes1
appvolumes2

Table 32: vSphere DRS Rules

For this reference architecture, we also recommend the following settings.

vSphere DRS 

Setting 

vSphere DRS 

Turn on vSphere DRS 

DRS Automation 

Fully Automated 

Power Management 

Off 

Table 33: vSphere Distributed Resource Scheduler Settings

Leave all other DRS settings set to the default.

vSAN

vSAN pools its server-attached HDDs and SSDs to create a distributed shared datastore that abstracts the storage hardware and provides hyper-converged storage optimized for VMs without the need for external SAN or NAS.

vSAN uses VM-centric storage policies to automate the storage services levels on a per-VM basis. Horizon 7 integrates into this consumption model and automatically generates the required storage policies as pools are deployed onto a vSAN datastore. For best-practice recommendations, see the VMware Horizon 7 on VMware vSAN Best Practices technical white paper.

Networking

At a high level, all network components are configured redundantly to operate in either active/passive mode or active/active mode where allowed, and the various traffic types are separated from each other. Quality of service is controlled with network IO control (NIOC) on the configured distributed virtual switch.

vSphere Networking

Figure 83: vSphere Networking

The configuration uses 10-GbE adapters to simplify the networking infrastructure and remedy other 1-GB drawbacks such as inadequate bandwidth and lower utilization. Even with these 10-GbE advantages, it is still necessary to ensure that traffic flows can access sufficient bandwidth.

NIOC addresses this requirement by enabling diverse workloads to coexist on a single networking pipe, thus taking full advantage of 10 GbE. NIOC revolves around resource pools similar to those for CPU and memory. The vSphere administrator is given control to ensure predictable network performance when multiple traffic types contend for the same physical network resources.

Traffic Type

Shares

Shares Value

Reservation

Limit

Management traffic

Normal

50

0 Mbit/s

Unlimited

Virtual machine traffic

High

100

0 Mbit/s

Unlimited

vSAN traffic

Normal

50

0 Mbit/s

Unlimited

vMotion traffic

Normal

50

0 Mbit/s

Unlimited

Table 34: NIOC Configuration

Flow control is disabled for VMkernel interfaces tagged for vSAN (vmk2). vSAN networks can use teaming and failover policy to determine how traffic is distributed between physical adapters and how to reroute traffic in the event of adapter failure. NIC teaming is used mainly for high availability for vSAN. However, additional vSphere traffic types sharing the same team still leverage the aggregated bandwidth by distributing different types of traffic to different adapters within the team. Load-based teaming is used because network convergence on these switch ports can happen quickly after the failure due to the port entering the spanning-tree forwarding state immediately, bypassing the listening and learning states.

The following table shows the distributed switch and port group policies. 

Property 

Setting 

Default

Revised 

General 

Port Binding 

Static 

– 

Policies: Security 

Promiscuous mode 

Reject 

– 

MAC address changes 

Accept 

Reject 

Forged transmits 

Accept 

Reject 

Policies: Traffic Shaping 

Status 

Disabled 

– 

Policies: Teaming and Failover 

Load balancing 

Route based on the originating virtual port ID 

Route based on physical NIC load 

Failover detection 

Caution Link Status only 

– 

Notify switches 

Yes 

– 

Policies: Resource Allocation 

Network I/O Control 

Disabled 

Enabled 

Advanced 

Maximum MTU 

1500 

9000 

Table 35: Distributed Switch Settings

A single vSphere distributed switch was created with two 10-Gb interfaces in a team. Five port groups isolate network traffic: 

  • Virtual machines 
  • VMware ESXi management network 
  • VMware vSphere® vMotion® 
  • iSCSI 1 and iSCSI 2

Note: Two iSCSI port groups are required in order to configure vmknic-based iSCSI multi-pathing.

Quality of service is enforced with network I/O control (NIOC) on the distributed virtual switch, guaranteeing a share of bandwidth to each type of traffic. A vmkernel interface (vmknic) is created on the ESXi management port group, vSphere vMotion port group, and on each iSCSI port group.

Both 10-Gb adapters are configured as active/active for the VM port group, ESXi management network port group, and the vSphere vMotion port group.

  • The iSCSI 1 port group is bound to a single 10-Gb adapter, with only storage traffic permitted on that adapter.
  • The iSCSI 2 port group is bound to the second 10-Gb network adapter, with only storage traffic permitted over that adapter.

For more information, see the vSphere Networking guide and Configuring Flow Control on VMware ESXi and VMware ESX.

NSX for vSphere

NSX provides network-based services such as security, virtualization networking, routing, and switching in a single platform. These capabilities are delivered for the applications within a data center, regardless of the underlying physical network and without the need to modify the application. NSX provides key benefits to the Horizon 7 infrastructure components and the desktop environments.

As the following figure shows, NSX performs several security functions within a Horizon 7 solution:

  • Protects VDI infrastructure – NSX secures inter-component communication among the management components of a Horizon 7 infrastructure.
  • Protects desktop pool VM communication with enterprise applications – Virtual desktops contain applications that allow users to connect to various enterprise applications inside the data center. NSX secures and limits access to applications inside the data center from each desktop.
  • Provides user-based access control – NSX allows user-level identity-based micro-segmentation for the Horizon 7 desktops. This enables fine-grained access control and visibility for each desktop based on the individual user.

How NSX Protects a Horizon 7 Environment

Figure 84: How NSX Protects a Horizon 7 Environment

Design Overview

The following diagram shows how NSX and Horizon 7 components fit together.

Horizon 7 and NSX Topology

Figure 85: Horizon 7 and NSX Topology

The NSX platform consists of several components that make up the overall architecture. A highly scalable NSX infrastructure design is typically split into two clusters to create fault domains: the compute cluster and the management cluster. In a Horizon 7 design, however, we also have a desktop cluster.

  • The management cluster provides resources for the Horizon 7 and NSX management servers. 
  • The compute cluster provides compute hosts for the server data center environment.
  • The desktop cluster provides resources for building out VDI and RDSH servers for the Horizon 7 environment.

As is shown in the diagram, the server domain is separated from the desktop domain. The server domain houses the Horizon 7, NSX, and vCenter Server management components. The desktop domain houses the desktop and RDSH pools and server farms, along with the NSX Manager and vCenter Server for the desktop cluster. 

Design Decision: Because the Horizon 7 architecture provides a separation of the server and desktop domains, two NSX Managers are required to provide security for each of these domains. 

The following table lists the components of NSX that were used in this reference architecture.

Component

Description

NSX Manager

The management plane for the NSX platform. The software deployments and Distributed Firewall rules are configured and managed from here. NSX Manager is configured to communicate with a vCenter Server. 

  • The server domain NSX Manager secures the Horizon 7 management servers.
  • The desktop domain NSX Manager connects to an Active Directory domain controller to provide access for the NSX Identity Firewall. AD groups are used to provide the objects in which Distributed Firewall rule sets are built.

Database

NSX Manager uses an embedded database. There is no option to use an external database. To protect this database, use the NSX Manager administration console to schedule regular backups.

Distributed Firewall

A hypervisor kernel-embedded firewall that provides visibility and control for virtualized workloads and networks.

Identity Firewall

Allows an NSX administrator to create Active Directory user-based distributed firewall (DFW) rules

Table 36: NSX Components

Scalability

NSX Manager has the following scalability numbers:

  • vSphere hosts per vCenter Server: 512
  • DFW rules per NSX Manager: 100,000

NSX Manager has been tested to the following scalability numbers with using the identity firewall (IDFW):

  • Active Directory groups: 30,000
  • Users per Active Directory group: 250
  • VMs per vSphere host: 50
  • vSphere hosts per vCenter Server: 250
  • Active Directory security groups: 300
  • Active Directory groups per security group: 10
  • VMs per security group: 1,000

Key Design Considerations – Micro-segmentation

The concept of micro-segmentation takes network segmentation, typically done with physical devices such as routers, switches, and firewalls at the data center level, and applies the same services at the individual workload (or desktop) level, independent of network topology.

NSX and its Distributed Firewall feature are used to provide a network-least-privilege security model using micro-segmentation for traffic between workloads within the data center. NSX provides firewalling services, within the vSphere ESXi hypervisor kernel, where every virtual workload gets a stateful firewall at the virtual network card of the workload. This firewall provides the ability to apply extremely granular security policies to isolate and segment workloads regardless of and without changes to the underlying physical network infrastructure. 

Two foundational security needs must to be met to provide a network-least-privilege security posture with NSX micro-segmentation. NSX uses a distributed firewall (DFW) and can use network virtualization to deliver the following requirements. 

Isolation

Isolation can be applied for compliance, software life-cycle management, or general containment of workloads. In a virtualized environment, NSX can provide isolation by using the DFW to limit which workloads can communicate with each other. In the case of Horizon 7, NSX can block desktop-to-desktop communications, which are not typically recommended, with one simple firewall rule, regardless of the underlying physical network topology.

Isolation Between Desktops

Figure 86: Isolation Between Desktops

The specific rule that prevents all virtual desktops from communicating with each other is Rule 7 from Desktops Rule Set for VDI and RDSH in the NSX Distributed Firewall Rules for Horizon 7 section of Appendix C: NSX Manager Installation and Configuration.

Another isolation scenario, not configured in this reference architecture, entails isolating the Horizon 7 desktop and application pools. Collections of VDI and RDSH machines that are members of specific Horizon 7 pools and NSX security groups can be isolated at the pool level rather than per machine. Also, identity-based firewalling can be incorporated into the configuration, which builds on the isolation setup by applying firewall rules that depend on users’ Active Directory group membership, for example.

Segmentation

Segmentation can be applied at the VM, application, infrastructure, or network level with NSX. Segmentation is accomplished either by segmenting the environment into logical tiers, each on its own separate subnet using virtual networking, or by keeping the infrastructure components on the same subnet and using the NSX DFW to provide segmentation between them. When NSX micro-segmentation is coupled with Horizon 7, NSX can provide logical trust boundaries around the Horizon 7 infrastructure as well as provide segmentation for the infrastructure components and for the desktop pools. As an example, the following figure illustrates how segmentation could be used between logical tiers of an application. The same principles apply to Horizon 7 components.

Segmentation

Figure 87: Segmentation

The majority of the NSX firewall rules listed in Appendix C: NSX Manager Installation and Configuration are part of the segmentation model. For example, the table Desktops Rule Set for VDI and RDSH applies a set of rules that allow the Horizon 7, App Volumes, and User Environment Manager agents from the virtual desktop machines to communicate with their corresponding infrastructure components and services.

Another example can be found in the table Infrastructure Rule Set for App Volumes Manager, where the App Volumes Managers can communicate only with the SQL database servers, ESXi hosts, and vCenter Servers.

Advanced Services Insertion (Optional)

Although we did not use this option for this reference architecture, it warrants some discussion. As one of its key functionalities, NSX provides stateful DFW services at layers 2–4 for micro-segmentation. Customers who require higher-level inspection for their applications can leverage one or more NSX extensible network frameworks, in this case NetX, in conjunction with third-party next-generation firewall (NGFW) vendors for integration and traffic redirection. Specific traffic types can be sent to the NGFW vendor for deeper inspection or other services. 

The other network extensibility framework for NSX is Endpoint Security, EPSec. NSX uses EPsec for capabilities leveraged to provide enhanced agentless antivirus/malware or endpoint-monitoring functions from third-party security vendors as well. This integration is optional and in Horizon 7 deployments is beneficial for removing the need for AV/AM agents on the guest operating system. This functionality is provided by NSX through guest introspection, which is also leveraged to provide information for the identity firewall.

To implement guest introspection, a guest introspection VM must be deployed on each ESXi host in the desktop cluster. Also, the VMware Tools driver for guest introspection must be installed on each desktop or RDSH VM. 

Advanced Services

Figure 88: Advanced Services

Installation and Configuration

For an outline of the steps for installing and configuring NSX, see Appendix C: NSX Manager Installation and Configuration.

vSphere Infrastructure Design for Active/Active and Active/Passive Services

Standard vSphere design and installation should be followed to create a compute and storage platform to run Horizon 7 resources. This section describes the design used for a Horizon 7 multi-site deployment. For a vSAN stretched cluster, within a metro or campus network environment with low network latency between sites, see Appendix H: Active/Passive Service Using VMware vSAN Stretched Cluster.

The active/active and the active/passive services for a multi-site setup are based on separate sets of vSphere clusters in each site. The storage used was all-flash arrays. Horizon 7 Cloud Pod Architecture was used to give global entitlements across both sites. Details in this section are specific to the environments put in place to validate the designs in this guide. Different choices in some of the configurations, hardware, and components are to be expected.

The vSphere infrastructure is deployed identically in both data centers, following VMware best practices for pod and block design concepts. For further details, see the Architectural Principles and Concepts chapter.

Horizon 7 Pod and Block 

In the validation of this design, two data centers were built. Each site had two vSphere clusters, one for management VMs forming the management block and one for desktop and RDSH VMs that reside in the first resource block.

Horizon 7 Blocks

Figure 89: Horizon 7 Blocks

Storage 

When designing storage for a Horizon 7 environment, consideration should be given to the mixed workloads. There are management servers running in the management block and desktops and RDSH VMs running in the resource blocks. The storage selected should be able to 

  • Handle the overall I/O load and provide sufficient space.
  • Ensure performance for key components so that a noisy neighbor such as a desktop does not affect the performance of the environment.

Depending on the capability of the storage being used, it is generally recommended to separate these mixed workloads.

In the environment built to validate this reference architecture, the underlying physical storage, all-flash, was shared between the management block and the resource blocks running desktop and RDSH workloads. This was possible because all-flash storage can handle mixed workloads while still delivering great performance.

This approach can be seen in the following logical diagram.

All-Flash Storage Usage

Figure 90: All-Flash Storage Usage

Storage Replication 

For some components of the active/passive service, which uses two geographically dispersed sites, storage array data replication is necessary to provide complete business continuity.

If possible, use an asynchronous replication engine that can support bi-directional replication, which facilitates use of DR infrastructure for DR and production. VMware recommends using a replication engine that compares the last replicated snapshot to the new one and sends only incremental data between the two snapshots, thus reducing network traffic. Snapshots that can be deduplicated provide space efficiency.
Asynchronous Replication

Figure 91: Asynchronous Replication

VMware recommends replicating User Environment Manager data between sites. In the case of a site failure, a protected volume that is replicated to the DR site can be recovered promptly and presented. In the case of an active/active deployment, User Environment Manager volumes are replicated in each direction.

For optimal performance, VMware recommends implementing the advanced vSphere configuration changes outlined in the following table.

vSphere HA 

Setting 

vSphere HA 

Turn on vSphere HA 

Host Monitoring 

Enabled 

Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss” 

Disabled (default) 

Virtual Machine Monitoring 

Disabled (default) 

Table 37: vSphere High Availability (HA) Settings

Leave all other HA settings set to the default.

Environment Infrastructure Design

Several environment resources are required to support a Workspace ONE deployment. In most cases these will already exist. It is important to ensure that minimum version requirements are met and that any specific configuration for Workspace ONE is followed. For any external component that Workspace ONE depends on, the component must be designed to be scalable and highly available. Some key items are especially important when the environment is used for a multi-site deployment.

Active Directory

Workspace ONE and Horizon 7 require an Active Directory domain structure for user authentication and management. Standard best practices for an Active Directory deployment must be followed to ensure that it is highly available.

Because cross-site traffic should be avoided wherever possible, configure AD sites and services so that each subnet used for desktops and services is associated with the correct site. This guarantees that lookup requests, DNS resolution, and general use of AD are kept within a site where possible. This is especially important in terms of Microsoft Distributed File System Namespace (DFS-N) to control which specific file server users get referred to.

See the View Installation guide for details on supported versions and preparation steps.

Additionally, for Horizon 7, set up dedicated organizational units (OUs) for the machine accounts for virtual desktops and RDSH servers. Consider blocking inheritance on these OUs to stop any existing GPOs from having an undesired effect.

Group Policy

Group Policy objects (GPOs) can be used in a variety of ways to control and configure both Horizon 7 components and also standard Windows settings.

These policies are normally applied to the user or the computer Active Directory account, depending on where the objects are located in Active Directory. In a Horizon 7 environment, it is typical to set specific user policy settings for the specific Horizon 7 session only when a user connects to it.

We also want to have user accounts processed separately from computer accounts with GPOs. This is where the loopback policy is widely used in any GPO that also needs to configure user settings. This is particularly important with User Environment Manager. User Environment Manager applies only user settings, so if the User Environment Manager GPOs are applied to computer objects, loopback processing must be enabled.

Group policies can also be associated at a site level.

Refer to the Microsoft Web site for details.

DNS

The Domain Name System (DNS) is widely used in a Workspace ONE and Horizon 7 environment, from server components communication to clients and virtual desktops. Follow standard design principles for DNS, making it highly available. Additionally, ensure that:

  • Forward and reverse zones are working well.
  • Dynamic updates are enabled so that desktops register with DNS correctly.
  • Scavenging is enabled and tuned to cope with the rapid cloning and replacement of virtual desktops.

DHCP

In a Horizon 7 environment, desktops and RDSH servers rely on DHCP to get IP addressing information. DHCP must be allowed on the VM networks designated for these virtual desktops and RDSH servers.

In multi-site deployments, the number of desktops a given site is serving usually changes when a failover occurs. Typically, the recommendation is to over-allocate a DHCP range to allow for seamlessly recomposing pools and avoiding scenarios where IPs are not being released from the DHCP scope for whatever reason.

For example, take a scenario where 500 desktops are deployed in a single subnet in each site. This would normally require, at a minimum, a /23 subnet range for normal production. To ensure additional capacity in a failover scenario, a larger subnet, such as /21, might be used. The /21 subnet range would provide approximately 2,000 IP addresses, meeting the requirements for running all 1,000 desktops in either site during a failover while still leaving enough capacity should reservations not get released in a timely manner.

It is not a requirement that the total number of desktops be run in the same site during a failover, but this scenario was chosen to show the most extreme case of supporting the total number of desktops in each site during a failover.

There are other strategies for addressing this issue, for example, by using multiple /24 networks across multiple desktop pools or dedicating a subnet size you are comfortable using for a particular desktop pool. The most important consideration is that there be enough IP address leases available.

The environment can be quite fluid, with instant-clone desktops being deleted at logout and recreated when a pool dips below the minimum number. Because of this, we need to make sure the DHCP lease period is set to a relatively short period. The amount of time depends on the frequency of logouts and the lifetime of a clone.

Design Decision: DHCP must be available on the VM network for desktops and RDSH servers. DHCP failover is implemented to ensure availability. The lease duration of the scopes used is set to 4 hours (based on average logout after 8 hours).

Distributed File System

File shares are critical in delivering a consistent user experience. They are used to store various types of data used to configure or apply settings that contribute to a persistent-desktop experience.

The data can include the following types: 

  • IT configuration data, as specified in User Environment Manager
  • User settings and configuration data, which are collected by User Environment Manager
  • Windows mandatory profile 
  • User data (documents, and more) 
  • ThinApp packages 

The design requirement is to have no single point of failure within a site while replicating the above data types between the two data centers to ensure their availability in a site failure scenario. This reference architecture uses Microsoft Distributed File System Namespace (DFS-N) with array-level replication.

DFS Namespace 

The namespace is the referred entry point to the distributed file system.

  • A single entry point is enabled and active for profile-related shares to comply with the Microsoft support statements (for example, User Environment Manager user settings). 
  • Other entry points can be defined but disabled to stop user referrals to them. They can then be made active in a recovery scenario.
  • Multiple active entry points are possible for shares that contain data that is read-only for the users (for example, User Environment Manager IT configuration data, Windows mandatory profile, ThinApp packages).

More detail on how DFS design applies to profile data can be found in Component Design: User Environment Manager Architecture.

Certificate Authority

A Microsoft Enterprise Certificate Authority (CA) is often used for certificate-based authentication, SSO, and email protection. A certificate template is created within the Microsoft CA and is used by VMware AirWatch to sign certificate signing requests (CSR) that are issued to mobile devices through the Certificate Authority integration capabilities in VMware AirWatch and Active Directory Certificate Services.

The Microsoft CA can be used to create certificate-signing requests for Unified Access Gateway, VMware Identity Manager, and any other externally facing components. The CSR is then signed by a well-known external CA to ensure that any device connecting to the environment has access to a valid root certificate.

Having a Microsoft Enterprise CA is a prerequisite for Horizon True SSO. A certificate template is created within the Microsoft CA and is used by True SSO to sign CSRs that are generated by the VM. These certificates are short-lived (approximately 1 hour) and are used solely for the purpose of single-signing a user into a desktop without the user having to provide AD credentials when accessing through VMware Identity Manager.

Details on setting up a Microsoft CA can be found in the View Administration guide.

Design Decision:

A Microsoft Enterprise CA is set up to support certificate authentication for Windows 10 devices and to support the True SSO capability.

Microsoft RDS Licensing

Horizon 7 published applications use Microsoft RDSH servers as a shared server platform to host Windows applications. Microsoft RDSH servers require licensing through a Remote Desktop Licensing service. It is critical to ensure that the Remote Desktop Licensing service is highly available within each site and also redundant across sites.

Microsoft Key Management Service

To activate Windows (and Microsoft Office) licenses in a VDI environment, VMware recommends using Microsoft Key Management Service (KMS) with volume license keys. Because desktops are typically deleted at logout and are recreated frequently, it is important that this service be highly available. See the Microsoft documentation on how best to deploy volume activation. It is critical to ensure that the KMS service is highly available within each site and also redundant across sites. 

Design Decision: For this reference architecture, Microsoft Key Management Service (KMS) was deployed in a highly available manner to allow desktops and RDSH servers to activate their Microsoft licenses.

Database

As detailed in the component design section, several components require a database to store data and configuration. The database server needs to be highly available and scalable to match the demand. One option when using Microsoft SQL Server is to use clustering for HA.

Design Decision: Microsoft SQL Server was set up utilizing Microsoft Failover Clustering to ensure availability.

More information is available in the Microsoft guides on SQL Server Failover Cluster Installation.

Load Balancer

To remove a single point of failure from some components, we can deploy more than one instance and use a third-party load balancer. This not only provides redundancy but also allows the load and processing to be spread across multiple instances of the component. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for setup of multiple nodes in an HA or master/slave configuration.

Throughout this paper, in each of the sections specific to a component, the back-end design and the front-end access mechanism have been discussed to show how to design the components to be highly available both within a site and between sites, for example, by using Global Traffic Manager (GTM) from F5.

This section describes load balancing between the two sites in general and explains how the active/active service differs from the active/passive service in terms of persistence and end-user access.

All DNS services are running as Active Directory integrated zones on Windows Server 2016–based domain controllers with no changes beyond Microsoft best practices.

This reference architecture uses the following three global namespace resources: 

  • horizon.vmweuc.com 
  • avm.vmweuc.com 
  • my.vmweuc.com 

Those namespaces are delegated to the F5 BIG-IP DNS (GTM) function because it is effectively in charge of deciding where a user is directed based on the topology setup defined on F5 BIG-IP DNS for each of those services.

For guidance on how to configure F5 BIG-IP DNS (GTM) for the services listed above, refer to the following resources: 

Load Balancing for an Active/Active Service

The active/active service in this design uses the end user’s current physical location. Geo-location attributes align a user in Europe with a data center in Europe and a user in the U.S. with a U.S. data center.

When a user travels from, for example, Europe to the U.S., existing sessions are honored and re-connected, but new connections are always established with the data center closest to the user.

This kind of intelligent placement relies on the load balancer or geographic DNS capabilities, or both, to be functional. This is critical for the active/active service to ensure that a user is always getting a desktop in a data center closest to their current physical location.

The following figure presents a logical overview. The load balancer monitors both pods for availability and health-check status and then decides, based on availability and the end user’s physical location, where a session should be placed.

Multi-Geo Active/Active Load Balancing

Figure 92: Multi-Geo Active/Active Load Balancing 

Load Balancing for an Active/Passive Service 

User affinity for the active/passive service is based on the source IP address and is configured only on the Local Traffic Manager (LTM) layer because the F5 GTM flow checks only whether the LTM module of a given site is available. No affinity or session management occurs at the GTM layer. F5 GTM performs the initial placement based on the following: 

  • For external access, the geo-location of the user is considered.
  • For internal access, the user is directed to one of the sites based on their client subnet value as defined by the VLAN (port group) the desktop pool is associated with.

This allows for the control of the traffic flow for on-premises users because we know the internal IP subnets used and can direct users accordingly. For example, if F5 GTM sees a connection associated with a subnet in Site 1, it directs the requests to Site 1 unless that site’s LTM instance is not responding to requests.

Service Integration Design

At this stage, the Workspace ONE components have been designed, deployed, and the environment has all the functionality and qualities that are required. We can now proceed to creating the parts from each component and assembling and integrating them into the various services that are to be delivered to end users.

Some components are common to multiple services. To avoid repeating information common to each individual service, we outline the design of common components first.

VMware Identity Manager and VMware AirWatch Integration

To successfully integrate VMware Identity Manager and VMware AirWatch, you can use the Workspace ONE Getting Started wizards. The Enterprise Connector & Directory wizard walks you through setting up the VMware Enterprise Systems Connector to allow the components of Workspace ONE, VMware AirWatch, and VMware Identity Manager to communicate with your Active Directory.

Documentation for this process is available in the Guide to Deploying VMware Workspace ONE.

Common Application Service Components

Figure 93: Common Application Service Components

Enterprise Connector & Directory Integration Configuration Wizard

You can use the Workspace ONE wizards to set up the Enterprise Systems Connector, directory integration, and VMware Identity Manager integration.

Enterprise Connector & Directory Configuration Wizard

Figure 94: Enterprise Connector & Directory Configuration Wizard

The Enterprise Systems Connector is a unified connector consisting of AirWatch Cloud Connector (ACC) and VMware Identity Manager Connector. It is used in the Mobile Device Management service and the Mobile Productivity service. The Enterprise Systems Connector provides the ability to integrate VMware AirWatch and VMware Identity Manager with an organization’s back-end enterprise systems. It is enabled in the AirWatch Console and is downloaded to a Windows Server in the enterprise to enable communication between Active Directory and the Workspace ONE service. For more information, see the VMware Enterprise Systems Connector Installation and Configuration guide in the Installation & Architecture section of the VMware Identity Manager Documentation.

The Enterprise Connector & Directory wizard prompts you to set up a password before downloading the Enterprise Systems Connector installer. Use this password while running the installer on the VM.

Enterprise Systems Connector Setup Wizard

Figure 95: Enterprise Systems Connector Setup Wizard

Active Directory Integration

The next step after setting up the Enterprise Systems Connector is to enter your Active Directory and bind authentication information to integrate AD with VMware AirWatch. Because you are making connections from the Enterprise Systems Connector, ensure that networking and server IPs and hostnames can be resolved.

Active Directory Configuration Wizard

Figure 96: Active Directory Configuration Wizard

VMware Identity Manager Integration

In the final step of the configuration wizard, enter the fully qualified domain name and the authentication information for VMware Identity Manager. The AirWatch Admin Console servers must be able to reach the VMware Identity Manager servers in the DMZ through port 443. The VMware Identity Manager servers must be able to reach the AirWatch API servers through port 443.

VMware Identity Manager Configuration

Figure 97: VMware Identity Manager Configuration

Because you will be using the Enterprise Systems Connector to authenticate users directly in VMware Identity Manager, select No for the prompt to use VMware AirWatch to authenticate users.

Select No to Use AirWatch to Authenticate Users

Figure 98: Select No to Use AirWatch to Authenticate Users

VMware Identity Manager Connector Configuration

The VMware Identity Manager Connector provides connectivity to sync with the user directory, such as Active Directory. The VMware Identity Manager Connector also provides user authentication and integration with Horizon 7, along with following capabilities:

  • VMware Identity Manager Connector authentication methods, such as password, RSA Adaptive Authentication, RSA SecurID, and RADIUS
  • Kerberos authentication for internal users
  • Citrix-published resources

To set up the VMware Identity Manager Connector along with directory integration, see the VMware Identity Manager Connector Configuration section of the VMware Enterprise Systems Connector Installation and Configuration guide in the Installation & Architecture section of the VMware Identity Manager Documentation.

Catalog Population

The unified Workspace ONE app catalog contains many types of applications. SaaS-based SAML apps and VMware Horizon apps and desktops are delivered through the VMware Identity Manager catalog, and native mobile apps are delivered through the VMware AirWatch catalog.

VMware Identity Manager Catalog Resource

Configuration Considerations

SaaS Apps

  • To add a new SaaS application, go to the Catalog tab, select Web Apps from the drop-down list, and select New. Applications can be defined manually, or a predefined application template can be customized. See Adding a Web Application to Your Catalog in Setting Up Resources in VMware Identity Manager (On Premises) or Guide to Deploying VMware Workspace ONE.
  • You can manually create SaaS apps that do not have a template in the cloud catalog with appropriate parameters.
  • Entitle the appropriate users of the applications being published and choose whether the entitlement is automatic or manual.

View in Horizon 7

  • For the Mobile Application Workspace service, because Horizon 7 resources are published, the View application pools must be published. Entitlements are synced from the Horizon 7 environment to VMware Identity Manager. See Setting Up Resources in VMware Identity Manager (On Premises).
  • Horizon Connection Servers are added into the VMware Identity Manager catalog.
  • For external publishing, VMware Unified Access Gateway allows access to the Horizon 7 desktops and applications.

Table 38: Configuration Considerations for Populating the VMware Identity Manager Catalog

 

VMware AirWatch Catalog Resource

Configuration Considerations

Native Mobile Apps

  • In the AirWatch Console, you use the Apps and Books node to assign apps from the public app stores to their respective device platforms. Apps are defined by platform (iOS, Android, Windows, and more) and located in the app store for that platform.
  • The apps are then assigned to Smart Groups as appropriate.
  • Application configuration key values are provided to point the Workspace ONE app to the appropriate VMware Identity Manager tenant.
  • Recommended apps to deploy include the Workspace ONE app and popular VMware AirWatch apps, such as VMware Boxer, AirWatch Content Locker, and AirWatch Browser.

Table 39: Configuration Considerations for Populating the VMware AirWatch Catalog

Device Profiles – Single Sign-On

Device profiles provide key settings that are applied to devices as part of enrollment in VMware AirWatch. The settings include payloads, such as credentials, passcode requirements, and other parameters used to configure and secure devices. Different payloads are configured in different services for this document, but SSO is a common requirement across all devices and use cases

Device Profiles

Configuration Considerations

iOS SSO

  • The iOS platform uses the mobile SSO authentication adapter. The authentication adapter is enabled in VMware Identity Manager and added to an access policy. A profile is deployed that provides the appropriate certificate payloads to support trust between the user, the iOS device, VMware AirWatch, and VMware Identity Manager. For more information, see the Guide to Deploying VMware Workspace ONE.
  • Use the Mobile SSO Getting Started wizard to enable Mobile SSO in your environment.
  • The Mobile SSO wizard creates an SSO profile that uses a certificate issued by the AirWatch Certificate Authority.

Android SSO

  • Android uses the mobile SSO authentication adapter. It is enabled in VMware Identity Manager and added to an access policy. A profile is deployed to support SSO.
  • Use the Mobile SSO Getting Started wizard to enable Mobile SSO in your environment. For more information, see the Guide to Deploying VMware Workspace ONE.
  • The Mobile SSO wizard creates the necessary VMware Tunnel device profile, publishes the VMware Tunnel application, and creates the required network rules.

Windows 10 SSO

  • Windows 10 SSO uses certificate authentication. A certificate is generated from the AirWatch CA through a SCEP profile. When a device profile is deployed, the appropriate certificates are generated for the user and are installed on the user’s device. The certificate (cloud deployment) authentication adapter is enabled to use Windows 10 SSO. For more information, see the Guide to Deploying VMware Workspace ONE.
  • The user is prompted to select a certificate at Workspace ONE app launch.
  • For device compliance checking to function, part of the certificate request template for VMware AirWatch must include a SAN Type of DNS Name with a value of UDID={DeviceUid}.

Table 40: Configuration Considerations for Device Profiles in VMware AirWatch

The VMware Identity Manager directory synchronizes user account information from Active Directory and uses it for entitling applications to users through the Workspace ONE portal. For SSO and True SSO to work when integrating with VMware Identity Manager and Horizon 7, a number of configuration considerations must be taken into account.

Component

Configuration Considerations

VMware Identity Manager catalog

The VMware Identity Manager catalog is the launch point for applications through the Workspace ONE portal. Applications in the following categories are expected to be configured:

  • SaaS apps
  • ThinApps
  • Horizon 7 desktops
  • VMware Horizon apps
  • RDSH-published apps

True SSO

True SSO support is configured in VMware Identity Manager to ensure simple end-user access to desktops and apps without multiple login prompts and without requiring AD credentials.

Identity Manager and Connector appliances

VMware Identity Manager appliances are placed in the DMZ, and VMware Identity Manager Connectors are placed in the internal network in order to ensure that users external to the organization can access the resources that have been configured in the Workspace ONE catalog.

ThinApp packages

A ThinApp repository with ThinApp packages can allow use of ThinApp packages through the VMware Identity Manager catalog. ThinApp 4.7.2 and later packages are supported. You must install the VMware Identity Manager desktop in order to use ThinApp packages in your environment. For more information, see Integrating VMware ThinApp Packages in Setting Up Resources in VMware Identity Manager (On Premises).

SaaS-based web apps

SaaS-based applications that use SAML as an authentication method can be accessed through VMware Identity Manager. Configuration of applications is done through the templates in the cloud application catalog. See Setting Up Resources in VMware Identity Manager (On Premises).

Horizon 7 virtual desktops

Horizon 7–published applications

RDSH-published applications and their entitlements populate the VMware Identify Manager catalog when Horizon pods are configured as described for virtual desktops.

Cloud Pod Architecture

  • To configure VMware Identity Manager to work with Horizon Cloud Pod Architecture entitlements, each VMware Identity Manager connector must be able to access all Horizon pods within the global cluster.
  • In the VMware Identity Manager administration console, configure network ranges to reflect the site and external topology of your network.

For instructions, see Configure Horizon Pods and Pod Federations in VMware Identity Manager in Setting Up Resources in VMware Identity Manager (On Premises).

Kerberos authentication

  • To provide SSO to the VMware Identity Manager catalog, the appropriate authentication methods must be enabled.
    • The default authentication method is password, which prompts for the user’s Active Directory user ID and password.
    • If Kerberos is enabled as the default authentication method, the user’s Windows credentials are passed to VMware Identity Manager when users open the catalog.
  • Kerberos authentication must be enabled under the Connectors section in the administration console. See Implementing Kerberos for Desktops with Integrated Windows Authentication in the VMware Identity Manager Administration guide.

Access policies for Kerberos authentication

  • Access policies are configured to establish how to set up an operating system, network, or application to authenticate.
  • Use the Identity and Access Management tab to manage policies and edit the default access policy, as described in the Managing Access Policies section in the VMware Identity Manager Administration guide. For the web browser, choose Kerberos as the first authentication method, and Password for the second.
  • You might want to use different policies for different network ranges so that Kerberos is used for internal connections but other authentication methods are used for external connections.

Table 41: Configuration Considerations for Features in VMware Identity Manager

Workspace ONE Use Case Service Integration

The following table lists the parts required for each Workspace ONE service. The rest of this section details the design and configuration of each service.

 

Device Management Service

Mobile Productivity Service

Mobile Application Workspace Service

VMware Identity Manager

VMware AirWatch

VMware Enterprise Systems Connector

VMware Verify

 

Adaptive management

 

 

Device enrollment

 

Native mobile apps

SaaS apps

Unified app catalog

Mobile email management

 

 

Mobile content management

 

 

DLP restrictions

 

Secure browsing

 

 

Mobile SSO

Conditional access

 

VMware Horizon 7 or Horizon Cloud

 

 

VMware Unified Access Gateway

 

 

Table 42: Service Requirements

The two broad categories of application types are handled as follows:

  • SaaS applications – Are added from the Workspace One SaaS cloud catalog and are entitled to appropriate users.
  • Native mobile apps – Are added to the AirWatch Console. Privileged apps have the Require Management option selected; other apps do not.

Mobile Device Management Service

The Mobile Device Management service brings an organization that has minimal device management capabilities—such as Exchange ActiveSync policies applied for passcode, wipe, and other basic settings—under an MDM strategy.

The devices are initially configured to support adaptive management. Some less critical applications are enabled for SSO, while other applications are configured to require enrollment. Employees are encouraged, but not required, to enroll their devices. Users can use their native email clients, email apps available from the public app stores, or VMware Boxer.

Mobile Device Management Service

Figure 99: Mobile Device Management Service

Device Management Service Details

Configuration Considerations

Adaptive management

  • Adaptive management enables applications such as WebEx and Concur to be used with mobile SSO across all platforms without device enrollment. Other applications, such as HR sites, ADP, or Salesforce, require device enrollment to have a high degree of control over the device.
  • Users are encouraged to download the Workspace ONE app from a public app store.
  • Applications that are deemed to have a higher risk to user or company data are set to require management in the VMware AirWatch device profile.

Active Directory – Cloud Password Authentication

  • VMware Identity Manager is configured with a policy to use the cloud password from the built-in identity provider and authenticate through the Enterprise Systems Connector to the Active Directory account.

Email Access

  • Users are provided appropriate documentation on how to configure their device for native or third-party email client access.
  • If users choose to install VMware Boxer, their email configuration is automatically pushed to the device. Typically, users are provided with the Exchange ActiveSync Server address (outlook.office365.com) and their email address and password.

Enrollment

  • Enrollment is completed through the Workspace ONE application. If a user attempts to access an application that has been deployed as requiring management in VMware AirWatch, the enrollment process is initiated.
  • After enrollment in Workspace ONE, end users have all applications available to them. They can also use mobile SSO after they have enrolled because they have a device profile. This profile deploys the appropriate payloads to authenticate using the appropriate SSO technology.
  • Additional compliance information is passed to VMware Identity Manager. If the device is no longer in compliance, the user loses access to the VMware Identity Manager applications.

Table 43: Configuration Considerations for Device Management Service

Mobile Productivity Service

The Mobile Productivity service builds on the previous service in that it begins with devices that have been enrolled with the AirWatch Agent and are fully managed at deployment. When new devices are brought into the organization, they are essentially quarantined until enrolled.

Devices in this service have the following characteristics.

Mobile Productivity Service Details

Configuration Considerations

Device enrollment

All devices in the Mobile Productivity service are required to enroll using the AirWatch Agent. These devices are likely to have valuable enterprise data on them and so require a higher level of control and security.

Email restrictions

Native and third-party email apps are blocked, and all users use VMware Boxer for increased security.

Content access

AirWatch Content Locker is pushed to the device and configured for secure access to corporate repositories.

Secure browsing

AirWatch Browser is pushed to the device to ensure that links to intranet sites are always opened in a secure browser.

Email access

Email and content are delivered from Microsoft Office 365, so federation with the Microsoft Office 365 service is enabled to allow SSO to the Office service and native mobile Microsoft Office 365 apps.

Data loss prevention

DLP components are enabled within AirWatch Content Locker and VMware Boxer to prevent the use of unapproved applications, ensuring that data cannot be inadvertently or purposely copied and pasted into other apps.

Multifactor authentication

Multifactor authentication through VMware Verify is used when users need to access the Workspace ONE application and they are in a network range that is not within the corporate network. On corporate WiFi, users need only mobile SSO-based authentication. VMware Verify is also required on personally owned, non-managed PCs using only the browser to access SaaS apps.

Table 44: Configuration Considerations for Mobile Productivity Services

Mobile Productivity Service

Figure 100: Mobile Productivity Service

Microsoft Office 365 Federation

Configuration Considerations

Federation to Microsoft Office 365

Enable Federation in the Microsoft Office 365 or Azure AD Portals

  • Sync Active Directory user accounts through the Azure AD or Microsoft Office 365 portals.
  • Use PowerShell scripting to configure the Microsoft Office 365 service to authenticate through Workspace One as a federated identity provider. A set of PowerShell scripts with appropriate parameters and signing certificates establish trust between Microsoft Office 365 and VMware Identity Manager.
  • Note: An important criterion to make Microsoft Office 365 integration work is ensuring that the attribute ObjectGUID is synced from AD to the VMware Identity Manager service.

Configure Microsoft Office 365 Apps in VMware Identity Manager

  • Using the templates in the Cloud Application Catalog, configure the Microsoft Office 365, WS-fed based template to allow authentication against VMware Identity Manager for Microsoft Office 365-based apps and resources, such as email, SharePoint Online, Skype for Business, and other Microsoft Services.

Table 45: Configuration Considerations for Microsoft Office 365 Federation

 

Email Configuration

Configuration Considerations

Email integration with Microsoft Office 365 through PowerShell

VMware AirWatch issues commands through PowerShell to Exchange in Microsoft Office 365. Devices communicate directly with Exchange ActiveSync in the Microsoft Office 365 service. Full configuration information is in the VMware AirWatch PowerShell Integration Guide in the Email Management section of the Workspace ONE UEM Documentation.

PowerShell Roles in Office 365

PowerShell requires specific roles to be established in the Microsoft Office 365 administration portal for Exchange. These roles enable the execution of PowerShell commandlets from VMware AirWatch to the Microsoft Office 365 service.

Blocking and quarantine rules

To prevent unauthorized devices from connecting to the Exchange Server, you can block or quarantine devices until they have enrolled. PowerShell commands are used to set the appropriate policy. These rules are not needed for environments where enrollment is not required.

Email compliance policies

Compliance policies for email include a range of options for controlling managed and unmanaged devices:

  • Must the device be enrolled to perform email sync?
  • Which email clients are allowed to sync email?
  • Is device encryption required for email sync?
  • Are jail-broken or otherwise compromised devices allowed?

ActiveSync profiles for email Clients

  • To enable email sync, you must configure the Exchange ActiveSync payload for the device profiles. The hostname for Microsoft Office 365 is typically outlook.office365.com.
  • The domain, username, and email address are configured with lookup values. Make sure that these values are available in the directory and are properly mapped from AD through the VMware Enterprise Systems Connector.

Table 46: Configuration Considerations for Email

 

Content Configuration

Configuration Considerations

Content integration with Microsoft Office 365

  • Integration is established through the AirWatch Console under the Content node.
  • From here, you configure templates for the SharePoint libraries in Microsoft Office 365, to sync to the mobile devices.
  • Full configuration information is in the most recent VMware AirWatch Mobile Content Management (MCM) Guide in the Content Management section of the Workspace ONE UEM Documentation.

Office 365 SharePoint document libraries

Use https://portal.office.com to log in to Microsoft Office 365 and create SharePoint sites with document libraries containing content.

Content templates in AirWatch for automatic deployment

To create these templates:

  • In the AirWatch Console, access the Content node, select Templates, and then select Automatic.
  • Configure SharePoint Office 365 as the repository type.
  • Configure the Link field with the path to the SharePoint document library. For example, https://<domain>.sharepoint.com/Sales_Material/Shared%20Documents
  • Enable Allow Write if read/write access is needed.
  • If content is synced, choose Allow Offline Viewing.
  • If content is used with other apps, select Allow Open in Third Party Apps.
  • Review other security settings per your enterprise policy.
  • Assign appropriate groups to the repository.

For more information, see the VMware AirWatch Mobile Content Management (MCM) Guide in the Content Management section of the Workspace ONE UEM Documentation.

AirWatch Content Locker

To ensure access to content, require that AirWatch Content Locker be automatically deployed to groups who use SharePoint.

Table 47: Configuration Considerations for Content

 

Data Loss Prevention Configuration

Configuration Considerations

DLP configuration on a global basis

  • You can set DLP configuration on a global basis, platform basis, or per application deployment.
  • For DLP settings to take effect, the application must be built with the AirWatch SDK, or, for an internal application, DLP settings must be supported through app wrapping.
  • VMware Boxer, AirWatch Content Locker, and AirWatch Browser are built using the AirWatch SDK and honor the settings chosen.

SDK profile defaults for iOS or Android

SDK profiles allow global configuration of DLP settings that are applied to applications on the platform for which the profile is defined. Policy settings include enabling or disabling:

  • Printing
  • Composing email
  • Location services
  • Data backup
  • Camera
  • Watermarking
  • Ability to open documents in certain apps

Custom policies for AirWatch Content Locker and VMware Boxer

AirWatch Content Locker can use the default policies defined in the SDK profile, or defaults can be overridden by enabling custom policies. Requiring MDM enrollment ensures that content is accessed only by enrolled devices.

Email compliance policies

When configuring AirWatch Content Locker policies, verify that the email compliance policies match corporate standards, including whether devices must be enrolled in device management to receive email.

Table 48: Configuration Considerations for Data Loss Prevention

 

VMware Verify Configuration

Configuration Considerations

Authentication Adapter in VMware Identity Manager

VMware Verify is an authentication method within VMware Identity Manager. You must enable the built-in authentication adapter by selecting a check box.

Access policies

To use an authentication method, you add it to a policy. You can configure VMware Verify as a standalone authentication method in a policy, but it is typically chained with other methods to implement multifactor authentication.

To use VMware Verify in conjunction with mobile SSO for iOS, click the + icon and add VMware Verify. After authenticating through mobile SSO, users are prompted for VMware Verify credentials.

Installation

VMware Verify is available from the Apple App Store, Google Play, and as an add-in for Chrome on Windows and macOS.

Device enrollment

When users access VMware Verify for the first time, they are asked for a phone number. The phone number is then associated with the VMware Identity Manager service, and a notification is sent to the user’s device to enroll it.

After enrollment, the user’s phone is issued an authentication token. If the phone can receive push notifications, it lets the user choose to allow or reject the authentication.

Registration of additional devices

You can register additional devices for the end user by leveraging a previously registered device. During registration of an additional device, an authentication request is sent to a previously registered device for verification.

Table 49: Configuration Considerations for VMware Verify

 

Conditional Access and Compliance Policies

Configuration Considerations

VMware AirWatch compliance

  • Create a compliance policy for the appropriate platforms through the AirWatch Console. Criteria for evaluation can include jail-broken or rooted devices, devices that have not checked into the AirWatch environment in a period of time, or the installation of blacklisted applications.
  • The policy can include an escalation of notifications as actions, starting with an email notification to the user, followed by an email notification to an administrator, and ultimately blocked access to email if the device is not remediated in time.

VMware Identity Manager compliance

  •  VMware Identity Manager compliance checking is enabled through policy configuration. Policies include device compliance with the AirWatch authentication adapter and other authentication methods, such as a password.
  • You can use the policies in conjunction with network ranges, OS platforms, or specific applications, allowing varying requirements to evaluate whether an application can launch based on where users are, which device they are using, and how they are authenticating.

Table 50: Configuration Considerations for Access and Compliance Policies

Mobile Application Workspace Service

The Mobile Application Workspace service has a similar configuration to the Mobile Productivity service, but also includes access to VMware Horizon applications. VMware Horizon resources can be synced with Workspace ONE through an outbound-only connection from the Enterprise Systems Connector. This method allows entitlements to sync to the service. Inbound access to the Horizon Connection Servers, virtual desktops, and applications is still required. Therefore, VMware Unified Access Gateway is also part of this solution.

Components in the Mobile Application Workspace have the following unique characteristics.

Mobile Application Workspace Service Details

VMware Identity Manager Connector

The connector component of VMware Identity Manager is delivered as a virtual appliance or is installed and run as a service on a Windows server. The connector is deployed within the internal network and integrates with your enterprise directory to sync users and groups to the VMware Identity Manager service and to provide authentication.

VMware Horizon Entitlements

Entitlements are enabled through the VMware Identity Manager catalog by connecting to Horizon pods that expose user-entitled apps and desktops to both Horizon Cloud and Horizon 7.

VMware Unified Access Gateway

This component enables external Horizon Clients to securely access on-premises-based Horizon 7 resources for virtual apps and desktops.

Table 51: Unique Characteristics of the Mobile Application Workspace Service

Mobile Application Workspace Service

Figure 101: Mobile Application Workspace Service

VMware Identity Manager Configuration

Configuration Considerations

Enterprise Systems Connector deployment

  • The connector component of VMware Identity Manager is delivered as a virtual appliance or is installed and run as a service on a Windows server. The connector is deployed within the internal network and integrates with your enterprise directory to sync users and groups to the VMware Identity Manager service and to provide authentication. Instructions for deploying the connector are in the Deploying VMware Identity Manager Connector in the Enterprise Network section of the Deploying VMware Identity Manager in the DMZ guide in the Installation & Architecture section of the VMware Identity Manager Documentation.
  • The connector can support View entitlement sync when configured as an outbound-only connector, which does not require inbound ports opened at the network perimeter beyond the ports required to access virtual desktop and application resources. Instructions for enabling the outbound-only authentication adapters are in Using Built-In Identity Providers in the VMware Identity Manager Administration Guide.
  • This authentication method, when enabled, is referred to as Password (Cloud Deployment). See Using Outbound Connector for Authentication in Built-in Identity Providers in the VMware Identity Manager Administration Guide.

Directory sync

After the connector is deployed, directory synchronization is performed to sync Active Directory users and groups with the VMware Identity Manager service. For more information, see Set Up a Directory in VMware Enterprise Systems Connector Installation and Configuration.

Access to Horizon 7 desktops and applications in the Workspace ONE App Catalog

To make Horizon 7 resources available in the Workspace ONE app, you create one or more virtual apps collections in the VMware Identity Manager administration console. The collections contain the configuration information for the Horizon 7 pods and pod federations, as well as sync settings. See Configuring Horizon Pods and Pod Federations in VMware Identity Manager in Setting Up Resources in VMware Identity Manager (On Premises).

User entitlements for apps and desktops are made available through the VMware Horizon configuration and automatically appear in the Workspace ONE app and in a web browser.

Access to VMware Horizon 7 from external devices

  • To access the resources made available through VMware Horizon, you must establish a means of access from Internet-based devices.
  • You can configure VMware Unified Access Gateway along with True SSO to allow egress and provide connectivity to the VMware Horizon 7 Connection Servers. See Deploying and Configuring Unified Access Gateway.

Table 52: Configuration Considerations for VMware Identity Manager

 

Client Configuration

Configuration Considerations

VMware Horizon Client Native App

When using VMware Horizon resources in Workspace ONE, the resources appear on the Launcher page of the apps, but the resources launch using the VMware Horizon Client native mobile apps. For environments planning to access VMware Horizon–based apps and desktops, an automatic deployment of the native clients is recommended.

Table 53: Configuration Considerations for VMware Horizon Client

Horizon 7 Use Case Service Integration

The following table details the parts required for each Horizon 7–based service. The rest of this section details the design and build of each of these services.

 

Business Process Application Service

Mobile Secure Workspace Service

Dedicated Power Workspace Service

Developer Workspace Service

High-Performance Workspace Service

Windows 10 instant clone

 

 

RDSH instant clone

 

 

 

 

Linux clone

 

 

 

 

App Volumes AppStack

 

App Volumes writable volume

 

 

 

User Environment Manager

 

Smart Policies

 

Application blocking

 

 

Folder redirection

 

Mandatory profile

 

GPO

 

Virtual printing (ThinPrint)

 

ThinApp Packages

 

SaaS apps

 

 

Unified Access Gateway

 

True SSO

 

 

vGPU

 

 

 

 

NSX Firewall

Optional

Optional

Optional

Optional

Optional

Table 54: Components Required by Horizon 7 Services

Multiple Horizon 7 services can use the same underlying desktop pool type (core service). When there is no variation in the hardware specifications of the desktop, you can reuse the same pool to address multiple use cases. App Volumes and User Environment Manager can provide the customization to the use case.

Business Process Application Service

This service is created for static task workers, who require a small number of Windows applications and location-aware printing capabilities.

Core Service

The core service consists of RDSH-published applications that are made available to end users through the Workspace ONE app catalog.

Business Process Application Service

Figure 102: Business Process Application Service – Core

 

RDSH Instant Clone

Configuration Considerations

Windows 2016 master VM

Build a Windows 2016 VM using the guidelines in Building a Master VM Template in Appendix B: Horizon 7 Configuration.

Automated RDSH farm

Table 55: Configuration Considerations for RDSH-Published Applications

Applications

The actual applications available from the RDSH farm can either be applications installed in the master VM image or part of App Volumes AppStacks that are attached to the RDSH server at system startup. Because we use instant clones of RDSH servers, App Volumes can save us the trouble of installing the same applications on each node. We assign the AppStack containing the core applications, and each RDSH instant-clone server has the same application set for publishing.

Business Process Application Service – Applications

Figure 103: Business Process Application Service – Applications

 

App Volumes

Configuration Considerations

Overview

Create AppStacks as required to address the use cases.

With RDSH instant clones, App Volumes saves us from needing to install the same applications on each node. We assign the AppStack containing the core applications so that each RDSH instant-clone server has the same application set for publishing.

Provisioning machine

Because the AppStacks are created for an RDSH server, each AppStack must be captured on the same operating system (we used Windows Server 2016) to ensure that applications are compatible with the OS that they are being attached to.

Core applications

  • Create an AppStack to contain all core applications to be delivered as RDSH-published applications. Follow the instructions in Working with AppStacks in the VMware App Volumes Administration Guide for details.
  • These AppStack-delivered applications are published through RDSH.
  • Assign and entitle the AppStacks to an Active Directory group containing the RDSH server machine accounts—these are machine-based assignments.

Application pool

Table 56: Configuration Considerations AppStacks in the Business Process Application Service

Profile and User Data

With User Environment Manager, a combination of the mandatory profile, Windows and application environment settings, user preference settings, and folder redirection work together to create and maintain the user profile.

Profile and User Data

Figure 104: Business Process Application Service – Profile and User Data

For detailed instructions for all of the tasks mentioned in the following table, see the VMware User Environment Manager Administration Guide.

 

Profiles

Configuration Considerations

Mandatory profile

Set up a mandatory profile, and use a group policy to assign it to the OU that contains the desktop objects. See Mandatory Profile in Appendix B: Horizon 7 Configuration.

Environment settings

  • Map the H: drive to the users’ home drive with User Environment Manager.
  • Map location-based printers with User Environment Manager, according to the IP address range.

Personalization applications

  • Verify that User Environment Manager Flex configuration files are created and configured properly for each application that allows users to save preference settings.
  • Verify that each application that persists user settings across sessions has a User Environment Manager Flex configuration file.
  • If a User Environment Manager Flex configuration file does not exist, use the Application Profiler to create one and place it in the configuration share.

Folder redirection

Folder redirection is configured from User Environment Manager, which redirects user profile folders to a file share so that user data persists across sessions. See User Environment Manager Group Policy Settings in Appendix B: Horizon 7 Configuration.

Smart Policies

Leverage Horizon Smart Policies to apply the Internal Horizon Smart Policy profile, which allows USB, copy and paste, client-drive redirection, and printing. See User Environment Manager Smart Policies in Appendix B: Horizon 7 Configuration.

Table 57: Configuration Considerations for User Profiles in the Business Process Application Service

Mobile Secure Workspace Service

This service is created for mobile knowledge workers and contractors, who require a large number of core and departmental applications, require access from many external locations, and might need access to USB devices.

Core Service

The core service consists of a Windows 10 virtual desktop made available to end users through the Workspace ONE app catalog.

Mobile Secure Workspace Service

Figure 105: Mobile Secure Workspace Service – Core

 

Windows 10 Instant Clone

Configuration Considerations

Windows 10 master VM

Build a Windows 10 VM using the guidelines in Building a Master VM Template in Appendix B: Horizon 7 Configuration.

Automated desktop pool

Table 58: Configuration Considerations for Windows 10 Instant-Clone Desktops

Applications

The majority of applications are delivered through App Volumes, with core and different departmental versions. Individual or conflicting applications are packaged with ThinApp and available through the Workspace ONE app catalog.

Mobile Secure Workspace Service – Applications

Figure 106: Mobile Secure Workspace Service – Applications

 

App Volumes

Configuration Considerations

Core applications

Departmental applications

  • Create an AppStack for each department containing unique applications to them.
  • Assign and entitle relevant user groups to their matching departmental AppStack.

Table 59: Configuration Considerations for AppStacks in the Mobile Secure Workspace Service

Profile and User Data

This service uses the same structure and design for profile and user data as outlined in Mobile Secure Workspace Service.

Policy

Profiles

Configuration Considerations

Smart Policies

  • Mobile knowledge worker:
    • Internal location: Apply an internal Horizon Smart Policy.
    • External location: Apply an external Horizon Smart Policy.
  • Contractors: Apply the restrictive zContractor Horizon Smart Policy at all times.
    Note: Smart Policies are evaluated in alphabetical order. Adding the z character before Contractor places the policy name at the bottom of the sort group. For examples, see User Environment Manager Smart Policies in Appendix B: Horizon 7 Configuration.

Application blocking

Leverage application blocking in User Environment Manager to block the following executables:

  • Regedit.exe
  • Cmd.exe

Group policies

No specific group policies.

Table 60: Configuration Considerations for User Profiles in the Mobile Secure Workspace Service

Dedicated Power Workspace Service

The Dedicated Power Workspace service uses a similar integration as the Mobile Secure Workspace Service described earlier, with the addition of an App Volumes writable volume.

Applications

The majority of applications are delivered through App Volumes, with core and different departmental versions. Individual or conflicting applications are packaged with ThinApp. For user-installed applications, the user gets an App Volumes writable volume.

Dedicated Power Workspace Service – Applications

Figure 107: Dedicated Power Workspace Service – Applications

 

App Volumes

Configuration Considerations

Core applications

  • Create an AppStack to contain all core applications. For details, see Working with AppStacks in the VMware App Volumes Administration Guide.
  • Assign and entitle the AppStack to an Active Directory group.

Departmental applications

  • Create an AppStack for each department containing unique applications for that department.
  • Assign and entitle relevant user groups to their matching departmental AppStack.

Writable volumes

Create writable volumes for each user (or for the user group) entitled to this desktop pool. This writable volume can capture any user-installed application and persist the application across user sessions. See Working with Writable Volumes in the VMware App Volumes Administration Guide.

Table 61: Configuration Considerations for AppStacks and Writable Volumes in the Dedicated Power Workspace Service

Profile and User Data

This service uses the same structure and design for profile and user data as outlined in Mobile Secure Workspace Service.

Policy

Profiles

Configuration Considerations

Smart Policies

Software developer:

  • Internal location: Apply an internal Horizon Smart Policy.
  • External location: Apply an external Horizon Smart Policy.

IT (power user):

  • Internal location: Apply an internal Horizon Smart Policy.
  • External location: Apply an external Horizon Smart Policy.

See User Environment Manager Smart Policies in Appendix B: Horizon 7 Configuration.

Application blocking

No application blocking settings.

Group policies

No specific group policies.

Table 62: Configuration Considerations for User Profiles in the Dedicated Power Workspace Service

Developer Workspace Service

VMware Horizon for Linux centralizes desktop management and secures data in the data center while supporting end users with seamless access to Linux services across devices, locations, mediums, and connections. Furthermore, this solution allows organizations to move away from costly Windows licensing and to embrace low-cost endpoints to deliver the best possible total cost of ownership.

Core Service and Apps

The core desktop is a full clone of a Linux VM that already has applications installed. Applications can be preinstalled in the master VM, and users can add their own applications to their individual clones. Desktops are persistent to the user.

Developer Workspace Service – Core and Apps

Figure 108: Developer Workspace Service – Core and Apps

 

Linux Clone

Configuration Considerations

Linux master VM

Follow the instructions in Create a Virtual Machine Template for Cloning Linux Desktop Machines in Setting Up Horizon 7 for Linux Desktops.

Customization specification

Follow the instructions in Create a Customization Specification for Linux in the vSphere Virtual Machine Administration Guide.

All applications

Install all needed applications on the master VM.

Cloned VM

Follow the instructions in Sample Script to Clone Linux Virtual Machines in Setting Up Horizon 7 for Linux Desktops.

Domain join

Follow the instructions in Sample Script to Join Cloned Virtual Machines to AD Domain in Setting Up Horizon 7 for Linux Desktops.

3D rendering (optional)

Follow the instructions in Configure Supported RHEL Distributions for vGPU in Setting Up Horizon 7 for Linux Desktops.

Horizon Agent

Follow the instructions in Install Horizon Agent on a Linux Virtual Machine in Setting Up Horizon 7 for Linux Desktops.

Configuration options

Follow the instructions in Sample Script to Upload Configuration Files to Linux Virtual Machines in Setting Up Horizon 7 for Linux Desktops.

Desktop pool

Follow the instructions in Create a Manual Desktop Pool for Linux in Setting Up Horizon 7 for Linux Desktops.

Table 63: Configuration Considerations for the Linux VM in the Developer Workspace Service

User Data

Users can reach their Windows user data from their file shares. For automount on Red Hat Enterprise Linux, see AUTOFS.

Developer Workspace Service – User Data

Figure 109: Developer Workspace Service – User Data

High-Performance Workspace Service

This service is similar to the Dedicated Power Workspace service but has more CPU and memory and can use hardware-accelerated rendering with NVIDIA GRID graphics cards installed in the vSphere servers (vGPU).

Core Service

The core is constructed using Horizon 7 instant clones. A master VM is configured, and a snapshot is taken. The snapshot is cloned to the replica, which is shared by all of the instant clones. The clones access the replica in read-only mode and save any changes to the instant-clone delta files. Because we are using folder redirection, there should be little data stored on the instant clones.

High-Performance Workspace Service – Core

Figure 110: High-Performance Workspace Service – Core

When creating the master VM, you must prepare the VM for NVIDIA GRID vGPU capabilities. Follow the steps in Preparing for NVIDIA GRID vGPU Capabilities in Setting Up Virtual Desktops in Horizon 7, and select the appropriate graphics profile, depending on the requirements. To understand the profile choices, see the VMware Compatibility Guide and the NVIDIA website.

At pool creation, chose NVIDIA GRID vGPU as the 3D Renderer option. The clones will use the same graphics profile that was selected during master VM creation.

We must also configure DRS and affinity rules to ensure that these desktops always remain on hosts that have NVIDIA cards.

Windows 10 Instant Clone

Configuration Considerations

Windows 10 master VM

Automated desktop pool

Table 64: Configuration Considerations for the Windows 10 VM in the High-Performance Workspace Service

Applications

This service uses the same application types as the Dedicated Power Workspace service above. Departmental AppStacks can be created for specific applications required by that department.

High-Performance Workspace Service – Applications

Figure 111: High-Performance Workspace Service – Applications

Profile and User Data

This service uses the same structure and design for profile and user data as was outlined previously in Mobile Secure Workspace Service.

Policy

Profiles

Configuration Considerations

Smart Policies

Multimedia Designer:

  • Internal location: Apply an internal Horizon Smart Policy.
  • External location: Apply external Horizon Smart Policy.

For examples, see User Environment Manager Smart Policies in Appendix B: Horizon 7 Configuration.

Application blocking

No application blocking settings.

Group policies

No specific group policies.

Table 65: Configuration Considerations for User Profiles in the High-Performance Workspace Service

Recovery Service Integration

At this stage, we have all of the disaster recovery components designed and deployed, and the environment should have all the functionality and qualities that are required to deliver the services defined earlier. The components required can now be created, assembled, and integrated into the recovery services to be mapped against the use case services that are consumed by end users.

Some of these steps might have already been completed while creating the use case services described earlier.

Recovery Services for Horizon 7 Use Cases

The following table details the components required for each recovery service. Some are optional, as indicated in the Recovery Services section of the Service Definitions chapter. The rest of this section details the steps for implementing each of the recovery service types.

Note: This section details the components of a multi-site active/active and active/passive deployment. For component details of a vSAN stretched active/passive service, within a metro or campus network environment with low network latency between sites, see Appendix H: Active/Passive Service Using VMware vSAN Stretched Cluster.

Component 

Active/Active Recovery Service 

Active/ Passive Recovery Service 

vSAN Stretched Active/ Passive Service 

VMware Identity Manager 

 

X

X

Windows instant clone 

X

X

 

Windows linked clone 

X

X

 

RDSH linked clone 

X

X

 

Windows full clone 

 

 

X

App Volumes AppStack 

X

X

 

App Volumes writable volume 

 

X

 

User Environment Manager 

X

X

 

Folder redirection 

X

X

X

Mandatory profile 

X

X

X

Storage replication (active/active) 

 

X

X

vSAN stretched cluster 

 

 

X

Table 66: Recovery Service Components

Some parts are prerequisites for any of the services. Ensure that these services are configured and functional before looking at the specifics for a given service: 

  • User Environment Manager GPO (ADMX) configuration 
  • DFS namespace (for User Environment Manager profile global access) 
  • Storage array replication
  • Mandatory profile 
  • SQL Server Always On (for App Volumes and VMware Identity Manager databases) 
  • Load balancing between sites 
  • Load balancing within sites 

Active/Passive Recovery Service 

This section covers the high-level steps required to build out the active/passive service, which can be seen from a blueprint perspective below.

Active/Passive Recovery Service Components

Figure 112: Active/Passive Recovery Service Components

Desktops and RDSH-Published Applications 

The first step is to create the Windows component of the service. This consists of either desktops or RDSH servers in pools or farms at both sites. Cloud Pod Architecture is then configured to provide a global entitlement to pools of desktops and published applications from both sites.

Step 

Details 

Load balancing 

Verify both global and local load balancing are functional.

Master VM 

Build out a master VM image in Site 1 to meet requirements.

Replicate the master VM image to Site 2.

Create pools or farms 

For desktops, create identical desktop pools in both sites based on the master VM.

 

For RDSH-published applications: 

  • Create RDSH server farms in both sites using the master VM image. 
  • Add application pools in both sites containing the required applications. 

Cloud Pod Architecture 

Set up and initialize Cloud Pod Architecture between the two sites.

  • Create sites and assign the pods to their respective sites. 
  • Create global entitlements. 
  • Associate pools from both sites. 

Table 67: Steps for Creating the Windows Component of an Active/Passive Service

 

Profile (User Environment Manager) and User Creation 

To manage user settings, user data, and users’ access to applications, set up file shares in Site 1, set up DFS-N so that the file shares are replicated to Site 2, and determine which site is primary for each user so that the profile service can function as shown in the following figure.

Profile Recovery Service Component

Figure 113: Profile Recovery Service Component

 

Step 

Details 

File shares 

Create four file shares on the file server in Site 1 and set the relevant permissions.

  • User Environment Manager IT configuration 
  • User Environment Manager user settings 
  • Mandatory profile 
  • Home file shares for redirected folders (optional) 

 

Set up DFS-N following the guidance given in Design Component: User Environment Manager Architecture.

User placement 

  1. Decide where a given named user is initially placed (Site 1 or Site 2).
  2. Map a user to a GPO that matches that placement from a User Environment Manager perspective.
  3. Verify profile creation and functionality by performing a login with a user.

Table 68: Steps for Creating the User Profile Component of an Active/Passive Service

App Volumes Active/Passive Design

To set up this container-style technology that attaches applications to a VM when the user logs in, you must install redundant instances of App Volumes Manager, create AppStacks, which store applications in shared read-only virtual disks (VMDK files), and, optionally, create writable volumes if users need to install their own applications.

Active/Passive App Volumes Recovery Service Component

Figure 114: Active/Passive App Volumes Recovery Service Component

 

App Volumes 

Step 

Details 

Installation 

  1. Set up two App Volumes Managers in Site
  2. Set up two App Volume Managers in Site

See Design Component: App Volumes Architecture for details.

Load balancing 

  1. Configure local load balancing within each site with a virtual IP (VIP) for the local App Volumes Managers.
  2. Point the desktop master images to their respective VIP based on their site.
  3. If you are using the clustered-database option (rather than separate databases for each site), configure global load balancing between the sites if required to have a global namespace.

Storage groups 

Set up one storage group in Site 1 and one storage group in Site 2. For each storage group:

  • Configure automatic replication for AppStacks. 
  • Select all datastores to be used for AppStacks. 
  • Additionally, select one common datastore to be used to replicate AppStacks between sites. NFS is a good choice for this datastore.
  • Mark this common datastore as non-attachable. 

AppStacks 

  1. Create AppStacks as required to address the use cases. Follow the instructions in Working with AppStacks in the VMware App Volumes Administration Guide.
  2. Place the AppStacks in the local storage group to allow them to replicate to every datastore in the local storage group and also to the other site.

Entitlement replication

If you are using the separate-database configuration, do one of the following:

Writable volumes 

(optional) 

  • Create a writable volume for each user who requires one. Follow the instructions in Working with Writable Volumes in the VMware App Volumes Administration Guide.
  • Place writable volumes on dedicated LUNs, which can later be configured to be protected using storage replication.

Table 69: Steps for Creating the Streamlined Application Component of an Active/Passive Service

VMware Identity Manager 

The VMware Identity Manager service provides a common entry point to all types of applications, regardless of which data center is actively being used. To build this service, you deploy three instances in Site 1, three instances in Site 2, and set up global load balancing.

VMware Identity Manager Recovery Service Component

Figure 115: VMware Identity Manager Recovery Service Component 

 

The following table provides a very general overview of the steps to configuring VMware Identity Manager.

Important: For detailed instructions about all the steps in this table, see Appendix F: VMware Identity Manager Configuration for Multi-site Deployments.

VMware Identity Manager Configuration 

Step 

Details 

Load balancing

Configure local and global load balancer virtual servers.

First appliance 

Deploy the VMware Identity Manager open virtual appliance (OVA) in Site 1.

See Install the VMware Identity Manager OVA File in Installing and Configuring VMware Identity Manager.

Site 1 

Clone the deployed appliance two times for a total of three VMware Identity Manager appliances in Site 1.

Verify the three VMware Identity Manager appliances are functional in Site 1.

Site 2 

Export the first appliance from Site 1 as a vApp and import it to Site 2.

Verify the imported VMware Identity Manager appliance in Site 2 can communicate with the appliances in Site 1.

Clone this appliance two times for a total of three VMware Identity Manager appliances in Site 2.

Load balancing 

Verify that load balancers are working as expected.

Table 70: Steps for Creating the VMware Identity Manager Component of an Active/Passive Recovery Service

Storage Replication 

You may use all-flash arrays or other types of storage that offer replication and can use common namespaces.

Storage 

Step 

Details 

Replication 

Set up and initialize storage replication capabilities to your vendors’ specification.

Also see the Storage Replication section of the vSphere and Environment Infrastructure Design chapter.

Replication targets 

Protect or replicate the datastores that contain App Volumes writable volumes.

Table 71: Steps for Setting Up Storage Replication for an Active/Passive Recovery Service

Active/Active Recovery Service 

This section covers the high-level steps required to build out the active/active service, which can be seen from a blueprint perspective in the following figure.

Active/Active Recovery Service Components

Figure 116: Active/Active Recovery Service Components

Desktops and RDSH-Published Applications 

The first step is to create the Windows component of the service. This consists of either desktops or RDSH servers in pools or farms at both sites. Cloud Pod Architecture is then configured to provide a global entitlement to pools of desktops and published applications from both sites.

Step 

Details 

Load balancing 

Verify both global and local load balancing are functional.

Master VM 

Build out a master VM image in Site 1 to meet requirements.

Replicate the master VM image to Site 2.

Create pool or farm 

For desktops, create identical desktop pools in both sites based on the master VM image.

 

For RDSH-published applications: 

  • Create RDSH server farms in both sites using the master VM image. 
  • Add application pools in both sites containing the required applications. 

Cloud Pod Architecture 

Set up and initialize Cloud Pod Architecture between the two sites.

  • Create sites and assign the pods to their respective sites. 
  • Create global entitlements. 
  • Associate pools from both sites. 

Table 72: Steps for Creating the Windows Component of an Active/Active Recovery Service

Profile (User Environment Manager) and User Creation 

The next step is to set up file shares in Site 1, set up DFS-N so that the file shares are replicated to Site 2, and determine which site is primary for each user so that the profile service can function as shown in the following figure.

Profile Recovery Service Component

Figure 117: Profile Recovery Service Component

 

Step 

Details 

File shares 

Create four file shares on the file server in Site 1 and set the relevant permissions.

  • User Environment Manager IT configuration 
  • User Environment Manager user settings 
  • Mandatory profile 
  • Home file shares for redirected folders (optional) 

Set up DFS-N following the guidance given in the Component Design: User Environment Manager Architecture and Distributed File System section of the vSphere and Environment Infrastructure Design chapter.

User placement 

  1. Decide where a given named user is initially placed (Site 1 or Site 2).
  2. Map a user to a GPO that matches that placement from a User Environment Manager perspective.
  3. Verify profile creation and functionality by performing a login with a user.

Table 73: Steps for Creating the User Profile Component of an Active/Active Recovery Service

App Volumes Active/Active Design

To set up this container-style technology that attaches applications to a VM when the user logs in, you must install redundant instances of App Volumes Manager, and create AppStacks, which store applications in shared read-only virtual disks (VMDK files).

Active/Active App Volumes Recovery Service Component

Figure 118: Active/Active App Volumes Recovery Service Component

 

App Volumes 

Step 

Details 

Installation 

  1. Set up two or more App Volumes Managers in Site
  2. Set up two or more App Volume Managers in Site

See the Design Component: App Volumes Architecture chapter for details.

Load balancing 

  1. Configure local load balancing within each site with a virtual IP (VIP) namespace for the local App Volumes Managers.
  2. Point the desktop master images to their respective namespace based on their site.
  3. If you are using the clustered-database option (rather than separate databases for each site), configure global load balancing between the sites if required to have a global namespace.

Storage groups 

Set up one storage group in Site 1 and one storage group in Site 2. For each storage group:

  • Configure automatic replication for AppStacks. 
  • Select all datastores to be used for AppStacks. 
  • Additionally, select one common datastore to be used to replicate AppStacks between sites. NFS is a good choice for this datastore.
  • Mark this common datastore as non-attachable. 

AppStacks 

  1. Create AppStacks as required to address the use cases. Follow the instructions in Working with AppStacks in the VMware App Volumes Administration Guide.
  2. Place the AppStacks in the local storage group to allow them to replicate to every datastore in the local storage group and also to the other site.

Entitlement replication

If you are using the separate-databases configuration, do one of the following:

Table 74: Steps for Creating the Streamlined Application Component of an Active/Active Recovery Service

User Experience and Validation

The success of any end-user computing solution hinges on the quality of the end user’s experience. This can sometimes be difficult to measure because it can be affected by the user’s perception. It is important to understand how users will interact with the environment and whether it delivers what they need. Feedback from users should be incorporated into the design—and on an ongoing basis—to ensure that any required changes are made to keep the solution relevant.

  • How do users connect?
  • How do users interact with the interfaces, applications, and other aspects of the solution?
  • Does the workflow address the way users need to work?
  • What does the typical workflow look like for them?
  • Do the client device capabilities fulfill the use case needs?
  • Does the environment deliver a usable and reliable experience? Consider response time, availability, ease of use, and the ability to customize to individual needs.

Devices

One of the aims of VMware Workspace ONE is to allow access to any application from any device. Using Workspace ONE as the common access mechanism for all resources provides a familiar interface and experience across all devices.

A user’s main working client device should match the requirements for that use case. This does not mean that a user is limited to just that device. It just means that other devices might not have all the functionality needed to deliver the full experience and capabilities.

  • Understand the use cases thoroughly.
  • There is no one perfect endpoint—different uses require different choices.
  • Users will use multiple devices—try to set expectations about differences.
  • Understand Microsoft Virtual Desktop Access (VDA) licensing implications if using virtual desktops or published applications.

When accessing Horizon 7 virtual desktops and RDSH-published applications, it should be noted that not all clients are equal, and all clients do not have the same capabilities. An iPad might be great for mobility and certain use cases, but might not be suitable if features such as multiple monitors and USB redirection are required.

One area that needs careful consideration is the use of Real-Time Audio-Video (RTAV) solutions such as Microsoft Skype for Business, especially where this includes VoIP or video calls. See Configuring Real-Time Audio-Video in Configuring Remote Desktop Features in Horizon 7 and in Microsoft Lync 2013 and Skype for Business on VMware Horizon 7.

Workspace ONE User Experience

Workspace ONE provides a consistent end-user experience, regardless of device. Workspace ONE native mobile apps are built using responsive design techniques. The apps implement an HTML5-based user experience wrapped in native APIs for the respective OS on which is the app is deployed. This means that the user experience is the same for every OS, but as native apps, the apps can leverage features specific to each OS.

Workspace ONE App on Windows 10

Figure 119: Workspace ONE App on Windows 10

User Authentication

Workspace ONE provides simple authentication combined with contextual authentication policies based on factors such as the location of the device and what type of device is being used.

In the example screenshots that follow, two authentication policies have been created, one where the device is internal and where username and password suffice. The second, for external use, is configured to require two-factor authentication.

Internal Login to VMware Workspace ONE

Figure 120: Internal Login to VMware Workspace ONE

External access requires two-factor authentication.

External Login to Workspace ONE

Figure 121: External Login to Workspace ONE

After users log in, they have access to a variety of entitled applications. If users have bookmarked applications, the bookmarked apps appear on the Bookmarks tab. The applications displayed on the tabs depend on the context and capabilities of the device. For example, mobile applications are not displayed if the Workspace ONE catalog is viewed from a laptop.

Bookmarked Applications in Workspace ONE

Figure 122: Bookmarked Applications in Workspace ONE

Users can use the self-service feature of the catalog to add applications.

Application Catalog in Workspace ONE

Figure 123: Application Catalog in Workspace ONE

They can also use filters and searches to help find apps both in the catalog and on their own workspace.

Searching for Applications

Figure 124: Searching for Applications

Application Launch

Users can launch different types of applications from within their workspace. Web page links open in new tabs. When launching links to SaaS applications (for example, Salesforce), single sign-on is used, and the user is automatically authenticated.

SaaS Application Launch and Single Sign-On

Figure 125: SaaS Application Launch and Single Sign-On

Horizon 7 Desktop and Published-Application Launch

Horizon 7 virtual desktops and published applications can be synchronized with the Workspace ONE catalog. This provides a consistent experience for the user, who now has one place to go for all their applications, regardless of the type.

Depending on how the environment is configured, virtual desktops and published applications can be automatically bookmarked for a user. Alternatively, users can search the catalog for resources they have been entitled to and optionally bookmark them if they intend to access the items frequently.

Desktops and Applications in Workspace ONE

Figure 126: Desktops and Applications in Workspace ONE

When users launch a published application, an application window opens on their desktop, just as if the Windows-based application were natively installed.

User Launch of a Horizon 7 Published Application from Workspace ONE

Figure 127: User Launch of a Horizon 7 Published Application from Workspace ONE

If entitled, users can launch a virtual desktop and single sign-on (SSO) to the desktop. In the example screenshot that follows, the VMware Horizon® HTML Access™ browser-based client is used rather than the Horizon Client native app.

Launch of a Horizon 7 Virtual Desktop from Workspace ONE

Figure 128: Launch of a Horizon 7 Virtual Desktop from Workspace ONE

From within a virtual desktop, users can also SSO to Workspace ONE and access all applications in the catalog.

Workspace ONE Inside a Horizon 7 Virtual Desktop

Figure 129: Workspace ONE Inside a Horizon 7 Virtual Desktop

Inside a virtual desktop, Windows applications can be run in the usual manner within Windows. These Windows applications could be:

  • Applications pre-installed in the master VM (and so present in all clones)
  • Core applications attached through a common App Volumes AppStack
  • Departmental applications given to specific users through an AppStack

Power users provided with an App Volumes writable volume can also install their own applications and have them persist across sessions.

User Experience on an iOS Device

On an iOS device, the Workspace ONE app can use the latest technologies from Apple, such as Touch ID to enable one-touch authentication that uses mobile SSO features. On Windows 10, the native app can use Windows Hello to authenticate using a camera and facial recognition.

The following sequence provides a tour of the basic user experience on an enrolled iPad Pro iOS device. In the following screenshot, the home screen of an enrolled iPad Pro is configured and displays the Workspace ONE Touch ID.

  1. The user launches the Workspace ONE app.
    For the example in the following screenshot, a user could either tap the icon in the top-left part of the screen or use the quick-launch menu at the bottom.Home Screen of iOS Device and Workspace ONE App

    Figure 130: Home Screen of iOS Device and Workspace ONE App 

  2. If the user has previously authenticated, they will be presented with the option to use Touch ID for Workspace and reauthenticate using their fingerprint.Touch ID Integrated with iOS SSO

    Figure 131: Touch ID Integrated with iOS SSO

  3. After authentication is complete, the Workspace ONE app opens the Bookmarks tab. This tab allows a user to conveniently locate their favorite and frequently used applications.Bookmarks for Favorite Applications

    Figure 132: Bookmarks for Favorite Applications

  4. Selecting the Catalog tab allows a user to see all the available applications.
    • These are categorized and include virtual (Horizon 7 desktops and published applications), websites (SaaS applications), and mobile apps.
    • The magnifying glass at the top right can also be used to search for applications.
    • Applications that are frequently used can be bookmarked.
      Catalog Displaying All Available Applications and Virtual Desktops​​​​​​

      Figure 133: Catalog Displaying All Available Applications and Virtual Desktops

  5. From the Catalog, a user can install mobile apps on their iOS device.
    Installing Mobile Apps from the Catalog Tab or Search ResultsInstalling Mobile Apps from the Catalog Tab or Search Results

    Figure 134: Installing Mobile Apps from the Catalog Tab or Search Results

  6. After selecting an app to install, the user is asked to confirm installation. Depending on the source, the application might be pushed to the device, or the user might be redirected to the native app store for the device type.Confirmation Box That Redirects to an App Store

    Figure 135: Confirmation Box That Redirects to an App Store

    Confirmation Box That Pushes the Mobile App to the Device

    Figure 136: Confirmation Box That Pushes the Mobile App to the Device

  7. After application installation is complete, the iOS home screen will display the application icon.Native Apps on iOS Home Screen

    Figure 137: Native Apps on iOS Home Screen

Recovery Service Validation

This section details the impact to both users and services during a site failure and the behavior after failover.

Active/Active Service 

Type of Access

During Failure 

After Failover 

VMware Identity Manager 

The VMware Identity Manager component is not supported in active/active mode. The VMware Identity Manager service must be active in only one data center.

If that data center is affected, service to users is interrupted until the VMware Identity Manager service is failed over to the secondary site.

User can log in as normal.

VMware AirWatch

Similar to VMware Identity Manager, VMware AirWatch services must be active in only one data center.

If that data center is affected, service to users is interrupted until the VMware AirWatch service is failed over to the secondary site.

User gets full VMware AirWatch functionality.

Horizon 7:

Logged-in user 

Current sessions are terminated.

N/A 

Horizon 7:

New user logging in 

User can log in to failover site immediately.

User can log in as normal.

Access to the user profile through User Environment Manager 

User gets a temporary profile.

User gets own profile.

Access to AppStacks 

User has access to AppStacks.

User has access to AppStacks.

Access to writable volumes 

N/A 

N/A 

Table 75: Active/Active Service Failure Impact

Active/Passive Service 

Type of Access

During Failure 

After Failover 

VMware Identity Manager 

The VMware Identity Manager component is active in one data center.

If that data center is affected, service to users is interrupted until the VMware Identity Manager service is failed over to the secondary site.

User can log in as normal.

VMware AirWatch

Similar to VMware Identity Manager, VMware AirWatch services must be active in only one data center.

If that data center is affected, service to users is interrupted until the VMware AirWatch service is failed over to the secondary site.

User gets full VMware AirWatch functionality.

Horizon 7:

Logged-in user 

Current sessions are terminated.

N/A (After the current session is terminated, the user must log in again, and so becomes a new user logging in.)

Horizon 7:

New user logging in 

User cannot log in until the CPA home site is changed.

User can log in as normal.

Access to the user profile through User Environment Manager 

N/A 

User gets own profile.

Access to App Volumes AppStacks 

User has access to AppStacks.

User has access to AppStacks.

Access to App Volumes writable volumes 

Writable volumes are unavailable.

User has access to their writable volume.

Table 76: Active/Passive Service Failure Impact

Appendix A: VM Specifications

This appendix includes virtual machine specifications for both management server VMs and virtual desktop and RDSH server VMs.

Management VM Specifications

For each of the management VMs, there are recommended builds and specifications.

vCenter Server

A vCenter Server can be deployed as a prepackaged virtual appliance, as was done for this reference architecture, or alternatively, it can be installed in a Windows server.

Attribute

Specification

Version

vCenter Server 6.5

VM hardware

VMware Virtual Hardware version 13

OS

SUSE Linux Enterprise 12 (64-bit)

vCPU

8

vMemory

24 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic Parallel

Virtual disk – VMDK (scsi0:x)

Scsi0:0 Disk 12 GB

Scsi0:1 Disk 1.4 GB

Scsi0:2 Disk 50 GB

Scsi0:3 Disk 50 GB

Scsi0:4 Disk 25 GB

Scsi0:5 Disk 25 GB

Scsi0:6 Disk 10 GB

Scsi0:8 Disk 50 GB

Scsi0:10 Disk 10 GB

Scsi0:12 Disk 25 GB

Scsi0:14 Disk 25 GB

Table 77: vCenter Server VM Specifications

SQL Server

SQL Server is used for the Connection Server event database, the Composer database, the VMware Identity Manager database, and the App Volumes database.

Attribute

Specification

Version

SQL Server 2016

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

2

vMemory

8 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:0 Windows OS 40 GB

Scsi0:1 Data Disk 50 GB

Table 78: SQL Server VM Specifications

AirWatch Device Services Server

Attribute

Specification

Version

AirWatch, version 9.2.3

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

8 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 50 GB

Table 79: AirWatch Device Services VM Specifications

AirWatch Console Services Server

Attribute

Specification

Version

AirWatch, version 9.2.3

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

8 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 50 GB

Table 80: AirWatch Console Services VM Specifications

AirWatch Cloud Connector Server

Depending on the scale of the environment and the number of devices to be supported, the recommend resources allocated to each AirWatch Cloud Connector VM can differ. For this reference architecture, a 50,000-device deployment was considered. For guidance on sizing for different numbers of devices see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

 

Attribute

Specification

Version

AirWatch, version 9.2.3

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

2

vMemory

4 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 50 GB

Table 81: AirWatch Cloud Connector VM Specifications

AirWatch Memcached Server

Attribute

Specification

Version

AirWatch, version 9.2.3

VM hardware

VMware Virtual Hardware version 13

OS

CentOS 7.4-1708

vCPU

2

vMemory

8 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 50 GB

Table 82: AirWatch Memcached VM Specifications

VMware Identity Manager Server

Depending on the scale of the environment and the number of devices to be supported, the recommend resources allocated to each VMware Identity Manger VM can differ. For this reference architecture, a 50,000-device deployment was considered. For guidance on sizing for different numbers of devices see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

Attribute

Specification

Version

VMware Identity Manager, version 3.1.0

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

8

vMemory

16 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 50 GB

Table 83: VMware Identity Manager VM Specifications

VMware Identity Manager Connector Server

Depending on the scale of the environment and the number of devices to be supported, the recommend resources allocated to each VMware Identity Manager Connector VM can differ. For this reference architecture, a 50,000-device deployment was considered. For guidance on sizing for different numbers of devices see On-Premises Recommended Architecture Hardware Sizing in the Architecture section of the AirWatch Documentation.

Attribute

Specification

Version

VMware Identity Manager, version 3.1.0

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

16 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 50 GB

Table 84: VMware Identity Manager Connector VM Specifications

Horizon 7 – Connection Server

Attribute

Specification

Version

Horizon 7, version 7.3.2

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

12 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 40 GB

Table 85: Connection Server VM Specifications

Horizon 7 – Enrollment Server

Attribute

Specification

Version

Horizon 7, version 7.3.2

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

12 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 40 GB

Table 86: Enrollment Server VM Specifications

Horizon 7 – Composer Server

Composer can be installed as a standalone server, or it can be co-installed on a Windows server with vCenter Server.

Attribute

Specification

Version

Composer 7.3.2

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

4

vMemory

12 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 40 GB

Table 87: Composer VM Specifications

App Volumes Manager

Attribute

Specification

Version

VMware App Volumes 2.13

VM hardware

VMware Virtual Hardware version 13

OS

Windows Server 2016

vCPU

2

vMemory

8 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic SAS

Virtual disk – VMDK (scsi0:x)

Scsi0:1 Windows OS 40 GB

Table 88: App Volumes Manager VM Specifications

vRealize Operations Manager

Attribute

Specification

Version

VMware vRealize Operations Manager 6.5

VM hardware

VMware Virtual Hardware version 13

OS

SUSE Linux Enterprise 13 (64-bit)

vCPU

4

vMemory

16 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic Parallel

Virtual disk – VMDK (scsi0:x)

Scsi0:0 Disk 20 GB

Scsi0:1 Disk 250 GB

Scsi0:2 Disk 4 GB

Table 89: vRealize Operations Manager VM Specifications

NSX Manager

Attribute

Specification

Version

NSX Manager 6.3.5

VM hardware

VMware Virtual Hardware version 13

OS

Other Linux (64-bit)

vCPU

4

vMemory

16 GB

vNICs

1

Virtual network adapter 1

VMXNET3 Adapter

Virtual SCSI controller 0

LSI Logic Parallel

Virtual disk – VMDK (scsi0:x)

Scsi0:0 Disk 60 GB

Table 90: NSX Manager VM Specifications

Appendix B: Horizon 7 Configuration

This appendix provides an overview of the installation and initial configuration of Horizon 7, as well as details about group policy settings and Horizon 7 Smart Policies, provided through User Environment Manager. Mandatory profile creation and configuration is also detailed.

Horizon 7 Installation and Configuration

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

Installation Prerequisites

Before starting, certain other infrastructure components must be in place and configured:

  • Management vSphere cluster, as described in the vSphere section
  • VDI vSphere cluster, as described in the vSphere section
  • Active Directory, as described in the Active Directory section
  • DNS, as described in the DNS section
  • DHCP, as described in the DHCP section
  • Certificate Authority, as described in the Certificate Authority section
  • Load balancer, as described in the Load Balancer section

You must also create a Windows 2016 RDSH VM template, as described in Windows Server 2016 Master VM.

Installation Steps

This section outlines the Horizon 7 installation steps.

Step

Task

1

Set up the required administrator users and groups in Active Directory.

2

If you have not yet done so, install and set up ESXi hosts and vCenter Server.

3

(Optional) If you are going to deploy linked-clone desktops, install Composer, either on the vCenter Server system or on a separate server. Also install the Composer database.

4

Install and set up Connection Server. Also install the event database.

5

Create one or more VMs that can be used as a template for full-clone desktop pools or as a master for linked-clone desktop pools or instant-clone desktop pools.

6

Set up an RDSH server VM and install applications to be remoted to end users.

7

Create desktop pools, application pools, or both.

8

Entitle users to desktops and published applications.

9

Install Horizon Client on end users’ machines and have end users access their remote desktops and applications.

10

(Optional) Create and configure additional administrators to allow different levels of access to specific inventory objects and settings.

11

(Optional) Configure policies to control the behavior of Horizon 7 components, desktop and application pools, and end users. See Configuring Policies in Horizon Administrator and Active Directory in the View Administration guide.

12

(Optional) For added security, integrate smart card authentication or a RADIUS two-factor authentication solution, especially where external access is allowed. This is covered in Component Design: Unified Access Gateway Architecture.

Preparation

Build three Windows 2016 VMs: two for Connection Servers and one for the enrollment server (required for True SSO). These will be hosted and physically located in the management cluster.

Follow the hardware specifications in Appendix A: VM Specifications and assign all three VMs static IP addresses.

Deployment

This guide is not intended to replace the Horizon 7 documentation. Follow the relevant section of the View Installation guide to install the following components.

Component

Install Guide

1. Install the first standard Connection Server.

See Install View Connection Server with a New Configuration in the View Installation guide.

2. Install a replica Connection Server.

See Install a Replicated Instance of View Connection Server in the View Installation guide.

3. Install an enrollment server.

See Setting Up True SSO in the View Administration guide.

Post-Installation Configuration

Connect to the first Connection Server and perform the following tasks.

Task

Documentation Instructions

  • Apply the license.
  • Add vCenter Server.
  • Configure View Storage Accelerator.

See Configuring View Connection Server for the First Time in the View Installation guide.

Add instant clone domain administrators.

See Add an Instant-Clone Domain Administrator in Setting Up Virtual Desktops in Horizon 7.

Configure event reporting.

See Configuring Event Reporting in the View Installation guide.

Assign administrators and roles.

See Configuring Role-Based Delegated Administration in the View Administration guide.

For each of the Connection Servers, configure the following.

Task

Detail

General settings

Because we are using Unified Access Gateway for external connectivity, leave the following fields deselected: HTTPS Secure Tunnel, PCoIP Secure Gateway, Blast Secure Gateway.

Authentication

Follow the steps in Configure a SAML Authenticator in View Administrator in the View Administration guide to set up the VMware Identity Manger as a SAML authenticator.

Backup

Define a backup schedule and location for the Connection Server configuration according to View Configuration Backup Settings in the View Administration guide.

Origin checking

With multiple Connection Servers fronted by a load balancer, it is necessary to change origin checking on each server. This requires the creation of a locked.properties file in the

C:\Program Files\VMware\VMware View\Server\sslgateway\conf

directory and the addition of the following entries as detailed in Cross-Origin Resource Sharing in the View Security guide.

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

Certificates

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

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

For the full process, see Obtaining SSL Certificates from a Certificate Authority in Scenarios for Setting Up SSL Certificates for View.

Pool Settings

The following tables list specific desktop pool settings and RDSH server farm settings that were used in this reference architecture.

Configuration Item

Settings for Instant-Clone Pools

Desktop Pool Definition

  • Type
  • User Assignment
  • vCenter Server

 

Automated

Floating

Instant clones

Desktop Pool Settings

  • Remote Machine Power Policy
  • Delete or refresh machine on logout
  • Default display protocol
  • 3D renderer
  • HTML access

 

N/A

N/A

 

VMware Blast

N/A or NVIDIA GRID vGPU (depending on use case)

Enabled

Provisioning Settings

  • Provision all machines up-front

 

Selected

Storage Optimization

  • Use VMware Virtual SAN

 

Selected

Guest Customization

  • AD container

Dedicated OU for this type of desktop

RDS Farm Settings

Configuration Item

Settings for RDSH Server Farms

Desktop Pool Definition

  • Type

 

Automated

Identification and settings

  • Default display protocol
  • HTML access
  • Max sessions per RDS host

 

VMware Blast

Enabled

30 or greater, depending on server hardware and VM specifications

Storage Optimization

  • Use VMware Virtual SAN

 

Selected

Guest Customization

  • AD container

Dedicated OU for this type of desktop

Predefined spec

Master VM Template Specifications and Best Practices

Build a clean VM. Do not convert (P2V) or reuse an image that was designed for physical PCs. Optimize, optimize…optimize!

For virtual desktop VMs and RDSH server VMs, there are recommended specifications and required software and settings.

  • Windows Server 2016 Master VM 
  • Windows 10 Master VM 
  • vGPU Specifications 
  • Windows Tuning Specifications 
  • Required RDSH Roles and Features 
  • Applications in the Base Image 
  • Antivirus Best Practices (If Not Using Endpoint Antivirus) 
  • Installation Order of VMware Tools and Agents 
  • VMware Identity Manager Client Installation Parameters 
  • Horizon Agent Installation Parameters 
  • OS Cleanup and VM Snapshot 

Windows Server 2016 Master VM

Use the following settings when creating a master VM for RDS server farms.

Item

Specifications

CPU and memory

  • Size appropriately
  • 4 vCPUs and 12 GB RAM

SCSI disk controller

LSI Logic SAS

Network card

VMXNET3

Video card

  • Size for the intended number of monitors and resolution.
  • Enable 3D support if required.

CD-ROM

  • Set to Client Device and Not to Connect at power on (delete if not needed).

Floppy drive

Delete

COM and LPT

Disable unused ports, such as COM1, COM2, and LPT (delete if not needed).

Hotplug

Time sync

In VMware Tools™ settings, enable Synchronize guest time with host.

Table 91: RDSH Server VM Tuning Specifications

Windows 10 Master VM

Use the following settings when creating the master VM for Windows 10 desktops. We used Windows 10 (1703).

Item

Specifications

CPU and memory

  • Size appropriately
  • 2 vCPUs and 4 GB RAM typical for Windows 10

SCSI disk controller

LSI Logic SAS

Network card

VMXNET3

Video card

  • Size for the intended number of monitors and resolution.
  • Enable 3D support if required.

CD-ROM

  • Set to Client Device and Not to Connect at power on (delete if not needed).

Floppy drive

Delete

COM and LPT

Disable unused ports, such as COM1, COM2, and LPT (delete if not needed).

Hotplug

Time sync

In VMware Tools™ settings, enable Synchronize guest time with host.

Table 92: VM Tuning Specifications

Note: When removing hardware such as the floppy drive, after you delete the item from the VM configuration, be sure to also disable it in the BIOS of the VM.

vGPU Specifications

To add the required virtual hardware and driver for GPU-enabled desktops, follow the additional steps in Preparing for NVIDIA GRID vGPU Capabilities in Setting Up Virtual Desktops in Horizon 7, or see chapter 10 of the NVIDIA GRID vGPU Deployment Guide for Horizon 6.1.

Windows Tuning Specifications

After you install Windows, there are lots of optimizations you can make to reduce the resources needed and to improve the user experience. Follow the VMware Windows Operating System Optimization Tool Guide for full details on tuning and optimizing Windows for use in a virtual environment.

The guide also provides details on how to use the VMware OS Optimization Tool, which includes customizable templates to enable or disable Windows system services and features according to VMware recommendations and best practices.

The OS Optimization Tool provides the following functionality:

  • Local analyze/optimize
  • Remote analyze
  • Optimization history and rollback
  • Managing templates

Because, in this reference architecture, we use VMware Identity Manager in conjunction with Horizon 7 desktops, we joined the VM to the Active Directory domain used for the resultant instant-clone desktops.

Task

Description

Adjust display properties

Choose a basic theme.

  • Set the background to a solid color.
  • Set the screen saver to None.
  • Set visual effects to Adjust for best performance.
  • Disable Aero if not required.
  • Verify that full hardware acceleration is enabled.

Power policy

  • Select a high-performance power option.
  • Change the plan so that the display never turns off.
  • Do not specify a sleep timer, standby, hibernation, or any other power option that could make the desktop unreachable.
  • Disable hibernation using the following command: powercfg.exe /h

Restore points

  • Remove or minimize system restore points.
  • Turn off system protection on C:\.

Sound scheme

Set the sound scheme to No Sounds.

Windows Media Player

Open Windows Media Player and use the default settings.

Networking

  • Disable IPv6 if not needed.
  • De-select Link-layer Topology Discovery Mapper I/O Driver
  • Refer to Configure the Windows Firewall Service to Restart After Failures in Setting Up Virtual Desktops in Horizon 7 for more information.

Active setup

Improve the login time for floating desktops by disabling Windows Active Setup components. Refer to the KB article Improving log in time for floating desktops on DaaS and Horizon View (2100337).

Updates

Turn off Automatic Updates.

Disk defragmenter

Disable unnecessary services such as disk defragmenter

Note: Windows schedules some services to run by default, such as the disk defragmenter. These services and tasks can cause OS disks to expand every few hours, even when idle. Services that affect disk expansion also generate additional IOPS.

Indexing service

Unless there are user requirements for it, disable the Indexing Service component.

Table 93: Windows Tuning Specifications

Evaluate the effects before implementing a change. For example, the Indexing Service component might be required if users expect (and you want to allow) them to be able to search Outlook.

Some items to consider tuning include the following common services and Windows 10 apps.

Common Services to Disable

Windows Hibernation

Windows Scheduled Disk Defragmentation

Windows Update service

Windows Diagnostic Policy service

Prefetch and Superfetch

Windows Registry Backup

System Restore

Windows Defender

Microsoft Feeds Synchronization Task

Table 94: Windows Services to Disable for Better Performance

 

Windows 10 Apps to Delete

 

News / Sports / Weather

  • BingFinance
  • BingNews
  • BingSports
  • BingWeather

Help / Get

  • Getstarted
  • SkypeApp
  • MicrosoftOfficeHub

Games / Xbox

  • XboxApp
  • ZuneMusic
  • ZuneVideo
  • MicrosoftSolitaireCollection

Others

  • 3DBuilder
  • People
  • Windows.Photos
  • WindowsAlarms
  • WindowsCalculator
  • WindowsCamera
  • WindowsMaps
  • WindowsPhone
  • WindowsSoundRecorder
  • Office.OneNote
  • WindowsStore
  • Appconnector

Table 95: Common Windows Apps to Consider Deleting

As with any tuning, consider the balance between resource consumption and user experience before removing applications, for example, WindowsCalculator.

Required RDSH Roles and Features

For Windows 2012 R2 and Windows 2016 servers used for RDSH servers, you must install the required roles. In Server Manager, add the following roles and features:

  • Server Role – From the Roles list, select Remote Desktop Services.
  • Features – From the Features list, select User Interfaces and Infrastructure > Desktop Experience, and confirm that you want to add the applicable required role services, features, and management tools.
  • Role Services – From the Role Services list, select Remote Desktop Session Host, and confirm that you want to add the applicable management tools.

Information about licensing for RDSH by using a group policy is described in Horizon 7 Group Policies.

Applications in the Base Image

Although our primary application-delivery mechanism is App Volumes, it might be desirable to install select applications in the master VM so that all clones get those applications in their base disk.

Many applications have integrated auto-update functionality. Install these applications and update them to the latest version, and then turn off or disable the auto-update functionality to prevent the clones from updating individually.

Antivirus Best Practices (If Not Using Endpoint Antivirus)

Follow the best practices for using antivirus software on virtual desktops and RDSH servers as detailed in Antivirus Considerations in a VMware Horizon 7 Environment.

Installation Order of VMware Tools and Agents

When preparing a VM for use as a virtual desktop or RDSH server, you must install the relevant product agents. The installation order is important, and if you update one agent, remove all subsequent agents and install their latest versions to maintain the following installation order.

  1. VMware Tools
  2. Horizon Agent
  3. User Environment Manager FlexEngine
  4. VMware Identity Manager Client
  5. App Volumes Agent

VMware Identity Manager Client Installation Parameters

This agent enables virtual desktops to launch application types such as ThinApps that are delivered through VMware Identity Manager. Install from the command line and specify the following parameters:

/v WORKSPACE_SERVER=”https://<WORKSPACE_SERVER_FQDN>” INSTALL_MODE=RUN_FROM_SHARE

Note: Replace the <WORKSPACE_SERVER_FQDN> with the server name that end users will use to access VMware Identity Manager. This might be the FQDN for the load balancer, if a load balancer is used in front of multiple VMware Identity Manager appliances.

Horizon Agent Installation Parameters

  1. Select IPv4 or IPv6.
    Agent, client, and Connection Servers must all use the same IP version.
  2. Select additional features, if required. See Horizon Agent Custom Setup Options in Setting Up Virtual Desktops in Horizon 7.
  3. Select a cloning technology: Instant Clone.
  4. Enable Remote Desktop, if not already done.
  • Give suitable security group access (for example, Domain Users).
  • Add Firewall exceptions if enabling manually.

OS Cleanup and VM Snapshot

The last step before we can use this VM is to clean up and take a vSphere snapshot.

  1. Cleanup:
    • Delete all event logs.
    • Delete all hidden update folders in C:\Windows
      Example: $NtUninstallKB893756$ (except $hf_mig$)
    • Turn off disk performance counters (diskperf –n).
    • Delete contents of C:\Windows\Temp\
    • Run Disk Cleanup to remove temporary files, empty the Recycle Bin, and remove other unneeded files.
    • Run Disk Defragmenter (you might have to temporarily re-enable the Optimize drives service).
    • Flush DNS and release the DHCP IP address lease.
  2. Shut down the VM.
  3. Disconnect the CD-ROM and make sure no ISO is configured in the VM.
  4. Snapshot the VM.

Horizon 7 Group Policies

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

OU GPO Best Practices

Use the following guidelines when applying GPO settings:

  • Re-use GPOs.
  • Create separate OUs for users and computers.
  • Ensure that each GPO is enabled or disabled for Computer 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.
    • Functional GPOs contain a limited set of settings for a specific area. Functional GPOs are smaller GPOs that facilitate settings being defined for particular users or VMs.
  • 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 the settings for the VM’s OU are applied to the session.

This appendix 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 User Environment Manager policies. As part of the download of Horizon 7, there is a VMware-Horizon-Extras- Bundle ZIP file that contains a set of group policy templates to assist in defining these and other GPO settings.

Common GPO Settings for Desktop and RDSH Server VMs

Setting

Value

Computer Configuration/Policies/Administrative Templates/System/Group Policy/

Configure user Group Policy loopback processing mode

Enabled

Mode = Replace

Configure Logon Script Delay

Disabled

Computer Configuration/Policies/Administrative Templates/System/Logon/

Show first sign-in animation

Disabled

Always wait for the network at computer startup and logon

Enabled

Table 96: Common GPO Settings

Desktop

Setting

Value

Computer Configuration/Policies/Administrative Templates/System/User Profiles/

Set roaming profile path for all users logging onto this computer

Enabled

(Specify the roaming profile network share path).

Delete cached copies of roaming profiles

Enabled

Table 97: Desktop Settings

RDSH Server OU Level

When using RDSH servers, you must apply certain group policy settings as described in Using Remote Desktop Services Group Policies in Setting Up Published Desktops and Applications in Horizon 7. To define these, first, copy the vmware_rdsh.admx and vmware_rdsh_server.admx files and the en-US folder (from the VMware-Horizon-Extras-Bundle ZIP file) to the C:\Windows\PolicyDefinitions folder on the Active Directory Domain Controller you are creating GPOs on.

Setting

Value

Computer Configuration/Policies/Administrative Templates/Windows Components/Horizon View RDSH Services/Remote Desktop Session Host/Licensing/

Use the specified Remote Desktop license servers

Enabled

(List license servers)

Hide notifications about RD Licensing problems that affect the RD Session Host server

Enabled

Set the Remote Desktop licensing mode

Enabled

(Match mode of licenses)

Computer Configuration/Policies/Administrative Templates/Windows Components/Horizon View RDSH Services/Remote Desktop Session Host/Profiles/

Use mandatory profiles on the RD Session Host server

Enabled

Set path for Remote Desktop Services Roaming User Profile

Enabled

Computer Configuration/Policies/Administrative Templates/Windows Components/Horizon View RDSH Services/Remote Desktop Session Host/Device and Resource Redirection/

Allow time zone redirection

Enabled

Table 98: RDSH Server Settings

User Configuration Settings

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

Setting

Value

User Configuration/ Policies/Administrative Templates/Start Menu and Taskbar/

Remove and prevent access to the Shut Down, Restart, Sleep and Hibernate commands

Enabled

Add Logoff to the Start Menu

Enabled

User Configuration/ Policies/Administrative Templates/Windows Components/Internet Explorer/

Automatically activate newly installed add-ons

Enabled

User Configuration/ Policies/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/ Security Page/

Site to Zone Assignment List

  • Zone assignments

Enabled

<URL of Identity Manager> 1

Example: https://workspace.vmweuc.com 1

<URL of ThinApp Share> 1

Example: \\vmweuc.com\files\ 1

Table 99: User Configuration Settings

User Environment Manager – Group Policy Settings

The following instructions are excerpted from the User Environment Manager Administration Guide. Refer to this guide for more details on Group Policy settings.

  1. Copy the VMware UEM.admx and VMware UEM FlexEngine.admx ADMX templates (and their corresponding ADML files) from the download package to the ADMX location as described in the Managing Group Policy ADMX Files Step-by-Step Guide on the Microsoft Web site.
  2. Open the Group Policy Management Console.
    1. Create a new Group Policy Object (GPO) or select an existing GPO that is applied to the users for which you want to configure FlexEngine.
    2. To open the Group Policy Management Editor, right-click the selected GPO and then click Edit.

    The FlexEngine ADMX template is available under User Configuration\ Administrative Templates\VMware UEM\FlexEngine.

  3. Configure the appropriate User Environment Manager Group Policy settings. At a minimum, the following must be set:
    • Flex config Files – Location of the User Environment Manager configuration share
    • Profile archives – Location of the User Environment Manager user profile share
    • Run FlexEngine as a Group Policy Extension – This setting enables the FlexEngine agent. Alternatively, it can be called from a logon script.
    • A logoff script must be defined for User Environment Manager to save settings on logoff. The syntax of the logoff script is:

      "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -s

 

Setting

Value

User Configuration\Policies\Administrative Templates\VMware UEM\FlexEngine

Flex config files

Enabled

(Enter User Environment Manager configuration share)

Profile archives

Enabled

(Location of the User Environment Manager user profile share)

Run FlexEngine as Group Policy Extension

Enabled

User Configuration\Policies\Windows Settings\Scripts\

Logoff

Script Name = C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe

Script Parameters = -s

Table 100: User Environment Manager Group Policy Settings

Mandatory Profile

After you create the mandatory profile by creating a new default folder, renaming certain files, and setting certain Windows Registry keys, you can use GPO settings to configure the profile.

Create the Mandatory Profile

The following table lists the steps for creating the mandatory profile.

Step

Task

1

  • From source Windows 10 or Windows 2016 machine, browse to C:\Users\. 
  • If the Default profile folder is not visible, change your default folder view options. (Show hidden files, folders, and drives, and uncheck Hide protected operating system files).

2

  • Copy the C:\Users\Default folder to your Mandatory profile network share.
  • Make sure the share is set for Everyone to have a minimum of Read access.

3

  • In the network copy of the Default folder you made, rename NTUSER.DAT to NTUSER.MAN.
  • Delete NTUSER.DAT.LOG1 and NTUSER.DAT.LOG2.

4

  • Run regedit: Click hkey_users and load Hive. Browse to ntuser.man.
  • Give your hive a name to help you identify it while you are editing it.
  • Set the correct permissions on the hive.
  • Remove Profile User and administrators.
  • Add in Full Control for authenticated users.

  • Rename the Default folder to Default.v6 (see the next table).
  • Change the folder’s properties so it is not hidden.

Table 101: Creating a Mandatory Profile

Note: The extension you use on the profile folder (for example, profile.v6) depends on the Windows version.

Profile Extension

Windows Version

None

Windows XP

.V2

Windows 7

Windows Server 2008 R2

.V3

Windows 8

Windows Server 2012

.V4

Windows 8.1

Windows Server 2012 R2

.V5

Windows 10 (1507, 1511)

.V6

Windows 10 (1607, 1703)

Windows Server 2016

Table 102: Profile Folder Extensions

Configure Active Directory Group Policies for Mandatory Profile

The following table describes how to configure settings for the mandatory profile.

Step

Task

1

Edit or create a Group Policy on the OU that will contain your virtual desktop objects.

2

To enable Always wait for the network at computer startup and logon, navigate to Computer Configuration > Policies > Administrative Templates > System > Logon.

3

Enable the Mandatory profile.

For virtual desktops:

  • Navigate to Computer Configuration > Policies > Administrative Templates > System > User Profiles.
  • Set roaming profile path for all users logging into this computer = Enabled.
  • Specify the mandatory network share path.

Example: \\server\share\Default (Do not include the .v6 in the folder path.)

For RDSH servers:

  • Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Profiles.
  • Use mandatory profiles on the RD Session Host server = Enabled.
  • Set path for Remote Desktop Services Roaming User Profile = Enabled.
  • Specify the mandatory network share path as you did for virtual desktops.

Table 103: Configuring a Mandatory Profile

For detailed instructions, see the Microsoft article Create Mandatory User Profiles.

When using mandatory profiles, also use folder redirection, which you can configure in the User Environment Manager policy.

User Environment Manager Smart Policies

The following tables contain some simple sample Horizon policies. Adapt and embellish to suit the use case and environment.

The following policies are defined in the User Environment Manager console.

Horizon Policy – External

 

Horizon Policy Setting

Value

USB redirection

Disable

Printing

Disable

Clipboard

Disable

Client drive redirection

Disable

PCoIP profile

Not set

Conditions

Horizon Client property Client location is equal to External

Table 104: External Horizon Smart Policies

Horizon Policy – Internal

Horizon Policy Setting

Value

USB redirection

Enable

Printing

Enable

Clipboard

Enable

Client drive redirection

Enable

PCoIP profile

Not set

Conditions

Horizon Client property Client location is equal to Internal

Table 105: Internal Horizon Smart Policies

Horizon Policy – ZContractor

Horizon Policy Setting

Value

USB redirection

Disable

Printing

Enable

Clipboard

Disable

Client drive redirection

Disable

PCoIP profile

Not set

Conditions

Horizon Client property Client location is equal to Internal

and

User is a member of group Contractor

Table 106: zContractor Horizon Smart Policies

You should also configure a triggered task to ensure that Smart Policies are reevaluated every time a user reconnects to a session so the user gets the appropriate policy applied.

Triggered Task – Horizon Policies

Trigger

Reconnect Session

Action

Use Environment refresh

Refresh

Horizon Policies

Table 107: Triggered Task Horizon Smart Policies

Folder Redirection

Folder Redirection Settings

Remote path

Users Home drive share using %username% variable

Example: \\vmweuc.com\share\Users\%username%

Folders to redirect

Documents

Note: Depending on your needs, you may also want to select Downloads, Music, Pictures, and Videos. Be aware that this will place a larger load on your file servers requiring more space and performance.

Conditions

None

Table 108: Folder Redirection Horizon Smart Policies

Appendix C: NSX Manager Installation and Configuration

This appendix provides an overview of the NSX deployment process and includes an extensive list of the firewall rules used in this reference architecture.

NSX Installation

This section outlines the NSX installation steps. This guide is not intended to replace the NSX documentation

Before starting, the NSX Manager requires other infrastructure components to be in place and configured:

  • Management vSphere cluster
  • VDI vSphere Cluster
  • vSphere Distributed Switch
  • vCenter Server and Platform Services Controller
  • DNS – Forward and Reverse Lookups
  • NTP
  • Active Directory
  • Static IP Addresses

Please follow the relevant section of the NSX Installation Guide to install all of the following components.

 

Step

Task

1

Install and set up ESXi hosts and vCenter Server.

2

Deploy the first NSX Manager for the management cluster.

See Install the NSX Manager Virtual Appliance in the NSX Installation Guide.

3

Prepare ESXi hosts in the management cluster for the Distributed Firewall feature.

 

4

Configure Distributed Firewall rules for the Horizon 7 management infrastructure cluster. See NSX Distributed Firewall Rules for Horizon 7.

5

Install and set up ESXi hosts and vCenter Server.

6

Deploy the second NSX Manager for the VDI compute cluster.

7

Prepare ESXi hosts in the VDI cluster for the Distributed Firewall feature.

8

Configure Distributed Firewall rules for Horizon 7 VDI systems.

Post-Installation Configuration

Perform the following tasks for each NSX Manager.

Task

Documentation

1. Register the vCenter Server for the management cluster with NSX Manager.

2. Verify that the NSX plug-in is installed in vSphere Web Client.

See Register vCenter Server with NSX Manager in the NSX Installation Guide.

3. Configure SSO.

See Configure Single Sign On in the NSX Installation Guide.

4. Configure Syslog.

See Configure a Syslog Server for NSX Manager in the NSX Installation Guide.

5. Apply the license.

See Install and Assign NSX for vSphere License in the NSX Installation Guide.

6. Exclude the vCenter Server from firewall protection.

See Exclude Virtual Machines from Firewall Protection in the NSX Installation Guide.

7. Prepare the management cluster for NSX.

See Prepare Host Clusters for NSX in the NSX Installation Guide.

8. Assign administrators. The Enterprise Admin role must be assigned for all relevant functions, including DFW.

See User Management in the NSX Administration Guide.

9. Define a backup schedule for the NSX Manager.

See NSX Backup and Restore in the NSX Administration Guide.

Certificates

When you first install NSX, self-signed certificates are used. It is not recommended that you use these in production. At a high level, the steps for replacing the certificates on the NSX Managers are:

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

For the full process, see NSX Manager SSL Certification in the NSX Documentation

NSX Distributed Firewall Rules for Horizon 7

The NSX firewall rules implemented in this reference architecture can be grouped into the following categories: 

The configuration uses the isolation and segmentation features of NSX to protect the Horizon 7 environment.

Note: The tables in this appendix occasionally use the following abbreviations:

  • SG – Security Group
  • UAG – Unified Access Gateway
  • vIDM – VMware Identity Manager
  • VDI – Virtual desktop machine
  • RDSHost – RDSH server machine
  • V4H – vRealize Operations for Horizon
  • UEM – User Environment Manager

Resource Block of VDI and RDSH Machines and Infrastructure

The following tables list the rules that apply to the resource block, where the virtual desktops reside. These rules block desktop-to-desktop communication and allow only the necessary communications to the corresponding infrastructure services within the management block.

Note: In the tables, SG means security group.

 

 

Connectivity - Internal Connections

 

Rule

Name

Source

Destination

Service

Action

Applied To

1

Internal - Horizon Client to Horizon Agent

any

SG-Horizon7-VDI
SG-Horizon7-RDSHost

Blast Extreme TCP Excellent Typical Horizon Client to Horizon Agent
Blast Extreme UDP Typical Horizon Client to Horizon Agent
RDP Horizon Client to Horizon Agent
CDR MMR Horizon Client to Horizon Agent
USB Horizon Client to Horizon Agent USB Redirection
PCoIP TCP Horizon Client to Horizon Agent
PCoIP UDP Horizon Client to Horizon Agent

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost

2

Internal - Browser to Horizon Agent HTML

any

SG-Horizon7-VDI
SG-Horizon7-RDSHost

Browser to Horizon Agent HTML Access

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost

Table 109: Connectivity Rule Set for Internal Connections

The following table lists the services that are affected by the rules listed in the preceding table.

Connectivity - Internal Connections Services

 

Service Name

Port

Protocol

Blast Extreme TCP Excellent Typical Horizon Client to Horizon Agent

22443

TCP

Blast Extreme UDP Typical Horizon Client to Horizon Agent

22443

UDP

RDP Horizon Client to Horizon Agent

3389

TCP

CDR MMR Horizon Client to Horizon Agent

9427

TCP

USB Horizon Client to Horizon Agent USB Redirection

32111

TCP

PCoIP TCP Horizon Client to Horizon Agent

4172

TCP

PCoIP UDP Horizon Client to Horizon Agent

4172

UDP

Table 110: Internal Connections Services

 

 

Desktops - VDI or RDS Host

 

Rule

Name

Source

Destination

Service

Action

Applied To

3

Desktops - Horizon Agent to Connection Server JMS

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-ConnServer

JMS Horizon Agent to Connection Server Enhanced
JMS Horizon Agent to Connection Server Legacy

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost
SG-Horizon7-ConnServer

4

Desktops - Horizon Agent to V4H

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-V4H

Horizon Agent to V4H RMI
Horizon Agent to V4H Desktop Message Server

Allow

SG-Horizon7-VDISG-Horizon7-RDSHost
-SG-Horizon7-V4H

5

Desktops - App Volumes Agent to App Volumes Manager

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-AppVolMgr

App Volumes Agent to App Volumes Manager SSL
App Volumes Agent to App Volumes Manager Standard

Allow

SG-Horizon7-RDSHost

6

Desktops - UEM Flex Engine to UEM File Servers

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-UEM_FS

User Environment Manager to UEM File Servers SMB

Allow

SG-Horizon7-V4H

7

Desktops - Block VDI to VDI

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-VDI
SG-Horizon7-RDSHost

any

Block

SG-Horizon7-VDI
SG-Horizon7-RDSHost

Table 111: Desktops Rule Set for VDI and RDSH

The following table lists the services that are affected by the rules listed in the preceding table.

 

Desktops - VDI or RDS Host Services

 

Service Name

Port

Protocol

JMS Horizon Agent to Connection Server Enhanced

4002

TCP

JMS Horizon Agent to Connection Server Legacy

4001

TCP

Horizon Agent to V4H RMI

3091

TCP

Horizon Agent to V4H Desktop Message Server

3099

TCP

App Volumes Agent to App Volumes Manager SSL

443

TCP

App Volumes Agent to App Volumes Manager Standard

80

TCP

User Environment Manager to UEM File Servers SMB

445

TCP

Table 112: VDI and RDSH Services

Management Block for Horizon 7 Infrastructure Components

The following tables list the rules that apply to the resource block where the Horizon 7 infrastructure and related services reside. These rules allow only the necessary communications among the various infrastructure services and to the virtual desktops within the resource block.

 

 

Connectivity - External Connections

 

Rule

Name

Source

Destination

Service

Action

Applied To

8

External - Horizon Client to UAG

any

SG-Horizon7-UAG

Horizon Client to Unified Access Gateway
Browser to Unified Access Gateway HTML Access
Browser to Unified Access Gateway vIDM
Blast Extreme TCP 443 Excellent Typical Horizon Client to Unified Access Gateway
Blast Extreme TCP 8443 Excellent Typical Horizon Client to Unified Access Gateway
Blast Extreme UDP 443 Poor Typical Horizon Client to Unified Access Gateway
Blast Extreme UDP 8443 Poor Typical Horizon Client to Unified Access Gateway
PCoIP TCP Horizon Client to Unified Access Gateway
PCoIP UDP Horizon Client to Unified Access Gateway

Allow

SG-Horizon7-UAG

Table 113: Connectivity Rule Set for External Connections

The following table lists the services that are affected by the rules listed in the preceding table.

 

Connectivity - External Connections Services

 

Service Name

Port

Protocol

Horizon Client to Unified Access Gateway

443

TCP

Browser to Unified Access Gateway HTML Access

443

TCP

Browser to Unified Access Gateway vIDM

443

TCP

Blast Extreme TCP 443 Excellent Typical Horizon Client to Unified Access Gateway

443

TCP

Blast Extreme TCP 8443 Excellent Typical Horizon Client to Unified Access Gateway

8443

TCP

Blast Extreme UDP 443 Poor Typical Horizon Client to Unified Access Gateway

443

UDP

Blast Extreme UDP 8443 Poor Typical Horizon Client to Unified Access Gateway

8443

UDP

PCoIP TCP Horizon Client to Unified Access Gateway

4172

TCP

PCoIP UDP Horizon Client to Unified Access Gateway

4172

UDP

Table 114: External Connections Services

 

 

Connectivity - Internal Connections

 

Rule

Name

Source

Destination

Service

Action

Applied To

9

Internal - Browser to vIDM

any

SG-Horizon7-vIDM

Browser to VMware Identity Manager

Allow

SG-Horizon7-vIDM

10

Internal - Browser to Horizon Agent HTML

any

SG-Horizon7-VDI

Browser to Horizon Agent HTML Access

Allow

SG-Horizon7-VDI

11

Internal - Horizon Client to Connection Server

any

SG-Horizon7-ConnServer

HTTP Horizon Client to Connection Servers Standard
HTTPS Horizon Client to Connection Servers SSL

Allow

SG-Horizon7-ConnServer

Table 115: Connectivity Rule Set for Internal Connections

The following table lists the services that are affected by the rules listed in the preceding table.

 

Connectivity - Internal Connections Services

 

Service Name

Port

Protocol

Browser to VMware Identity Manager

443

TCP

Browser to Horizon Agent HTML Access

443

TCP

HTTP Horizon Client to Connection Servers Standard

80

TCP

HTTPS Horizon Client to Connection Servers SSL

443

TCP

Table 116: Internal Connections Services

 

 

Desktops - VDI or RDS Host

 

Rule

Name

Source

Destination

Service

Action

Applied To

12

Desktops - App Volumes Agent to App Volumes Manager

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-AppVolMgr

App Volumes Agent to App Volumes Manager SSL
App Volumes Agent to App Volumes Manager Standard

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost
SG-Horizon7-AppVolMgr

13

Desktops - Horizon Agent to V4H

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-V4H

Horizon Agent to V4H RMI
Horizon Agent to V4H Desktop Message Server

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost
SG-Horizon7-V4H

14

Desktops - Horizon Agent to Connection Server JMS

SG-Horizon7-VDI
SG-Horizon7-RDSHost

SG-Horizon7-ConnServer

JMS Horizon Agent to Connection Server Enhanced
JMS Horizon Agent to Connection Server Legacy

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost
SG-Horizon7-ConnServer

Table 117: Desktops Rule Set for VDI and RDSH

The following table lists the services that are affected by the rules listed in the preceding table.

 

Desktops - VDI or RDS Host Services

 

Service Name

Port

Protocol

App Volumes Agent to App Volumes Manager SSL

443

TCP

App Volumes Agent to App Volumes Manager Standard

80

TCP

Horizon Agent to V4H RMI

3091

TCP

Horizon Agent to V4H Desktop Message Server

3099

TCP

JMS Horizon Agent to Connection Server Enhanced

4002

TCP

JMS Horizon Agent to Connection Server Legacy

4001

TCP

Table 118: VDI and RDSH Services

Connection Servers

 

Infrastructure - Connection Server

 

Rule

Name

Source

Destination

Service

Action

Applied To

15

Infrastructure - Connection Server to External DB

SG-Horizon7-ConnServer

SG-Horizon7-Database

Connection Server to MSSQL

Allow

SG-Horizon7-VDI
SG-Horizon7-ConnServer

16

Infrastructure - Connection Server to vCenter Server

SG-Horizon7-ConnServer

SG-Horizon7-vCenterMgmt

HTTPS Connection Server to vCenter Server SOAP

Allow

SG-Horizon7-ConnServer
SG-Horizon7-vCenterMgmt

17

Infrastructure - Connection Server to Composer

SG-Horizon7-ConnServer

SG-Horizon7-Composer

Connection Server to Composer SOAP

Allow

SG-Horizon7-ConnServer
SG-Horizon7-Composer

18

Infrastructure - Connection Server to Connection Server

SG-Horizon7-ConnServer

SG-Horizon7-ConnServer

Cloud Pod Inter-Pod
JMS Connection Server to Connection Server Legacy
JMS Connection Server to Connection Server SSL
CPA Global LDAP Replication
CPA Global LDAP Replication SSL
Connection Server Install Replica

Allow

SG-Horizon7-ConnServer

19

Infrastructure - Connection Server to Enrollment Server

SG-Horizon7-ConnServer

SG-Horizon7-EnrollServer

Connection Server to Enrollment Server View Framework

Allow

SG-Horizon7-ConnServer
SG-Horizon7-EnrollServer

20

Infrastructure - Connection Server to vIDM

SG-Horizon7-ConnServer

SG-Horizon7-vIDM

Connection Server to VMware Identity Manager Message Bus

Allow

SG-Horizon7-ConnServer
SG-Horizon7-vIDM

21

Infrastructure - Connection Server to V4H

SG-Horizon7-ConnServer

SG-Horizon7-V4H

Connection Server to V4H RMI
Connection Server to V4H Broker Message Server
Connection Server to V4H Cert Management Server

Allow

SG-Horizon7-ConnServer
SG-Horizon7-V4H

22

Infrastructure - Connection Server to 2FA Manager

SG-Horizon7-ConnServer

SG-Horizon-2FA

Default Connection Server to 2FA Manager

Allow

SG-Horizon7-ConnServer
SG-Horizon-2FA

Table 119: Infrastructure Rule Set for Connection Servers

The following table lists the services that are affected by the rules listed in the preceding table.

Infrastructure - Connection Server Services

 

Service Name

Port

Protocol

Connection Server to MSSQL

1433

TCP

HTTPS Connection Server to vCenter Server SOAP

443

TCP

Connection Server to Composer SOAP

18443

TCP

Cloud Pod Inter-Pod

8472

TCP

JMS Connection Server to Connection Server Legacy

4100

TCP

JMS Connection Server to Connection Server SSL

4101

TCP

CPA Global LDAP Replication

22389

TCP

CPA Global LDAP Replication SSL

22636

TCP

Connection Server Install Replica

32111

TCP

Connection Server to Enrollment Server View Framework

32111

TCP

Connection Server to VMware Identity Manager Message Bus

443

TCP

Connection Server to V4H RMI

3901

TCP

Connection Server to V4H Broker Message Server

3101

TCP

Connection Server to V4H Cert Management Server

3100

TCP

Default Connection Server to 2FA Manager

5500

UDP

Table 120: Connection Server Services

 

Unified Access Gateway

 

Infrastructure - Unified Access Gateway (UAG)

 

Rule

Name

Source

Destination

Service

Action

Applied To

23

Infrastructure - UAG to Connection Server

SG-Horizon7-UAG

SG-Horizon7-ConnServer

Unified Access Gateway to Connection Server Login

Allow

SG-Horizon7-VDI
SG-Horizon7-ConnServer

24

UAG to Horizon Agent

SG-Horizon7-UAG

SG-Horizon7-VDI
SG-Horizon7-RDSHost

Unified Blast Extreme TCP Unified Access Gateway to Horizon Agent
Unified Blast Extreme UDP Unified Access Gateway to Horizon Agent
PCoIP TCP Unified Access Gateway to Horizon Agent
PCoIP UDP Unified Access Gateway to Horizon Agent
RDP Unified Access Gateway to Horizon Agent
CDR MMR Unified Access Gateway to Horizon Agent
USB Unified Access Gateway to Horizon Agent USB Redirection
Unified Access Gateway to Horizon Agent
Default Unified Access Gateway to 2FA

Allow

SG-Horizon7-VDI
SG-Horizon7-RDSHost
SG-Horizon7-UAG

Table 121: Infrastructure Rule Set for Unified Access Gateway

The following table lists the services that are affected by the rules listed in the preceding table.

Infrastructure - Unified Access Gateway Services

 

Service Name

Port

Protocol

Unified Access Gateway to Connection Server Login

443

TCP

Unified Blast Extreme TCP Unified Access Gateway to Horizon Agent

22443

TCP

Unified Blast Extreme UDP Unified Access Gateway to Horizon Agent

22443

UDP

PCoIP TCP Unified Access Gateway to Horizon Agent

4172

TCP

PCoIP UDP Unified Access Gateway to Horizon Agent

4172

UDP

RDP Unified Access Gateway to Horizon Agent

3389

TCP

CDR MMR Unified Access Gateway to Horizon Agent

9427

TCP

USB Unified Access Gateway to Horizon Agent USB Redirection

32111

TCP

Unified Access Gateway to Horizon Agent

443

TCP

Default Unified Access Gateway to 2FA

5500

UDP

Table 122: Unified Access Gateway Services

 

VMware Identity Manager

 

Infrastructure - VMware Identity Manager (vIDM)

 

Rule

Name

Source

Destination

Service

Action

Applied To

25

Infrastructure - vIDM to Connection Server

SG-Horizon7-vIDM

SG-Horizon7-ConnServer

LDAP VMware Identity Manager to Connection Server
HTTPS VMware Identity Manager to Connection Server

Allow

SG-Horizon7-vIDM
SG-Horizon7-ConnServer

26

Infrastructure - vIDM to vIDM

SG-Horizon7-vIDM

SG-Horizon7-vIDM

HTTPS VMware Identity Manager to VMware Identity Manager
VMware Identity Manager to VMware Identity Manager Audit

Allow

SG-Horizon7-vIDM

27

Infrastructure - vIDM to SMTP Server

SG-Horizon7-vIDM

SG-Horizon7-SMTP

VMware Identity Manager to SMTP Server

Allow

SG-Horizon7-vIDM
SG-Horizon7-SMTP

28

Infrastructure - vIDM to Domain Controller

SG-Horizon7-vIDM

SG-Horizon7-DomainCtrl

LDAP VMware Identity Manager to Domain Controller
Kerberos TCP VMware Identity Manager to Domain Controller
Kerberos UDP VMware Identity Manager to Domain Controller
TCP Kerberos PWD VMware Identity Manager to Domain Controller
UDP Kerberos PWD VMware Identity Manager to Domain Controller
RPC VMware Identity Manager to Domain Controller

Allow

SG-Horizon7-vIDM
SG-Horizon7-DomainCtrl

29

Infrastructure - vIDM to DNS

SG-Horizon7-vIDM

SG-Horizon7-DNS

DNS TCP VMware Identity Manager to DNS Server
DNS UDP VMware Identity Manager to DNS Server

Allow

SG-Horizon7-vIDM
SG-Horizon7-DNS

30

Infrastructure - vIDM to ThinApp FS

SG-Horizon7-vIDM

SG-Horizon7-ThinApp_FS

VMware Identity Manager to ThinApp File Servers SMB

Allow

SG-Horizon7-vIDM
SG-Horizon7-ThinApp_FS

31

Infrastructure - vIDM to Upgrade Server

SG-Horizon7-vIDM

SG-Horizon7-UpdateServer

VMware Identity Manager to Upgrade Server

Allow

SG-Horizon7-vIDM
SG-Horizon7-UpdateServer

32

Infrastructure - vIDM to 2FA Manager

SG-Horizon7-vIDM

SG-Horizon7-2FA

VMware Identity Manager Default to 2FA Manager

Allow

SG-Horizon7-vIDM
SG-Horizon7-2FA

33

Infrastructure - vIDM to AirWatch

SG-Horizon7-vIDM

SG-Horizon7-AirWatch

VMware Identity Manager to VMware AirWatch REST API

Allow

SG-Horizon7-vIDM
SG-Horizon7-AirWatch

34

Infrastructure - vIDM to External DB

SG-Horizon7-vIDM

SG-Horizon7-Database

VMware Identity Manager to External MSSQL
VMware Identity Manager to External PostgreSQL
VMware Identity Manager to External Oracle

Allow

SG-Horizon7-vIDM
SG-Horizon7-Database

Table 123: Infrastructure Rule Set for VMware Identity Manager

 

The following table lists the services that are affected by the rules listed in the preceding table.

Infrastructure - VMware Identity Manager Services

 

Service Name

Port

Protocol

LDAP VMware Identity Manager to Connection Server

389

TCP

HTTPS VMware Identity Manager to Connection Server

443

TCP

HTTPS VMware Identity Manager to VMware Identity Manager

443

TCP

VMware Identity Manager to VMware Identity Manager Audit

93009400

TCP

VMware Identity Manager to SMTP Server

25

TCP

LDAP VMware Identity Manager to Domain Controller

389

TCP

Kerberos TCP VMware Identity Manager to Domain Controller

88

TCP

Kerberos UDP VMware Identity Manager to Domain Controller

88

UDP

TCP Kerberos PWD VMware Identity Manager to Domain Controller

464

TCP

UDP Kerberos PWD VMware Identity Manager to Domain Controller

464

UDP

RPC VMware Identity Manager to Domain Controller

135

TCP

DNS TCP VMware Identity Manager to DNS Server

53

TCP

DNS UDP VMware Identity Manager to DNS Server

53

UDP

VMware Identity Manager to ThinApp File Servers SMB

445

TCP

VMware Identity Manager to Upgrade Server

443

TCP

VMware Identity Manager Default to 2FA Manager

5500

UDP

VMware Identity Manager to VMware AirWatch REST API

443

TCP

VMware Identity Manager to External MSSQL

1433

TCP

VMware Identity Manager to External PostgreSQL

5432

TCP

VMware Identity Manager to External Oracle

1521

TCP

Table 124: Identity Manager Services

 

App Volumes Manager

 

Infrastructure - App Volumes Manager

 

Rule

Name

Source

Destination

Service

Action

Applied To

35

App Volumes Manager to External DB

SG-Horizon7-AppVolMgr

SG-Horizon7-Database

App Volumes Manager Default to MSSQL

Allow

SG-Horizon7-AppVolMgr
SG-Horizon7-Database

36

App Volumes Manager to ESXi

SG-Horizon7-AppVolMgr

SG-Horizon7-VDI-ESXi

App Volumes Manager to ESXi Hosts

Allow

SG-Horizon7-AppVolMgr
SG-Horizon7-VDI-ESXi

37

App Volumes Manager to vCenter Server

SG-Horizon7-AppVolMgr

SG-Horizon7-vCenterVDI_RDSH

App Volumes Manager to vCenter Server SOAP

Allow

SG-Horizon7-AppVolMgr
SG-Horizon7-vCenterVDI_RDSH

Table 125: Infrastructure Rule Set for App Volumes Manager

The following table lists the services that are affected by the rules listed in the preceding table.

 

Infrastructure - App Volumes Manager Services

 

Service Name

Port

Protocol

App Volumes Manager Default to MSSQL

1433

TCP

App Volumes Manager to ESXi Hostd

443

TCP

App Volumes Manager to vCenter Server SOAP

443

TCP

Table 126: App Volumes Manager Services

vRealize Operations for Horizon

 

Infrastructure - vRealize Operations for Horizon (V4H)

 

Rule

Name

Source

Destination

Service

Action

Applied To

38

V4H to Connection Server

SG-Horizon7-V4H

SG-Horizon7-ConnServer

V4H to Connection Server RMI
V4H to Connection Server Broker Message Server
V4H to Connection Server Cert Management Server

Allow

SG-Horizon7-V4H
SG-Horizon7-ConnServer

39

V4H to Horizon Agent

SG-Horizon7-V4H

SG-Horizon7-vCenterMgmt

V4H to Horizon Agent RMI
V4H to Horizon Agent Desktop Message Server

Allow

SG-Horizon7-V4H
SG-Horizon7-vCenterMgmt

40

V4H to UAG Monitoring

SG-Horizon7-V4H

SG-Horizon7-UAG

V4H to Unified Access Gateway Monitoring

Allow

SG-Horizon7-V4H
SG-Horizon7-UAG

41

V4H to App Volumes Manager Monitoring

SG-Horizon7-V4H

SG-Horizon7-AppVolMgr

V4H to App Volumes Manager Monitoring

Allow

SG-Horizon7-V4H
SG-Horizon7-AppVolMgr

Table 127: Infrastructure Rule Set for vRealize Operations for Horizon

The following table lists the services that are affected by the rules listed in the preceding table.

 

Infrastructure - vRealize Operations for Horizon Services

 

Service Name

Port

Protocol

V4H to Connection Server RMI

3091

TCP

V4H to Connection Server Broker Message Server

3101

TCP

V4H to Connection Server Cert Management Server

3100

TCP

V4H to Horizon Agent RMI

3901

TCP

V4H to Horizon Agent Desktop Message Server

3909

TCP

V4H to Unified Access Gateway Monitoring

9443

TCP

V4H to App Volumes Manager Monitoring

443

TCP

Table 128: vRealize Operations for Horizon Services

 

Management

 

Infrastructure - Management

 

Rule

Name

Source

Destination

Service

Action

Applied To

42

Management - Admin Console to UAG

SG-Horizon7-AdCon

SG-Horizon7-UAG

Admin Console to Unified Access Gateway

Allow

SG-Horizon7-AdCon
SG-Horizon7-UAG

43

Management - Admin Console to Conn Server, vCenter, AppV Mgr, V4H, vIDM

SG-Horizon7-AdCon

SG-Horizon7-ConnServer

Admin Console to Connection Server
Admin Console to vCenter Server
Admin Console to App Volumes Manager
Admin Console to VMware Identity Manager
Admin Console to V4H

Allow

SG-Horizon7-vIDM
SG-Horizon7-ConnServer
SG-Horizon7-AdCon
SG-Horizon7-V4H
SG-Horizon7-vCenterMgmt
SG-Horizon7-AppVolMgr

Table 129: Infrastructure Rule Set for Management

The following table lists the services that are affected by the rules listed in the preceding table.

 

Infrastructure – Management Services

 

Service Name

Port

Protocol

Admin Console to Unified Access Gateway

9443

TCP

Admin Console to Connection Server

443

TCP

Admin Console to vCenter Server

443

TCP

Admin Console to App Volumes Manager

443

TCP

Admin Console to VMware Identity Manager

8443

TCP

Admin Console to V4H

443

TCP

Table 130: Management Services

 

Connectivity Rule for Block All

 

Connectivity - Block All

 

Rule No.

Name

Source

Destination

Service

Action

Applied To

44

Block All

SG-Horizon7-ALL

SG-Horizon7-ALL

any

Block

SG-Horizon7-ALL

Table 131: Connectivity Rule for Block All

Appendix D: Horizon 7 Recovery Services Test Plan

This section includes test plans for the two main recovery services described in this reference architecture:

Active/Passive Horizon 7 Service Failover Test/Recovery Plan

In the following test, a persistent desktop user s1-Finance1, with a home site of Site 1, a User Environment Manager profile, and assigned AppStacks and a writable volume, fails over from Site 1 to Site 2 after a DR event.

Active/Passive Horizon 7 Service Failover Test/Recovery Plan

Figure 138: Active/Passive Horizon 7 Service Failover Test/Recovery Plan

The following table lists the preliminary tests and checks to be performed. 

Test 

Name 

Description 

Expectation 

Outcome 

0.1 

Test user login in Site 1 

Log in with user S1-Finance1 to Site 1. Change the desktop background.

User logs in successfully and the desktop change is written to the background.

As expected 

0.2 

Test user login in Site 2 

Log in with user S2-Finance1 to Site 2. Change the desktop background.

User logs in successfully and the desktop change is written to the background.

As expected 

0.3 

Identify candidate site to bring offline 

Select the site with master-of-operations domain controller/SQL Server Always On primary role, in order to simulate full site failover.

Candidate is identified for the failover test.

Site 1 identified 

0.4 

Prepare timing to record failover 

Prepare a time device to record the time it takes for failover of services from the failed site to the remaining site.

Time source starts recording time when failover occurs.

As expected 

Table 132: Active/Passive Preliminary Tests

The following list of tests includes descriptions of occurrences during an active/passive service failover, the recovery steps required, and the test results.

Test 

Name 

Description 

Expectation 

Outcome 

1.1 

Site failure simulation initiated 

Power is killed to all ESXi servers in Site 1: 

three servers for management VMs, and

three servers for hosting desktops.

ESXi servers in Site 1 – management cluster and all management VMs are offline. ESXi hosts in Site 1 – desktop cluster and all virtual desktops are unavailable. Virtual desktop sessions to Site 1 are killed. Virtual desktop sessions to linked-clone and full-clone desktops in Site 1 are unaffected.

Desktop session for user S1-finance1 terminated 

1.2 

Verify user desktop session to Site 2 (Test 0.2) is still operating normally 

Verify that the user experience of the Site 2 user, who is logged in to Site 2, is same as before the failure of Site 1.

The S2-Finance1 user continues to work as normal (AppStacks, VMware Identity Manager, User Environment Manager configuration and user data).

As expected 

Verify Site 1 user can log in to Site 2 

User S1-Finance1 logs into Site 2.

The user gets an error and cannot launch a desktop.

As expected 

3.0

Point the global load balancer to the load balancer in Site 2 for VMware Identity Manager

Modify the global load balancer or DNS record to point to the load balancer in the secondary data center.

For more details about this process, see Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

As expected

3.1 

Always On failover for VMware Identity Manager

Move the primary role to a node on the SQL Server Always On cluster in Site 2, for the VMware Identity Manager protection groups.

The Always On availability group comes online in Site 2 and can be accessed through the VMware Identity Manager JDBC connection.

As expected

3.2

VMware Identity Manager Sync Connector

Use the VMware Identity Manager administration console to select a sync connector in Site 2.

The sync connector in Site 2 will sync users and groups from the enterprise directory to the VMware Identity Manager Service in Site 2.

As expected 

3.3 

VMware Identity Manager availability verification 

VMware Identity Manager recognizes the Always On availability group listener has changed.

After a few minutes, VMware Identity Manager should be functional again. Verify by logging in as the admin user, and change an entitlement on an existing resource.

As expected 

3.4 

App Volumes Manager is unaffected 

Because App Volumes uses separate standalone databases in each site, no failover action is required.

The S1- Finance1 user can log in and get the correct AppStack because AppStack entitlements are replicated between sites.

As expected 

3.5 

Active Directory FSMO roles 

Site 1 had the master-of-operations domain controller. Necessary to seize FSMO roles for the domain controller in Site 2.

Seizing of all roles is successful and the DFS management console can access the domain-based namespace hosted file servers in Site 2.

As expected 

3.6 

DFS replication 

Remove unavailable referral points from Site 2 and add in a copy from Site 1.

The \\vmweuc.com\data\s1-user-data folder can be written to.

As expected 

3.7 

Recover writable volumes array snapshot 

Copy the latest snapshot on the Site 2 all-flash array from source Site 1 all-flash array. Create a new volume and present it to the Site 2 host group of ESXi servers.

The snapshot is copied to a new volume, COPY-S1-writablevolumes-x.

As expected 

3.8 

Add storage to Site 2 ESXi cluster 

Scan the storage adapters on the ESXi hosts in Site 2.

Add a new datastore and resignature it. Label the vSphere datastore COPY-S1- writablevolumes-x.

The copy of the Site 1 writable volumes datastore is presented to all ESXi hosts in Site 2 and mounted successfully.

As expected 

3.9 

App Volumes Manager – Disable old Site 1 writable volumes reference 

Log in to the App Volumes Manager console. Disable assignments to the S1-writablevolumes-x datastore.

All assignments to the writable volumes datastore in failed Site 1 are successfully disabled.

As expected 

3.10 

App Volumes Manager – Import new COPY-Site1- writable volumes-x datastore 

Log in to the App Volumes Manager console. Import the COPY-S1-writablevolumes-x datastore.

All assignments to writable volumes are successfully added, but to the new valid location.

As expected

Horizon 7 CPA home site override for Site 1 user groups 

Log in to the Horizon Administrator console and set the home site override on the Finance GE to 

S1-Finance > Site 2.

Override succeeds.

As expected

Verify user login for Site 1 user to Site 2 

Log in again with user S1-Finance1 (Step 2) and verify that the user is able to work as before the site failure.

User receives User Environment Manager profile, writable volume, and VMware Identity Manager portal access.

As expected 

Table 133: Active/Passive Test Results

 

Active/Active Horizon 7 Service Failover Test/Recovery Plan

In the test plan depicted in the figure below, a floating desktop user with a User Environment Manager profile and an assigned AppStack fails over from Site 1 to Site 2 after a disaster event.

Active/Active Horizon 7 Service Failover Test/Recovery Plan

Figure 139: Active/Active Horizon 7 Service Failover Test/Recovery Plan

 

The following table lists the preliminary tests and checks to be performed.

Test 

Name 

Description 

Expectation 

Outcome 

0.1 

Test user login in Site 1 

Log in with user S1-sales1 to Site 1.

Change the desktop background.

User logs in successfully and the desktop change is written to the background.

As expected 

0.2 

Test user login in Site 2 

Log in with user S2-sales1 to Site 2.

Change the desktop background.

User logs in successfully and the desktop change is written to the background.

As expected 

0.3 

Identify candidate site to bring offline 

Select the site with the master-of-operations domain controller/SQL Server Always On primary role, in order to simulate a full site failover.

Candidate is identified for the failover test.

Site 1 identified 

0.4 

Prepare timing to record failover 

Prepare a time device to record the time it takes for failover of services from the failed site to the remaining site.

Time source starts recording time when failover occurs.

As expected 

Table 134: Active/Active Preliminary Tests

The following list of tests includes descriptions of occurrences during an active/active service failover, the recovery steps required, and the test results. 

Test 

Name 

Description 

Expectation 

Outcome 

1.1 

Site failure simulation initiated 

Power is killed to all ESXi servers in Site 1: three servers for management VMs, and three servers for hosting desktops. 

ESXi servers in Site 1 – management cluster and all management VMs are offline. ESXi hosts in Site 1 – desktop cluster and all virtual desktops are unavailable. Virtual desktop sessions to Site 1 are killed. Virtual desktop sessions to linked-clone and full-clone desktops in Site 2 are unaffected.

Desktop session for user S1-sales1 terminated 

1.2 

Verify user desktop session to Site 2 (Test 0.2) is still operating normally 

Verify that the user experience of the Site 2 user, who is logged in to Site 2, is the same as before the failure of Site 1.

The S2-sales1 user continues to work as normal (AppStacks, VMware Identity Manager, User Environment Manager configuration and user data).

As expected 

Verify Site 1 user can log in to Site 2 

User S1-sales1 logs in to Site 2.

The S1-sales1 user can log in and get a temporary profile and User Environment Manager configuration settings.

No VMware Identity Manager features are available due to offline SQL.

As expected

3.0

Point the global load balancer to the load balancer in Site 2 for VMware Identity Manager

Modify the global load balancer or DNS record to point to the load balancer in the secondary data center.

For more details about this process, see Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

As expected

3.1 

Always On failover for VMware Identity Manager

Move the primary role to a node on the SQL Server Always On cluster in Site 2, for the VMware Identity Manager protection groups.

The Always On availability group comes online in Site 2 and can be accessed through the VMware Identity Manager JDBC connection.

As expected 

3.2

VMware Identity Manager Sync Connector

Use the VMware Identity Manager administration console to select a sync connector in Site 2.

The sync connector in Site 2 will sync users and groups from the enterprise directory to the VMware Identity Manager Service in Site 2.

As expected 

3.3 

VMware Identity Manager availability verification 

VMware Identity Manager recognizes the Always On availability group listener has changed.

After a few minutes, VMware Identity Manager should be functional again. Verify by logging in as the admin user, and change an entitlement on an existing resource.

As expected 

3.4 

App Volumes Manager is unaffected

Because App Volumes uses separate standalone databases in each site, no failover action is required.

The S1-sales1 user can log in and get the correct AppStack because AppStack entitlements are replicated between sites.

As expected 

3.5 

Active Directory FSMO roles 

Site 1 had the master-of-operations domain controller. Necessary to seize FSMO roles for the domain controller in Site 1.

Seizing of all roles successful and the DFS management console can access the domain-based namespace hosted fileservers in Site 1.

As expected 

3.6 

DFS replication 

Remove unavailable referral points from Site 2 and add in a copy from Site 1.

The \\vmweuc.com\data\ s1-user-data folder can be written to.

As expected 

Verify user login 

Log in again with user S1-Sales1 (Step 2) and verify that the user receives a profile.

DFS referral is available, and the user receives a profile.

As expected 

Table 135: Active/Active Test Results

Notes 

  • Step 3.1 is required only if the failed site held the primary SQL node, necessitating moving the primary role to the continuity site.
  • Step 3.6 is required only if the failed site had the Master of Operations Domain Controller, necessitating moving FSMO roles to the continuity site.

Appendix E: App Volumes Configuration for Multi-site Deployments

This appendix provides detailed instructions for deploying App Volumes across multiple sites, implementing redundancy both within and across sites.

As is described in the Multi-site Design section of the Component Design: App Volumes Architecture chapter, there are two deployment options for the App Volumes database across multiple sites: using separate databases or using a clustered database. This appendix provides detailed procedures for implementing either option. This appendix includes the following sections:

  • Configuration Procedures for a Clustered App VOlumes Database Across Multiple Sites
  • Configuretion Procedures for Seperate App Volumes for Database Instances in Multiple Sites
  • Next Steps: Installing and Setting Up Other App Volumes Components

Configuration Procedures for a Clustered App Volumes Database Across Multiple Sites

This configuration uses a clustered SQL database that is common across Site 1 and Site 2. Database failover is needed if the primary instance fails, as described in Perform a Forced Manual Failover of an Availability Group (SQL Server).

To create a clustered highly available App Volumes database, perform the procedures in the following order:

  1. Create a Windows Server Failover Cluster and Configure Shared Storage.
  2. Install the SQL Server Failover Cluster.
  3. Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance.
  4. Create the App Volumes Clustered Database Using Backup and Restore.
  5. Create and Configure the SQL Server Always On Availability Group for VMware App Volumes.
  6. Install and Configure App Volumes Manager.

Create a Windows Server Failover Cluster and Configure Shared Storage

A Windows Server Failover Clustering (WSFC) failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

To create a WSFC cluster with shared storage:

  1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.
    For instructions, see Setup for Failover Clustering and Microsoft Cluster Service and use these chapters:
    • Chapter 3: Cluster Virtual Machines Across Physical Hosts

      Using a cluster of VMs across physical hosts protects against software failures and hardware failures on the physical machine by placing the cluster nodes on separate VMware ESXi hosts. This configuration requires shared storage on a Fibre Channel SAN for the quorum disk. The VMs share a private network connection, for the private heartbeat, and a public network connection.

      This chapter guides you through the process of creating and configuring the VMs on which you will install the SQL Servers. This chapter also guides you through creating virtual hard disks using unformatted LUNs on SAN datastores. You will create an RDM (raw device mapping) disk in physical compatibility (pass-through) mode.

    • Chapter 5: Use MSCS in an vSphere HA and vSphere RDS Environment
      Because the cluster of MSCS (Microsoft Cluster Service) VMs goes across physical hosts, you must set VM-VM anti-affinity rules to specify that the VMs should be kept apart, on different physical hosts. You must also set VM-Host affinity rules, which requires creating a DRS group for VMs and a DRS group for ESXi hosts. The VM-Host affinity rules specify that the VMs in the VM DRS group can run on the ESXi hosts in the host DRS group.

  2. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.
    In the wizard, select to add the following features:
  3. Create a file server in each site with a shared folder that you will use for the quorum witness; for example, the path to the file share in Site 1 might be something like \\S1-FILE\App-Vol-Quorum.
  4. In each site, in Active Directory, give the cluster object full rights on each SQL server machine.
    • On the domain controller, open Active Directory Users and Groups.
    • On the View menu, make sure that Advanced Features is selected.
    • Navigate to the computer object for one of the SQL Server VMs in the cluster, right-click the object, and select Properties.
    • Click the Security tab, scroll through the list of users, and select the cluster name object (CNO). If the cluster name is not in the list, click Add to add it.
    • In the list of permissions, select the Full Control check box to allow full control, and click OK.

      Active Directory
      f. Repeat these steps for the other SQL Server VMs.
  5. In each site, use vSphere Web Client to create RDM disks for the shared SQL disks:
    • SQL_Data
    • SQL_Logs
    • SQL_Backup
    SQL_Temp and SQL_Binaries are local drives to each SQL Server VM and do not need to be shared.
  6. On each SQL Server VM, map the disks to drive letters.
    For example, map the SQL_Data disk to drive F, map the SQL_Logs disk to drive G, and map the SQL_Backup disk to drive H, so that both VMs use the same drive letters for the same disks. Also, make sure the drive letters for local disks are the same on all VMs. Perform this task for the two SQL Server VMs in Site 1 and the two SQL Server VMs in Site 2.
  7. Open Failover Cluster Manager in each site and verify that the disks appear as available storage.
    Failover Cluster Manager

Install the SQL Server Failover Cluster

In this procedure, you run the Setup.exe program from the SQL Server installation media to install a new failover cluster on the first SQL Server VM. On the second SQL Server VM, you run the Setup.exe program and select to add a node to the existing SQL Server failover cluster that you created on the first SQL Server VM.

To create SQL Server failover cluster instances for both sites:

  1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:
    • Installation page – Select New SQL Server failover cluster installation.
    • Feature Selection page – Select all of the Database Engine Services features.
    • Instance Configuration page – Select Named Instance and enter a name. For example, use S1-App-Vol-Inst for the SQL Server failover instance in Site 1, and use S2-App-Vol-Inst for the instance in Site 2.
    • Cluster Resource Group page – Create a new cluster resource group name for each site.
    • Cluster Network Configuration page – Select the IPv4 check box. Do not select the DHCP check box because the SQL Server VM has a static IP address. Site 1 and Site 2 will have different networks.
    • Server Configuration page – Do not change the startup type for the services that use the Manual startup type. The cluster service must control these services.
    • Database Engine Configuration page ­– On the Data Directories tab, for each item, select the disk that you created for that type of file. For example, place the data root directory, system database directory, and user data directory on the RDM disk you created for SQL data. For the database log directory, select the RDM disk you created for SQL logs, and so on.
      On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators.
      For detailed instructions, see Create a New SQL Server Failover Cluster (Setup).
  2. On the second SQL Server VM in the cluster, run the SQL Server installation wizard, but on the installation page, select Add node to a SQL failover cluster.
    For the other pages, follow the guidelines in the previous step. For detailed instructions about the wizard, see Add or Remove Nodes in a SQL Failover Cluster (Setup).
  3. Open the Failover Cluster Manager, expand the cluster, and verify that the following items are working as expected:
    • Select Roles to verify that the SQL Server cluster instance is running.
    • Select Nodes to verify that SQL Server on both SQL Server VMs is running.
    • Under Storage, select Disks to verify that the RDM disks for data, logs, and backups are all online and are assigned to the SQL Server clustered instance.
  4. Repeat these steps to create the SQL Server instance in Site 2.

Now we have a WSFC cluster with two SQL Server failover instances, and a total of four SQL servers.

Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance

At this point, you will configure cluster quorum settings and specify which cluster nodes (VMs) each cluster instance can run on. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will cast the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure the cluster quorum settings:

  1. Configure quorum votes for Site 1:
    1. In Site 1, open Failover Cluster Manager, right-click the cluster for Site 1, and select More Actions > Configure Cluster Quorum Settings.
    2. Complete the Configure Cluster Quorum Wizard, using the following guidelines:
    3. To verify that the quorum is configured correctly, in Failover Cluster Manager, select Nodes and examine the Assigned Vote column.
      verify quorum configuration
  2. Configure quorum votes for Site 2:
    1. In Site 2, open Failover Cluster Manager, right-click the cluster for Site 2, and select More Actions > Configure Cluster Quorum Settings.
    2. Complete the Configure Cluster Quorum Wizard, using the following guidelines:
      • Select Quorum Configuration Option page – Select Advanced Quorum Configuration.
      • Select Voting Configuration page – Click Select Nodes, and select the check boxes for the SQL Server VMs in Site 2 only. Leave the check boxes for the VMs in Site 1 deselected.
      • Select Quorum Witness – Select Configure a file share witness, click Next, and enter the path to the file share in Site 2; for example, \\S2-FILE\App-Vol-Quorum.
  3. Configure the possible owners for each WSFC instance.
    1. Select Roles in the left pane.
    2. Select the cluster instance for Site 1 in the upper portion of the Roles pane.
    3. Click the Resources tab in the lower pane.
    4. Scroll down and select the resource under Server Name.
    5. Right-click the resource and select Properties.
    6. Click the Advanced Policies tab and deselect the check boxes for the two SQL Server VMs in Site 2. Only the two SQL Server VMs in Site 1 should be possible owners.
      Configure owners for WSFC instance
    7. Click OK on the Advanced Properties tab.
    8. Select the cluster instance for Site 2 (in this example, SQL Server (S2INST), and repeat the steps, but make the two SQL Server VMs in Site 2 the possible owners, and deselect the check boxes for the servers in Site 1.

We are now ready to create the database and configure an Always On availability group for the VMware App Volumes database.

Create the App Volumes Clustered Database Using Backup and Restore

In this procedure, you create the database in Site 1, make a backup, and then create the database in Site 2 by restoring from the backup you created in Site 1.

Note: This procedure is the fourth task in the configuration procedures listed at the beginning of this appendix. Be sure you complete the tasks for creating a WSFC cluster, SQL Server failover cluster instance (FCI), and cluster quorum before completing creating the database using the following procedure.

To create the databases in both sites:

  1. Log in to Microsoft SQL Server Management Studio as the sysadmin or as a user account with sysadmin privileges.
  2. Connect to the SQL Server FCI in Site 1.
  3. Use SQL Server Management Studio to create a new database named app_volumes.
    • Base the login on Windows Authentication pointing to the computer accounts of all the App Volumes Managers by specifying the name of the computer followed by a $ (for example, DOMAIN\AVM-01$). 
    • Associate that login with the app_volumes database as well as the db_owner user mapping. This ensures that all App Volume Managers can authenticate using their computer account and that they all have dbo mappings to the database.
      This document does not give recommendations regarding the sizing of the database for various sizes of deployments. For information about database sizing, see VMware App Volumes 2.x Database Best Practices.
  4. After the database has been created, right-click the app_volumes database and select Tasks > Back Up to create a full backup on Site 1, selecting the SQL_Backup disk (H drive) as the destination for the backup file.
  5. In Site 1, use SQL Server Configuration Manager to set the default port for all IPs to 1433.
    1. Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left pane, and double-click TCP/IP in the right pane.
    2. In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.
    3. Set TCP Port to 1433.
  6. In Site 2, restore the database from the backup file you created in Step 3.
    • On the General page, select Device and browse to and select the database backup file you created from Site 1 in Step 4 of this procedure.
    • On the Options page, for Recovery state, select RESTORE WITH NORECOVERY.
  7. In Site 2, use SQL Server Configuration Manager to set the default port for all IPs to 1433.

Create and Configure the SQL Server Always On Availability Group for VMware App Volumes

In this procedure, you create an Always On availability group, add the SQL Server clustered instance from Site 1 as the primary replica and the instance from Site 2 as the secondary replica. You then configure some advanced parameters for the availability group listener.

To create the availability group:

  1. In preparation for creating the availability group listener, choose a listener name and obtain a corresponding static IP address for Site 1 and a static IP for Site 2.
    For example, in this reference architecture, the listener name is avm-agl, to designate App Volumes Manager availability group listener.
  2. In Site 1, in the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.
  3. Complete the New Availability Group wizard, using the following guidelines:
    • Specify Name page – Use the name that you selected in Step 1.
    • Select Databases page – Select the check box for the VMware App Volumes Manager database; for example, saas.
    • Specify Replicas > Replicas tab – The cluster instance from Site 1 should already be listed. Click Add Replica to connect to and add the cluster instance from Site 2.
      Complete the New Availability Group wizard
    • Specify Replicas > Backup Preferences tab – Select Any Replica. The two server instances are listed and they both have a backup priority of 50 (out of 100).
    • Specify Replicas > Listener tab – Select Create an availability group listener, enter the listener name, set the port to 1433, and click Add to add the IP addresses of the two IP addresses you obtained in Step 1.
      Specify Replicas listener setting
  4. Select Data Synchronization page – Select Full.
    Data Synchronization
    The database is created on the secondary SQL Server failover cluster instance, in Site 2.

    After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas.
    When the process is complete, you can view the new availability groups using the Management Studio.

  5. In Microsoft SQL Management Studio, connect to both SQL Server cluster instances and expand the availability groups. You can see that the availability group (avm-ag) for Site 1 is the primary, as shown in the following figure.
    Primary group in Microsoft SQL Management Studio
    The availability group for Site 2 is the secondary, as shown in the following figure, and the database synchronizes with the database in Site 1.
    Secondary group in Microsoft SQL Management Studio
  6. Open a PowerShell prompt and use the following PowerShell commands to configure advanced listener parameters.
    • Use the Get-ClusterResource and Get-ClusterParameter cmdlets to determine the name of the resource (avm-ag_avm-agl) and its settings, as shown in the following example.
       configure advanced listener parameters
      Configure advanced listener parameters in PowerShell
    • Change the following settings:
      • Use Set-ClusterParameter HostRecordTTL 120 to change HostRecordTTL to a lower value than the default in multi-site deployments. A generally recommended value is 120 seconds, or 2 minutes, rather than the default of 20 minutes. Changing this setting reduces the amount of time to connect to the correct IP address after a failover for legacy clients that cannot use the MultiSubnetFailover parameter.
      • Use Set-ClusterParameter RegisterAllProvidersIP 0 to change RegisterAllProvidersIP to false in multi-site deployments. With this setting, the active IP address is registered in the Client Access Point in the WSFC cluster, reducing latency for legacy clients.
        For instructions on how to configure these settings, see RegisterAllProvidersIP Setting and HostRecordTTL Setting. For sample scripts to configure the recommended settings, see Sample PowerShell Script to Disable RegisterAllProvidersIP and Reduce TTL.
        change HostRecordTTL
    • Use stop-clusterresource and start-clusterresource to restart the avm-agl_avm-agl resource so that the new settings can take effect.
      restart the avm-agl_avm-agl resource

Now that the database is set up and the SQL Server Always On availability groups are configured, you can deploy and configure App Volumes Manager to point to the Always On availability group for the database.

Install and Configure App Volumes Manager

If you have completed the preceding procedures in this appendix, you now have an availability group listener to point to when you install the App Volumes Managers in each site. Perform the following tasks in the specified order:

  1. Install the first App Volumes Manager in the primary site where the primary SQL node is running using the availability group listener FQDN when configuring the ODBC connection.
  2. Complete the App Volumes Manager wizard and add vCenter Servers from both Site 1 and Site 2, including mapping their corresponding datastores.
  3. After machine manager access has been verified from Step 2, continue with installing the second manager in the same site as the first manager.

You can use a global namespace for the App Volumes Manager service between sites, but this is not a requirement. This model adds some complexity because the load balancer is responsible for making sure that desktops in Site 1 are connected to the App Volumes Manager in Site 1 and desktops in Site 2 are connected to the App Volumes Manager in Site 2. The benefit in doing this is in not having to maintain two different configurations in the desktop master image in terms of which FQDN the App Volumes Agent is pointing to. Keep in mind that using separate namespaces is equally valid.

Configuration Procedures for Separate App Volumes for Database Instances in Multiple Sites

This design uses separate App Volumes database instances for each site, rather than using a clustered database across sites. With this option, you still use Always On availability groups, but each site has its own availability group to achieve automatic failover within a site. To make user-based entitlements for AppStacks available between sites, you must use a PowerShell script, which VMware provides. This setup is shown in the following figure.

To use this setup, perform the procedures in the following order:

  1. Create a Windows Server Failover Cluster in Each Site
  2. Install SQL Server 2016 Stand-Alone in All VMs
  3. Create the App Volumes Databases and Enable Availability Groups for the Clusters
  4. Create Always On Availability Groups for App Volumes Databases
  5. Configure Cluster Quorum Settings
  6. Install App Volumes to Use a Highly Available Database

Create a Windows Server Failover Cluster in Each Site

A failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

Note: For information about setting up F5 load balancers for use with App Volumes, see F5 with App Volumes Configuration Guide. If you are using another type of load balancer, verify that you have set up this load balancer according to the vendor’s instructions.

To create a Windows Server Failover Clustering (WSFC) cluster:

  1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.
    • For this reference architecture, we used the Windows Server 2016 Standard operating system in the VMs that run SQL Server.
    • In this example, we named the VMs as follows: At Site 1, we created VMs named s1-sql4 and s1-sql5 on separate ESXi hosts. At Site 2, we created VMs named s2-sql4 and s2-sql5.
    • Set up each VM in the same way, with a total of five 20-GB hard disks: one disk for the Windows OS and five disks for the various types of SQL Server data
      set up VM
      Inside the OS, the disks are mapped to drive letters as follows.
      Disks inside OS
  2. In preparation for creating the failover cluster, choose a cluster name and obtain a corresponding static IP address for the cluster in Site 1 and in Site 2.
    For example, in this reference architecture, for the cluster names, we use s1-sqlclust-2 and s2-sqlclust-2.
  3. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.
    In the wizard, select to add the following features:
  4. Use the Failover Cluster Manager to create a WSFC cluster that includes two SQL Server VMs in Site 1, and then do the same in Site 2.
    For detailed instructions, see the Microsoft blog post Creating a Windows Server 2012 Failover Cluster, and see Create a Failover Cluster. The failover cluster for Site 1 includes the VMs s1-sql4 and s1-sql5. The cluster for Site 2 includes the VMs s2-sql4 and s2-sql5.
    create a WSFC cluster

Install SQL Server 2016 Stand-Alone in All VMs

You install SQL Server Stand-Alone on each VM, rather than creating a SQL Server failover cluster. For App Volumes, you use stand-alone installations and then create Always On availability groups to achieve failover within a site.

To install SQL Server:

  1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:
    • Installation page – Select New SQL Server stand-alone installation.
    • Feature Selection page – Select Database Engine Services and Management Tools - Basic.
    • Instance Configuration page – Select Default instance. The instance ID is MSSQLSERVER.
    • Server Configuration page – The startup type is Automatic for the SQL Server Agent and SQL Server Database Engine.
    • Database Engine Configuration page ­– On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators.
      On the Data Directories tab, for each item, select the disk that you created for that type of file during VM creation. Use the following screen shot as a guide.

      SQL Server setup
      For more information about the setup wizard, see Install SQL Server 2016 from the Installation Wizard (Setup).
  2. Repeat Step 1 to install SQL Server on the other VM in Site 1 and on the VMs in Site 2.
  3. Create a shared folder on the first SQL Server VM in each site; for this example, the VMs are s1-sql4 and s2-sql4).
    • Create a folder named Replication on the SQL_Binaries (E:) drive. You created this drive during Step 1 of Create a Windows Server Failover Cluster.
      Create shared folder on SQL Server
    • Give the SQL service account full permissions on the folder.
      Change permission for SQL service

Create the App Volumes Databases and Enable Availability Groups for the Clusters

This document provides detailed instructions for creating a highly available database but does not give recommendations regarding the sizing of the database for various sizes of deployments. For information about database sizing, see VMware App Volumes 2.x Database Best Practices.

To create the databases:

  1. On first SQL Server VM in each site, use Microsoft SQL Server Management Studio to create an App Volumes database.
    For this example, the VMs are s1-sql4 and s2-sql4.
    • Log in to the Management Studio as the sysadmin or as a user account with sysadmin privileges.
    • Connect to the SQL Server instance on the VM, right-click the Databases folder, and select New Database.
    • Enter a database name and click OK.
      For example, for Site 1, we named the database s1-appvolumes. For Site 2, we named the database s2-appvolumes.
      create another App Volumes database
  2. Open SQL Server Configuration Manager and enable Always On availability groups for the Windows Failover cluster in Site 1 and Site 2.
    For instructions, see Enable and Disable AlwaysOn Availability Groups (SQL Server).
    Configure availability group for SQL server
    The cluster names are the names you created in Step 2 of Create a Windows Server Failover Cluster.
  3. In each site, on the domain controller, open Active Directory Users and Groups, and create a new Computer object for the availability group.
    For this example, for Site 1, the AD computer name for the group is s1-sqlclust2-ag1. For Site 2, the name is s2-sqlclust2-ag1.
    create a new Computer object for the availability group

Create Always On Availability Groups for App Volumes Databases

In this procedure, you create an Always On availability group, adding the SQL Server stand-alone instances from Site 1 as the primary replica and secondary replicas. You then do the same for Site 2, so that each site has its own Always On availability group to achieve automatic failover within each site (but not across sites).

To create the availability groups:

  1. On the first SQL Server VM in Site 1, open the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.
  2. Complete the New Availability Group wizard, using the following guidelines:
    • Specify Name page – Use the name of the AD computer object you just created. For this example, the name is s1-sqlclust2-ag1 for Site 1.
    • Select Databases page – Select the check box for the local database, which is s1-appvolumes in this example.
    • Specify Replicas > Replicas tab – The first SQL Server VM should already be listed. Click Add Replica to connect to and add the second SQL Server VM from this site.
      Specify Replicas Replicas tab
      Important: Select the Synchronous Commit and Automatic Failover check boxes. For the Readable Secondary setting, select No for the primary instance and Yes for the secondary instance.
  3. Select Data Synchronization page – Select Full, and specify the shared Replication folder that you created in Step 3 of Install SQL Server 2016 Stand-Alone.
    Data Synchronization page
    This share is used to synchronize the database on the secondary replica with that on the primary.

    After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas. On the Results page, you can see that the s1-appvolumes database is synchronized between both SQL servers.

    When the process is complete, you can view the new availability groups using the Management Studio. The following screen shot shows the availability group with the primary replica on the s1-sql4 VM.
    view availability groups in the Management Studio
    The following screen shot shows the availability group with the secondary replica on the s1-sql5 VM.
    view availability groups in the Management Studio
  4. Repeat Steps 1 and 2 for Site 2.

Configure Cluster Quorum Settings

At this point, you will configure cluster quorum settings to use a file share witness. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will caste the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure cluster quorum settings:

  1. On a file server in each site, use Server Manager to open and complete the New Share wizard and create an SMB share, using the following guidelines:
    • Select Profile page – Select SMB Share – Quick.
    • ​​​​​Share Location page – For the share location, select Select by volume, and select the drive.
      create an SMB share
    • Permissions page – Click Customize permissions and give the WSFC cluster object full control over the file share.
      Permission setting for SMB share
      When you finish this step, you have two files shares: one for Site 1 and one for Site 2. For more details about accessing and using this wizard, see 12 Steps to NTFS Shared Folders in Windows Server 2012.
  2. Configure the cluster quorum settings for each site:
    • Open Failover Cluster Manager on the first VM in Site 1, right-click the cluster, and select More Actions > Configure Cluster Quorum Settings.
    • Complete the Configure Cluster Quorum Wizard, using the following guidelines:
      • Select Quorum Configuration Option page – Select Select the quorum witness.
      • Select Quorum Witness page – Select Configure a file share witness.
      • Configure File Share Witness page – Enter the path to the file share you created in Step 1.
        Configure File Share Witness
        For detailed instructions, see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.
      • Repeat this procedure to set up a file share quorum witness in Site 2.

You are now ready to install App Volumes and point to the availability group we created.

Install App Volumes to Use a Highly Available Database

This procedure focuses on the specific settings required for connecting App Volumes to a highly available database. For details about other aspects of App Volumes installation, including system requirements, see the VMware App Volumes User Guide.

To install App Volumes:

  1. In preparation for installing App Volumes and connecting to the availability group listener, use SQL Server Configuration Manager on each SQL Server VM to enable named pipes.Enable named pipes

    For instructions, see Enable or Disable a Server Network Protocol.

    Important: Restart the SQL Server service so the new setting can take effect.
  2. In Site 1, on the first VM on which you want to install App Volumes, download the App Volumes Manager installer, start the installation wizard, and follow the prompts to the Database Server page.
  3. Complete the Database Server page, using the following guidelines:
  4. On the Choose Network Ports page, verify that the HTTP port is set to 80 and the HTTPS port is set to 443.
  5. Follow the rest of the wizard prompts to complete the installation.
  6. Repeat Steps 1–5 on the second App Volumes VM in Site 1, but on the Database Server page, be sure to leave the Overwrite existing database (if any) check box deselected.
    Both App Volumes Managers in Site 1 must point to the same highly available database.
  7. Repeat this entire procedure in Site 2.

With App Volumes successfully installed, you can begin configuration. For detailed instructions see the VMware App Volumes User Guide. Also see the VMware App Volumes Reference Architecture.

The procedures in this appendix create a setup in which the App Volumes database can failover automatically within each site. Site 1 and Site 2 have separate databases, but during a failover, users for Site 1 will be able to use replicated App Volumes AppStacks in Site 2 as long as the user entitlements are also replicated. For configuration details, see the next section, PowerShell Script for Replicating App Volumes Application Entitlements.

PowerShell Script for Replicating App Volumes Application Entitlements

To use this script, you copy and paste the script, either to the database VM, to run the script locally on the server, or to another location, where you can run the script remotely as long as you have an account with the proper permissions and the machine meets the following software requirements:

  • Windows Management Framework 4.0
  • Microsoft .NET Framework 4.5

Next, open the script with a text editor and change the username, password, source server, and destination server to match your environment. These items are shown in bold text, in the first five lines of the following script. When you are finished, save the file with a .ps1 extension.

 

$Credentials = @{

    username = 'domain\username'

    password = 'password'

}

 

$SourceServer = "SourceServerFQDN"

$TargetServer = "DestinationServerFQDN"

 

Invoke-RestMethod -SessionVariable SourceServerSession -Method Post -Uri "https://$SourceServer/cv_api/sessions" -Body $Credentials

Invoke-RestMethod -SessionVariable TargetServerSession -Method Post -Uri "https://$TargetServer/cv_api/sessions" -Body $Credentials

 

 

$SourceAssignments = (Invoke-RestMethod -WebSession $SourceServerSession -Method Get -Uri "https://$SourceServer/cv_api/assignments").assignments

 

$SourceAppstacks = Invoke-RestMethod -WebSession $SourceServerSession -Method Get -Uri "https://$SourceServer/cv_api/appstacks"

$TargetAppStacks = Invoke-RestMethod -WebSession $TargetServerSession -Method Get -Uri "https://$TargetServer/cv_api/appstacks"

 

foreach ($Assignment in $SourceAssignments)

{

    $SourceAppStack = $SourceAppStacks.Where({$_.id -eq $assignment.snapvol_id})[0]   

    $TargetAppStack = $TargetAppStacks.Where({$_.name -eq $SourceAppstack.name})[0]  

    Invoke-RestMethod  -WebSession $TargetServerSession -Method Post -Uri "https://$TargetServer/cv_api/assignments?action_type=assign&id=$($TargetAppStack.id)&assignments%5B0%5D%5Bentity_type%5D=$($assignment.entityt)&assignments%5B0%5D%5Bpath%5D=$($assignment.entity_dn)"

   

}

Next Steps: Installing and Setting Up Other App Volumes Components

After installation is complete, you must perform the following tasks to start using App Volumes:

  • Complete the App Volumes Initial Configuration Wizard (https://avmanager).
  • To optimize the speed of AppStack attachments, it is recommended that mount on host is set. This requires user accounts with same username and password on all resource vSphere hosts.
  • Install the App Volumes Agent on one or more clients and point the agent to the App Volumes Manager address (load-balanced address).
  • Select a clean provisioning system and provision an AppStack. See Working with AppStacks in the VMware App Volumes Administration Guide for instructions.
  • Assign the AppStack to a test user and verify it is connecting properly.
  • Assign a writable volume to a test user and verify it is connecting properly.

Appendix F: VMware Identity Manager Configuration for Multi-site Deployments

Use the procedures in this appendix to create SQL Server clustered instances that can fail over between sites and to set up a highly available database for VMware Identity Manager. The following diagram shows the architecture.

VMware Identity Manager Architecture 

Figure 140: VMware Identity Manager Architecture 

The tasks you need to complete are grouped into the following procedures:

  1. Create a Windows Server Failover Cluster and Configure Shared Storage
  2. Install the SQL Server Failover Cluster
  3. Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance
  4. Create the VMware Identity Manager Database
  5. Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager
  6. Deploy and Set Up VMware Identity Manager Appliances
  7. Configure Failover and Redundancy for VMware Identity Manager
  8. Deploy and Set Up the VMware Identity Manager Connectors Inside the Corporate Network
  9. Finalizing Failover Preparation

Create a Windows Server Failover Cluster and Configure Shared Storage

A Windows Server Failover Clustering (WSFC) failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

To create a WSFC cluster with shared storage:

  1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.
    For instructions, see Setup for Failover Clustering and Microsoft Cluster Service and use these chapters:
    • Chapter 3: Cluster Virtual Machines Across Physical Hosts
      Using a cluster of VMs across physical hosts protects against software failures and hardware failures on the physical machine by placing the cluster nodes on separate VMware ESXi hosts. This configuration requires shared storage on a Fibre Channel SAN for the quorum disk. The VMs share a private network connection, for the private heartbeat, and a public network connection.
      This chapter guides you through the process of creating and configuring the VMs on which you will install the SQL Servers. This chapter also guides you through creating virtual hard disks using unformatted LUNs on SAN datastores. You will create an RDM (raw device mapping) disk in physical compatibility (pass-through) mode.
      Note: For this reference architecture, we used the Windows Server 2016 Standard operating system in the VMs that run SQL Server.
    • Chapter 5: Use MSCS in a vSphere HA and vSphere RDS Environment
      Because the cluster of MSCS (Microsoft Cluster Service) VMs goes across physical hosts, you must set VM-VM anti-affinity rules to specify that the VMs should be kept apart, on different physical hosts. You must also set VM-Host affinity rules, which requires creating a DRS group for VMs and a DRS group for ESXi hosts. The VM-Host affinity rules specify that the VMs in the VM DRS group can run on the ESXi hosts in the host DRS group.
  2. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.
    In the wizard, select to add the following features:
  3. Create a file server in each site with a shared folder that you will use for the quorum witness; for example, the path to the file share in Site 1 might be something like \\S1-FILE\Quorum.
  4. In each site, in Active Directory, give the cluster object full rights on each SQL server machine.
    • On the domain controller, open Active Directory Users and Groups.
    • On the View menu, make sure that Advanced Features is selected.
    • Navigate to the computer object for one of the SQL Server VMs in the cluster, right-click the object, and select Properties.
    • Click the Security tab, scroll through the list of users, and select the cluster name object (CNO).
      If the cluster name is not in the list, click Add to add it.
    • In the list of permissions, select the Full Control check box to allow full control, and click OK.
      Give WSFC cluster full rights
    • Repeat these steps for the other SQL Server VMs.
  5. In each site, use vSphere Web Client to create RDM disks for the shared SQL disks:
    • SQL_Data
    • SQL_Logs
    • SQL_Backup
      SQL_Temp and SQL_Binaries are local drives to each SQL Server VM and do not need to be shared
  6. On each SQL Server VM, map the disks to drive letters.
    For example, map the SQL_Data disk to drive F, map the SQL_Logs disk to drive G, and map the SQL_Backup disk to drive H, so that both VMs use the same drive letters for the same disks. Also, make sure the drive letters for local disks are the same on all VMs. Perform this task for the two SQL Server VMs in Site 1 and the two SQL Server VMs in Site 2.
  7. Open Failover Cluster Manager in each site and verify that the disks appear as available storage.
    Failover Cluster Manager

Install the SQL Server Failover Cluster

In this procedure, you run the Setup.exe program from the SQL Server installation media to install a new failover cluster on the first SQL Server VM. On the second SQL Server VM, you run the Setup.exe program and select to add a node to the existing SQL Server failover cluster that you created on the first SQL Server VM.

To create SQL Server failover cluster instances for both sites:

  1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:
    • Installation page – Select New SQL Server failover cluster installation.
    • Feature Selection page – Select all of the Database Engine Services features.
    • Instance Configuration page – Select Named Instance and enter a name. For example, use S1Inst for the SQL Server failover instance in Site 1, and use S2Inst for the instance in Site 
    • Cluster Resource Group page – Create a new cluster resource group name for each site.
    • Cluster Network Configuration page – Select the IPv4 check box. Do not select the DHCP check box because the SQL Server VM has a static IP address. Site 1 and Site 2 will have different networks.
    • Server Configuration page – Do not change the startup type for the services that use the Manual startup type. The cluster service must control these services.
    • Database Engine Configuration page ­– On the Data Directories tab, for each item, select the disk that you created for that type of file. For example, place the data root directory, system database directory, and user data directory on the RDM disk you created for SQL data. For the database log directory, select the RDM disk you created for SQL logs, and so on.
    • On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators.
      For detailed instructions, see Create a New SQL Server Failover Cluster (Setup).
  2. On the second SQL Server VM in the cluster, run the SQL Server installation wizard, but on the installation page, select Add node to a SQL failover cluster.
  3. For the other pages, follow the guidelines in the previous step. For detailed instructions about the wizard, see Add or Remove Nodes in a SQL Failover Cluster (Setup).

  4. Open the Failover Cluster Manager, expand the cluster, and verify that the following items are working as expected:
    • Select Roles to verify that the SQL Server cluster instance is running.
    • Select Nodes to verify that SQL Server on both SQL Server VMs is running.
    • Under Storage, select Disks to verify that the RDM disks for data, logs, and backups are all online and are assigned to the SQL Server clustered instance.
  5. Repeat these steps to create the SQL Server instance in Site 2.

Now we have a WSFC cluster with two SQL Server failover instances, and a total of four SQL servers.

Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance

At this point, you will configure cluster quorum settings and specify which cluster nodes (VMs) each cluster instance can run on. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will cast the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure the cluster quorum settings:

  1. Configure quorum votes for Site 1:
    • In Site 1, open Failover Cluster Manager, right-click the cluster for Site 1, and select More Actions > Configure Cluster Quorum Settings.
    • Complete the Configure Cluster Quorum Wizard, using the following guidelines:
    • To verify that the quorum is configured correctly, in Failover Cluster Manager, select Nodes and examine the Assigned Vote column.
      Verify quorum configuration
  2. Configure quorum votes for Site 2:
    • In Site 2, open Failover Cluster Manager, right-click the cluster for Site 2, and select More Actions > Configure Cluster Quorum Settings.
    • Complete the Configure Cluster Quorum Wizard, using the following guidelines:
      • Select Quorum Configuration Option page – Select Advanced Quorum Configuration.
      • Select Voting Configuration page – Click Select Nodes, and select the check boxes for the SQL Server VMs in Site 2 only. Leave the check boxes for the VMs in Site 1 deselected.
      • Select Quorum Witness – Select Configure a file share witness, click Next, and enter the path to the file share in Site 2; for example, \\S2-FILE\Quorum.
  3. Configure the possible owners for each WSFC instance.
    • Select Roles in the left pane.
    • Select the cluster instance for Site 1 in the upper portion of the Roles pane.
    • Click the Resources tab in the lower pane.
    • Scroll down and select the resource under Server Name.
    • Right-click the resource and select Properties.
    • Click the Advanced Policies tab and deselect the check boxes for the two SQL Server VMs in Site 2. Only the two SQL Server VMs in Site 1 should be possible owners.
      Configure owners for each WSFC instance
    • Click OK on the Advanced Properties tab.
    • Select the cluster instance for Site 2 (in this example, SQL Server (S2INST), and repeat the steps, but make the two SQL Server VMs in Site 2 the possible owners, and deselect the check boxes for the servers in Site 1.

We are now ready to create the database and configure an Always On availability group for the VMware Identity Manager database.

Create the VMware Identity Manager Database

In this procedure, you create the database in Site 1 and make a backup. You also create the horizon login user.

To create the database and login user:

  1. Log in to Microsoft SQL Server Management Studio as the sysadmin or as a user account with sysadmin privileges.
  2. Connect to the SQL Server clustered instance in Site 1.
  3. Follow the procedure provided in the product documentation to create a new saas database for VMware Identity Manager, along with a login user named horizon.
    See the topic Configure a Microsoft SQL Database in the desired on-premises version of Installing and Configuring VMware Identity Manager. This topic provides a script with SQL commands you must run to create the database and login user.
    Note: The default database name used in the script is saas. The default login user name is horizon. You can modify the script to use different names, but if you use a different name, write the name down.
  4. After the database has been created, right-click the saas database (or, if you modified the database script to use a different name, select that name) and select Tasks > Back Up to create a full backup on Site 1, selecting the SQL_Backup disk (H drive) as the destination for the backup file.
    Back up the saas database
  5. In Site 1, use SQL Server Configuration Manager to set the default port for all IPs to 1433.
    • Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left pane, and double-click TCP/IP in the right pane.
    • In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.
    • Set TCP Port to 1433.
  6. Use the Management Studio to export the horizon user credentials on Site 1 (or, if you modified the database script to use a different name, export that user’s credentials), as described in the Microsoft KB article How to transfer logins and passwords between instances of SQL Server. 
    Important: Use Method 2, which creates a login script with a blank password, and be sure to follow Step 3 of Method 2, which involves running the sp_help_revlogin statement. This step simplifies the process of keeping the SID for the horizon login the same when you create the login on any secondary nodes; otherwise user login association fails upon failover.
    export the horizon user credentials
  7. In Site 2, use the Management Studio to create the horizon user, as described in Method 2 of the Microsoft KB article How to transfer logins and passwords between instances of SQL Server.
    create the horizon user in Management Studio

    As described in the Microsoft documentation, you use the output script that the sp_help_revlogin stored procedure generates.

    It is important to create the login before adding the saas database to the availability group (as described in the next procedure) because that information cannot otherwise be set correctly in the replica databases that are part of the availability group.

  8. Create a new Windows file share that is accessible by each of the four SQL Servers.

Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager

In this procedure, you create an Always On availability group, add the SQL Server clustered instance from Site 1 as the primary replica and the instance from Site 2 as the secondary replica. You then configure some advanced parameters for the availability group listener.

To create the availability group:

  1. In preparation for creating the availability group listener, choose a listener name and obtain a corresponding static IP address for Site 1 and a static IP for Site 2.
    For example, in this reference architecture, the listener name is idm-agl, to designate VMware Identity Manager availability group listener.
  2. In Site 1, in the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.
  3. Complete the New Availability Group wizard, using the following guidelines:
    • Specify Name page – Use the name that you selected in Step 1.
    • Select Databases page – Select the check box for the VMware Identity Manager database; for example, saas.
    • Specify Replicas > Replicas tab – The cluster instance from Site 1 should already be listed. Click Add Replica to connect to and add the cluster instance from Site 2.
      Specify Replicas Replicas tab
    • Specify Replicas > Backup Preferences tab – Select Any Replica. The two server instances are listed and they both have a backup priority of 50 (out of 100).
    • Specify Replicas > Listener tab – Select Create an availability group listener, enter the listener name, set the port to 1433, and click Add to add the IP addresses of the two IP addresses you obtained in Step 1.
      Specify Replicas Listener tab
  4. Select Data Synchronization page – Select Full.
    Data Synchronization page

    The database is created on the secondary SQL Server failover cluster instance, in Site 2.

    After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas.

    When the process is complete, you can view the new availability groups using the Management Studio.
  5. In Microsoft SQL Management Studio, connect to both SQL Server cluster instances and expand the availability groups. You can see that the availability group (idm-ag) for Site 1 is the primary, as shown in the following figure.
    availability group in Microsoft SQL Management Studio
    The availability group for Site 2 is the secondary, as shown in the following figure, and the database synchronizes with the database in Site 1.
    Secondary group in Microsoft SQL Management Studio
  6. Open a PowerShell prompt and use the following PowerShell commands to configure advanced listener parameters.
    • Use the Get-ClusterResource and Get-ClusterParameter cmdlets to determine the name of the resource (idm-ag_idm-agl) and its settings, as shown in the following example.
      configure advanced listener parameters in powershellconfigure advanced listener parameters
    • Change the following settings:
      • Use Set-ClusterParameter HostRecordTTL 120 to change HostRecordTTL to a lower value than the default in multi-site deployments. A generally recommended value is 120 seconds, or 2 minutes, rather than the default of 20 minutes. Changing this setting reduces the amount of time to connect to the correct IP address after a failover for legacy clients that cannot use the MultiSubnetFailover parameter.
      • Use Set-ClusterParameter RegisterAllProvidersIP 0 to change RegisterAllProvidersIP to false in multi-site deployments. With this setting, the active IP address is registered in the Client Access Point in the WSFC cluster, reducing latency for legacy clients.
        For instructions on how to configure these settings, see RegisterAllProvidersIP Setting and HostRecordTTL Setting. For sample scripts to configure the recommended settings, see Sample PowerShell Script to Disable RegisterAllProvidersIP and Reduce TTL.
        change HostRecordTTL
      • Use stop-clusterresource and start-clusterresource to restart the idm-agl_idm-agl resource so that the new settings can take effect.
        restart the idm-agl_idm-agl resource

Now that the database is set up and the SQL Server Always On availability groups are configured, you can deploy and configure VMware Identity Manager to point to the Always On availability group for the database.

Deploy and Set Up VMware Identity Manager Appliances

For this reference architecture, we used the Linux-based VMware Identity Manager virtual appliance, which is a very standard VMware virtual appliance, with all the usual deployment wizard prompts. You can alternatively use the Windows-based VMware Identity Manager. For more information, see Installing and Configuring VMware Identity Manager for Windows.

After deploying VMware Identity Manager instances, you point the appliance to the availability group listener you configured in the previous procedure. The VMware Identity Manager appliances reside in the DMZ within each site.

Important: As part of the following procedure, you will need to enter the fully qualified domain name (FQDN) of the global load balancer you are using. All administration tasks will be undertaken from the VMware Identity Manager administration console at the URL with this global FQDN (https://<global-LB-URL>/admin). You should also configure the local load balancer for Site 1. Before starting the procedure, complete the load balancer prerequisites:

  • Verify that you have set up the local and global load balancers according to the vendor’s instructions, that the FQDN for each load balancer is configured in DNS, and that each load balancer server is assigned a static IP address.
  • On the global load balancer, obtain and install an SSL certificate. You can use a wildcard certificate or a Subject Alternate Name (SAN) certificate. VMware recommends the use of SAN certificates so that you can define the node FQDNs (public or internal) within the load balanced VIP FQDN. If you use a SAN certificate, add the FQDNs of the following servers:
    • Global load balancer
    • The four VMware Identity Manager connectors (two in Site 1 and two in Site 2)
    • The three VMware Identity Manager appliances in Site 2
    • The three VMware Identity Manager appliances in Site 1
    • Local load balancer for Site 2
    • Local load balancer for Site 1
  • On the local load balancer, install the SSL certificate described in the preceding bullet point. You will need to install the root certificate of this SSL certificate on the VMware Identity Manager appliance.
  • Configure the load balancer settings to enable X-Forwarded-For headers, increase the request timeout, and enable sticky sessions. For more information, see the topic Using a Load Balancer or Reverse Proxy to Enable External Access to VMware Identity Manager in Installing and Configuring VMware Identity Manager.
  • Add the FQDNs and IP addresses of three VMware Identity Manager appliances you plan to create for Site 1 to the local load balancer.

If you are using F5, see Load Balancing VMware Identity Manager. This document provides instructions for integrating VMware Identity Manager 2.9.1 nodes with the local load balancer. Also see Managing Horizon Traffic Across Multiple Data Centers with BIG-IP.

To set up VMware Identity Manager:

  1. In vSphere Web Client, use the Deploy OVF Template wizard to deploy the VMware Identity Manager virtual appliance in Site 1
    Set a static IP address. See the topic Install the VMware Identity Manager OVA File in Installing and Configuring VMware Identity Manager for Linux. For network port requirements, see Deploying VMware Identity Manager in the DMZ.
    Note: In our example, the name of this first VMware Identity Manager appliance is s1-idm1.
    Important: In our example, we used the Linux-based VMware Identity Manager. You can alternatively use the Windows-based VMware Identity Manager. See Installing and Configuring VMware Identity Manager for Windows.
  2. After deployment is complete, log in to the VMware Identity Manager browser-based console and follow the prompts to complete the Appliance Setup wizard.
    This involves entering the JDBC URL string and entering the credentials for the horizon database login user. The syntax of the JDBC URL is:
     jdbc:sqlserver://<hostname-of-availability-group-listener>;DatabaseName=saas;multiSubnetFailover=true
    Important: When deploying in a multi-subnet setup, be sure to add multiSubnetFailover=true as part of the JDBC connection string. This option enables faster failover. For more information, see the MultiSubnetFailover Keyword and Associated Features.set up VMware Identity Manager

    Note: When you test the connection, if you get a connection failed error, verify that you set the database port for all IP addresses to 1433, as described in Step 5 of Create the VMware Identity Manager Database.

    For more information about the Appliance Setup wizard, see the topic Configure VMware Identity Manager Settings in the on-premises version of Installing and Configuring VMware Identity Manager.
  3. When the Setup Complete page appears, click the link on the page to continue with other VMware Identity Manager configuration tasks.
    VMware Identity Manager complete setup
  4. Configure user attributes before changing any other configuration settings.
    • Under Identity & Access Management, click the Setup button on the right side of the screen, and choose Change User Attributes.
    • Select the userPrincipalName and distinguishedName attributes.
    • Add the objectGUID attribute.
      Configure user attributes
      For more information, see the topic Configure VMware Identity Manager Settings in the on-premises version of Installing and Configuring VMware Identity Manager.
  5. Use the VMware Identity Manager console to install an SSL certificate and configure SSL for the appliance.
    To offload SSL to your load balancer, see the vendor’s documentation for the load balancer.
    install and configure SSL certificate
    For more information, see the topics Managing Appliance System Configuration Settings and Using SSL Certificates in the on-premises version of Installing and Configuring VMware Identity Manager.
    Important: VMware recommends the use of certificates that support Subject Alternate Names (SANs). Ensure that the VMware Identity Manager certificate includes the FQDN of the load balancer from the primary data center, the FQDN of the load balancer from the secondary data center, and the FQDN of the global load balancer.
  6. Obtain the root certificate for the local load balancer and install it, as described in Apply Load Balancer Root Certificate to VMware identity Manager, in Installing and Configuring VMware Identity Manager.
  7. Configure the VMware Identity Manager FQDN by using the FQDN of the top-level, master load balancer server.Configure the VMware Identity Manager FQDN

    Important: You need a minimum of three VMware Identity Manager appliances in a cluster. We use a local load balancer virtual server for our pool of VMware Identity Managers in Site 1 (s1-idm). We use another local load balancer virtual server for our pool of VMware Identity Managers in Site 2 (s2-idm). We then use a global, master load balancer virtual server named identity, which is in place above s1-idm and s2-idm.

    For more information about configuring the FQDN, see the topic Modifying the VMware Identity Manager Service URL in the on-premises version of Installing and Configuring VMware Identity Manager. As part of this procedure, after you change the FQDN to that of the global load balancer, you will enable the new portal UI.

  8. Copy the root certificate of the VMware Identity Manager appliance to the local load balancer, as described in Apply VMware Identity Manager Root Certificate to the Load Balancer, in Installing and Configuring VMware Identity Manager.

Configure Failover and Redundancy for VMware Identity Manager

You use the VMware Identity Manager appliance you just created to create additional appliances in both Site 1 and Site 2. After giving each appliance its own IP address and DNS name, you configure the built-in Elasticsearch and Ehcache clusters.

  1. Clone the VMware Identity Manager appliance twice, to create two clones of the VMware Identity Manager appliance in Site 1, as described in Clone the Virtual Appliance, in Installing and Configuring VMware Identity Manager.
    For our example, the original VMware Identity Manager appliance is named s1-idm1. The two clones for Site 1 are named s1-idm2 and s1-idm3.
  2. Give the cloned appliances static IP addresses and verify that an Elasticsearch cluster is created, as described in Assign a New IP Address to Cloned Virtual Appliance, in Installing and Configuring VMware Identity Manager.
  3. Configure Elasticsearch and Ehcache for replication, as described in Modify the Primary Data Center for Replication, in Installing and Configuring VMware Identity Manager.
  4. Export the VMware Identity Manager appliance and use it to create a new cluster of three appliances in Site 2, as described in Create VMware Identity Manager Virtual Appliances in Secondary Data Center, in Installing and Configuring VMware Identity Manager.
  5. Update the IP tables in Site 2, as described in Configure Nodes in Secondary Data Center, in Installing and Configuring VMware Identity Manager.

Deploy and Set Up the VMware Identity Manager Connectors Inside the Corporate Network

After you set up the VMware Identity Manager instances inside the DMZ, you deploy four VMware Identity Manager Connectors inside the corporate network—two connectors in Site 1 and two connectors in Site 2. The connectors use a built-in identity provider rather than a load balancer. The connectors sync users and groups from your enterprise directory to the VMware Identity Manager Service.

  1. In preparation for establishing a connection to VMware Identity Manager Connectors, navigate to the global load balancer URL (https://<global-LB-URL>/admin), log in to the VMware Identity Manager administrative console, and generate an activation code for the two connectors you will create, using the connector names s1-idmconn1 and s1-idmconn2.
    Prepare to connect to VMware Identity Manager Connectors

    For instructions on generating the activation code, see the topic Generate Activation Code for Connector in VMware Enterprise Systems Connector Installation and Configuration.
  2. Deploy two VMware Identity Manager Connectors in Site
    • When you complete the Deployment wizard for each connector, you will enter the connector name you used in Step 1.
    • When you complete the Setup wizard for each connector, you will enter the activation code you generated in Step 1.
      The Identity Manager Connectors run inside your trusted enterprise network. For instructions, see the topic Enterprise Systems Connector Installation Process in VMware Enterprise Systems Connector Installation and Configuration.
      Important: For this reference architecture, we used the Linux-based virtual appliance to deploy the connector. You can alternatively use the Enterprise Systems Connector to install the Windows-based version of the connector.
      activate connector
  3. (Optional) To replace the SSL certificate for the VMware Identity Manager Connector, go to this URL: https://<FQDN>:8443/cfg/ssl.
  4. In Site 1, use the VMware Identity Manager administration console (at the global load balancer URL) to add a directory.
    • Click the link on the Setup is Complete page, which is displayed after you activate the connector.
    • On the Identity & Access Management > Directories tab, click Add Directory and select the type of directory you want to add.
    • Follow the wizard prompts, and add the first connector (s1-idmconn1) as your Sync Connector.
      Adding a directory allows VMware Identity Manager to sync users and groups from your enterprise directory to the VMware Identity Manager Service. For more information, see the topic Integrating with Your Enterprise Directory in Installing and Configuring VMware Identity Manager.
      Add directory in VMware Identity Manager administration console
      Note: After you complete all the steps in this procedure, you will have four connectors—two in Site 1 and two in Site 2—and the sync connector will be the s1-idmconn1 connector in Site 1. If the s1-idmconn1 connector ever becomes unavailable, you will need to select a different connector as the sync connector. If Site 1 has a failure event, you will need to select a connector in Site 2. For more information, see the topic Enabling Directory Sync on Another Connector in the Event of a Failure in Deploying VMware Identity Manager in the DMZ.
  5. Enable the connectors to operate in outbound-only connection mode.
  6. In Site 2, just as you did for Site 1, navigate to the global load balancer URL (https://<global-LB-URL>/admin), log in to the VMware Identity Manager administrative console, and generate an activation code for the two connectors you will create in Site 2, using the connector names s2-idmconn1 and s2-idmconn2.
    Important: You must use the VMware Identity Manager administration console at the global load balancer URL to generate this activation code. Otherwise, communication cannot be established between the connector and the service that end users need to use.
  7. Deploy two VMware Identity Manager Connectors in Site 2.
    • When you complete the Deployment wizard for each connector, you will enter the connector name you used in Step 6.
    • When you complete the Setup wizard for each connector, you will enter the activation code you generated in Step 6.
  8. (Optional) To replace the SSL certificate for the VMware Identity Manager Connector, go to this URL: https://<FQDN>:8443/cfg/ssl.
  9. In Site 2, use the VMware Identity Manager administration console to add a directory.
    • Click the link on the Setup is Complete page, which is displayed after you activate the connector.
    • On the Identity & Access Management > Directories tab, click Add Directory and select the type of directory you want to add.
    • Follow the wizard prompts, and add the s1-idmconn1 connector as your Sync Connector.
  10. In Site 2, add the s2-idmconn1 and s2-idmconn2 connectors to the built-in identity provider that you created previously.
    You now have four connectors, with the s1-idmconn1 connector used for synching users and groups.
    Four VMware Identity Manager Connectors
    At this point, we have
    • 3 VMware Identity Manager appliances for Site 1: s1-idm1, s1-idm2, s1-idm3
    • 1 load balancer virtual server for site 1: s1-idm
    • 2 VMware Identity Manager Connectors for Site 1: s1-idmconn1, s1-idmconn2
    • 3 VMware Identity Manager appliances for Site 2: s2-idm1, s2-idm2, s2-idm3
    • 1 load balancer virtual server for site 2: s2-idm
    • 2 VMware Identity Manager Connectors for Site 2: s2-idmconn1, s2-idmconn2
    • 1 master load balancer virtual server: identity

Finalizing Failover Preparation

To complete the setup, follow the instructions provided in the following topics from Installing and Configuring VMware Identity Manager:

  • Configure Failover Order of Horizon View and Citrix-based Resources
  • Clear Cache in Secondary Data Center

Appendix G: VMware AirWatch Configuration for Multi-site Deployments

Use the procedures in this appendix to create SQL Server clustered instances that can fail over between sites and to set up a highly available database for VMware AirWatch. The following diagram shows the architecture.

VMware AirWatch Architecture

Figure 141: VMware AirWatch Architecture 

The tasks you need to complete are grouped into the following procedures:

  1. Create a Windows Server Failover Cluster and Configure Shared Storage
  2. Install the SQL Server Failover Cluster
  3. Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance
  4. Create the Airwatch Database.
  5. Create the AitWatch SQL Service Account and Assign Database Owner Roles
  6. Sync the AirWatch Database Account Across SQL Server Availability Group Replicas
  7. Create an Always On Availability Group for the AirWatch Database
  8. Set Advance Always On Availability Group Listener Parameters for Multi-site or Multi-subnet Failover

For steps 1, 2, and 3, which involve creating a Windows Server Failover Cluster using Microsoft SQL Server, follow the procedures detailed in Appendix F: VMware Identity Manager Configuration for Multi-site Deployments

Create the AirWatch Database

After you finish creating the Windows Server Failover Cluster, you are ready to create the database and configure an Always On availability group for AirWatch.

  1. Open SQL Server Management Studio and connect to your SQL Server database instance in Site 1
  2. Log in as the sysadmin or as a user account with sysadmin privileges.
  3. Click Connect.
  4. Right-click Databases and select New Database.
  5. Enter AirwatchDB as the database name.
  6. Scroll to the right side of Database files table, select the ellipses () in the Autogrowth column, and in the dialog box, change File Growth to In Megabytes, set the size to 128, and select OK.
    Change Autogrowth for Airwatch DB
  7. Select Options in the left pane, set Collation to SQL_Latin1_General_CS_AS, set Compatibility level to SQL Server 2008, and let other options use the defaults.
    Configure Option for AirWatch
  8. Select OK to create the database.
  9. Expand Databases and verify that the database is created.

Create the AirWatch SQL Service Account and Assign Database Owner Roles

After you create the AirWatch database, you must configure the SQL service account that will be used to connect to the AirWatch database.

  1. Open SQL Server Management Studio.
  2. Log in to the database server that contains the AirWatch database.
  3. Navigate to Security > Login, right-click, and select New Login and give the account a login name.
  4. Select whether to use your Windows account or the local SQL Server account for authentication.
    For SQL Server authentication, enter the password to be used.
  5. Select AirWatchDB as the Default database.
    Create AirWatchDB
  6. Navigate to the Server Roles page and select public as the server role.
    Public Server Role
  7. Navigate to the User Mapping page and make the following selections:
    • In the Users mapped to this login list, select AirwatchDB, and in the Database role membership list, select the db_owner role.
      Important: The db_owner role must be selected for the SQL Server user account that you plan to use for running the AirWatch database script.
    • In the Users mapped to this login list, select the msdb database, and in the Database role membership list, select the SQLAgentUserRole and db_datareader roles.
      Settings in User Mapping page

Sync the AirWatch Database Account Across SQL Server Availability Group Replicas

SQL Server Always On availability groups provide disaster recovery for the AirWatch database. Availability groups synchronize only the AirWatch database and not the entire server setup across both SQL Server cluster nodes.

It is important for us to have consistent SQL Server configurations across both Always On availability group nodes because we want the AirWatch database login to be able to connect to the database after failover.

Consistency across the SQL Server cluster nodes can be ensured through scripts, stored procedures, or manual commands. In this example, the focus is on ensuring account synchronization only.

In this reference architecture, we leveraged Copy-DbaLogin and Sync-DbaSqlLoginPermission commands to ensure consistency across both SQL Server instances. These are a part of the dbatools PowerShell module available on GitHub.

  1. Install dbatools:
    • Open PowerShell and enter the Install-Module dbatools command.
    • Click Yes on the next prompt.
      Install-Module dbatools in Powershell
    • Click Yes to All on the next prompt.
      Install-Module dbatools
      The dbatools module is now installed.
      Install-Module dbatools installed
  2. Use the Copy-DbaLogin PowerShell command to sync the SQL AirWatchDB account across both Always On instances.
    Syntax: Copy-DbaLogin -source <SQL_server> -Destination <SQL_server>
    Where source is the SQL Server instance where the AirWatch SQL Server account was created, and destination is the additional SQL Server Always On replica server we plan to use in the Always On availability group.
    sync the SQL AirWatchDB
  3. Use the Sync-DbaSqlLoginPermission PowerShell command to sync account permissions across Always On instances.
    Syntax: sync-DbaSqlLoginPermission -source <SQL_server> -Destination <SQL_server>
    Where source is the SQL Server instance where the AirWatch SQL Server account was created, and destination is the additional SQL Server Always On replica server we plan to use in the Always On availability group.
    sync account permissions
  4. Verify that the SQL Server account for the AirWatchDB database account is present in both SQL Server instances.
    Verify the AirWatchDB database account

Create an Always On Availability Group for the AirWatch Database

  1. Open SQL Server Management Studio and connect to the server where the AirWatchDB database was created.
  2. Navigate to Always On High Availability, right-click, and select New Availability Group Wizard.
    New availability group in SQL Server Management Studio
  3. Give the availability group for the AirWatchDB database a name; for example, AirwatchDB-AG.
    Name the availability group for the AirWatchDB database
  4. Select the AirWatchDB database for the availability group.
    If you have not already done so, you will need to make a full backup of the database before you can proceed.
    Select the AirWatchDB database for the availability group
  5. Click Add Replica and enter the credentials of the additional SQL Server instance to join the availability group.
    Join the availability group
    The additional SQL Server instance availability replica will appear in the list. Leave it at default settings.
  6. On the Listener tab select Create an availability group listener, enter the Listener DNS Name and Port, and click Add, to add the listener IP addresses.
    Note: There are two subnets, one from each of site. Enter one unused IP address from each subnet. SQL Server will create the DNS record for the availability group listener.
    Create an availability group listener
  7. On the Select Initial Data Synchronization page, select Automatic Seeding.
    Automatic seeding requires data and log file paths to be consistent across both availability replica SQL Server instances. If your configuration uses different data and log file paths, choose another data synchronization method.
    Select Initial Data Synchronization page
  8. After Validation has completed successfully, click Next.
    Validation
  9. Click Finish on the Summary page to create the availability group.
    Summary
  10. Click Close on the Results page.
    Results page
  11. Expand the Availability Group in SQL Server Management Studio and verify settings.
    Verify settings in SQL Server Management Studio

Set Advanced Always On Availability Group Listener Parameters for Multi-site or Multi-subnet Failover

  1. Open a PowerShell prompt and use the following PowerShell commands to configure advanced listener parameters.
  2. Use the Get-ClusterResource and Get-ClusterParameter cmdlets to determine the name of the resource (airwatchdb-ag_airwatchdb-agl) and its settings, as shown in the following example.
    configure advanced listener parameters
    Configure advanced listener parameters
  3. Change the HostRecordTTL to a lower value than the default using the following command: Set-ClusterParameter HostRecordTTL 120
    A generally recommended value is 120 seconds, or 2 minutes, rather than the default of 20 minutes. Changing this setting reduces the amount of time to connect to the correct IP address after a failover for legacy clients that cannot use the MultiSubnetFailover parameter.
  4. Use the following command to change RegisterAllProvidersIP to false in multi-site deployments:

    Set-ClusterParameter RegisterAllProvidersIP 0

    With this setting, the active IP address is registered in the Client Access Point in the WSFC cluster, reducing latency for legacy clients.

    For instructions on how to configure these settings, see RegisterAllProvidersIP Setting and HostRecordTTL Setting. For sample scripts to configure the recommended settings, see Sample PowerShell Script to Disable RegisterAllProvidersIP and Reduce TTL.
    change RegisterAllProvidersIP in multi-site deployments

  5. Stop and restart the airwatchdb-ag_airwatchdb-agl resource so that the new settings can take effect.
    1. stop-clusterresource
    2. start-clusterresource
      Restart the resource

Now that the database is set up and the SQL Server Always On availability group is configured, you can deploy and configure VMware AirWatch components to point to the Always On availability group for the database.

Appendix H: Active/Passive Service Using VMware vSAN Stretched Cluster

One infrastructure option for providing site resilience is to use a stretched cluster that extends a vSAN cluster across the two data sites.

This architecture is achievable with data centers that are near each other, such as in a metro or campus network environment with low network latency between sites. A stretched cluster provides both the data replication required and the high-availability capabilities to recover the server components, desktops, and RDSH servers.

This use case uses full-clone desktop VMs to address existing Horizon 7 implementations that use full-clone persistent desktops and cannot easily transition to a nonpersistent use case for various business reasons.

Recovery Service Definition for a vSAN Stretched Cluster Active/Passive Service

Requirement: The VMs used for VDI or RDSH run from a specific data center but can be failed over to a second data center in the event of an outage.

Overview: This service builds on the replication capability of vSAN and the high-availability (HA) features of vSphere HA when used in a stretched cluster configuration between two data centers. The required Horizon 7 server components are pinned to the vSphere hosts in one of the data centers using VM DRS groups, host DRS groups, and VM-Host affinity rules on the vSAN stretched cluster. vSphere HA fails them over to the second data center in the event of an outage.

Although the Windows component of the user service could be composed of full clones, linked clones, instant clones, or RDSH-published applications, this reference architecture shows full-clone desktop VMs. This addresses existing Horizon 7 implementations that use full-clone persistent desktops. Use cases involving floating desktop pools or RDSH-published applications are better served by adopting the active/active or active/passive use cases previously outlined. These use separate Horizon 7 pods per site with Cloud Pod Architecture for global entitlements.

Horizon 7 services accommodated: Legacy Full Clones, Developer Workspace Service. The overall RTO (recovery time objective) is between 15 and 30 minutes with an RPO (recovery point objective) of 15 to 30 minutes.

Requirement

Comments

Full-clone Windows desktop VMs

Persistent use case with 1:1 mapping of a VM to a user.

VMs are replicated with a vSAN stretched cluster.

• RTO = 15–30 minutes 

• RPO = 15–30 minutes 

Native applications 

  • Applications are installed natively in a base Windows OS.
  • Applications are replicated as part of the full-clone replication process above.

IT settings (optional) 

User Environment Manager IT configuration is replicated to another data center.

• RTO = 30–60 seconds 

• RPO = 30–60 seconds 

User data and configuration (optional) 

User Environment Manager user data is replicated to another data center.

• RTO = 30–60 seconds 

• RPO = Approximately 2 hours 

Table 136: Active/Passive Service Requirements for a vSAN Stretched Cluster

vSAN Stretched Cluster Blueprint for the Active/Passive Service 

This service uses stretched cluster storage to replicate both desktops and infrastructure components from one data center to the other. Only one data center is considered active, and in the event of a site outage, all components would be failed over to the other site as a combined unit.

Blueprint for the vSAN Stretched Cluster Active/Passive Service 

Figure 142: Blueprint for the vSAN Stretched Cluster Active/Passive Service 

Architectural Approach for the Stretched Cluster Active/Passive Service

This architecture relies on a single Horizon 7 pod with all required services always running at a specific site and never stretched between geographical locations. Only desktop workloads can run actively in both sites. The Connection Servers and other server components can fail over to Site 2 as a whole unit in the event of an outage of Site 1. This architecture relies on vSAN stretched cluster technology.

Stretched Cluster Active/Passive Architecture

Figure 143: Stretched Cluster Active/Passive Architecture

vSphere Infrastructure Design Using vSAN

The stretched cluster active/passive service uses Horizon 7 hosted on a vSphere 6 environment with a vSAN stretched cluster and storage between the two sites.

In the validation of this design, a vSAN storage environment was deployed as a vSAN stretched cluster to provide high availability and business continuity for the virtual desktops in a metro cluster deployment. The vSAN stretched cluster also achieves the high availability and business continuity required for the management server VMs.

To protect against a single-site failure in a metro or campus network environment with low network latency between sites, a stretched cluster can synchronously replicate data between the two sites, with a short RTO time and no loss of data.

vSAN does support active/active data sites with desktops and RDSH VMs active in both sites. Although these virtual desktops and Horizon 7–published applications can operate in active/active mode, the supporting management machines, and especially the Connection Servers, must all run within the one data center at a given time. To achieve this, the management servers should all be pinned to the same site at all times. Horizon 7 management services are deployed in an active/passive mode on a vSAN stretched cluster, failing over to the secondary site in the event of a site failure.

vSAN Configuration 

A vSAN stretched cluster is organized into three fault domains, referred to as preferred, secondary, and witness. Each fault domain denotes a separate, geographically dispersed site.

  • Preferred and secondary fault domains are data sites that contain an equal number of ESXi servers, with VMs deployed on them.
  • The witness fault domain contains a single physical ESXi server or an ESXi virtual appliance whose purpose is to host the witness component of VM objects. When there is a failure or split-brain occurrence, the witness appliance contributes toward the object quorum so the VM can remain available.

vSAN Stretched Cluster Configuration

Figure 144: vSAN Stretched Cluster Configuration 

 

The vSAN stretched cluster for Horizon 7 management VMs has a physical ESXi server located in the preferred fault domain (in our case Fault Domain A), an ESXi server in the secondary fault domain (in our case, B), and a dedicated witness virtual appliance running on an ESXi host located in the witness fault domain (C).

The six-node vSAN stretched cluster for Horizon 7 virtual desktops has three physical ESXi hosts located in the preferred fault domain, three physical ESXi hosts in the secondary fault domain, and a single witness virtual appliance located in the witness fault domain.

vSAN Network Requirements 

Connectivity between vSAN data sites and the witness site must obey strict requirements. Both layer-2 (L2, same subnet) and layer-3 (L3, routed) configurations are used in a vSAN stretched cluster deployment.

VMware recommends that vSAN communication between the data sites be over stretched L2, and vSAN communication between data sites and the witness site be routed over L3.

vSAN traffic between data sites is multicast, whereas traffic between a data site and witness site is unicast.

Networking for a vSAN Stretched Cluster

Figure 145: Networking for a vSAN Stretched Cluster

 

A critical requirement for a vSAN stretched cluster is the amount of latency between sites. Latency between data sites should 

  • Not exceed 5 ms RTT (round -trip time) 
  • Be less than 2.5 ms each way

For a two-node vSAN stretched cluster configuration, latency between a data site and witness site can be a maximum of 500 ms RTT (250 ms each way).

It is recommended to have a minimum of 10-Gbps network bandwidth between sites.

Horizon 7 Pod and Blocks in a vSAN Stretched Cluster

In the validation of this design, a single vSAN stretched cluster is used for both the management block and the desktop block.

One vCenter Server was deployed for the management servers and the desktop resources.

Horizon 7 Blocks on vSAN Stretched Cluster

Figure 146: Horizon 7 Blocks on vSAN Stretched Cluster

 

Virtual Networking on vSAN

A single vSphere distributed switch was created with two 10-Gb interfaces in a team.

Four port groups isolate network traffic: 

  • Virtual machines 
  • ESXi management network 
  • vSphere vMotion 
  • vSAN traffic 

Quality of Service is enforced with network I/O Control (NIOC) on the distributed virtual switch, guaranteeing a share of bandwidth for each type of traffic.

A vmkernel interface (vmknic) is created on the ESXi management port group, vSphere vMotion port group, and vSAN port group.

vSphere Networking

Figure 147: vSphere Networking

Prerequisites and Settings for a vSAN Stretched Cluster Active/Passive Service 

This section provides specifications for designing the infrastructure of the active/passive service using a vSAN stretched cluster, including settings for vSAN, vSphere, distributed switches, and storage.

The following table details the vSAN prerequisites. 

Requirements

Configuration Considerations

Three dispersed sites 

  • Two data sites, each with an equal number of ESXi hosts 
  • One witness site with a dedicated ESXi physical server or virtual appliance, per vSAN stretched cluster 

Network requirements 

Data site to data site:

  • < 5 ms latency round-trip time over 10 Gbps 
  • Layer-2 or Layer-3 network 
  • Connectivity with multicast 

Witness site to data site:

  • 200 ms latency over 100 mbps (500 ms permitted for two-node cluster) 
  • Layer-3 network 
  • Connectivity without multicast 

Table 137: vSAN Prerequisites

The vSphere HA settings are summarized in the following table. 

Name of Setting 

Setting to Use

vSphere HA 

Turn on vSphere HA 

Host Monitoring 

Enabled 

Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss” 

Disabled (default) 

Virtual Machine Monitoring 

Disabled (default) 

Admission Control 

Set to 50% 

Host Isolation Response 

Power off and restart VMs 

Datastore Heartbeats 

Select Use datastores only from the specified list – Do not select any of the datastores.

Table 138: vSphere High Availability Settings

Settings for vSphere Distributed Resource Scheduler are summarized in the following table.

Name of Setting 

Setting to Use

vSphere DRS 

Turn on vSphere DRS 

DRS Automation 

Partially Automated 

Power Management 

Off 

VMHost Groups 

For Management block only:

 

Add new VMHost Groups 

• Name: Preferred-Site-Hosts 

- Add ESXi hosts from Site 1 

• Name: Secondary-Site-Hosts 

- Add ESXi hosts from Site 2 

 

Add new VM Group 

• Name: Management-VM-Group 

- Add vSphere and Horizon 7 management VMs 

VMHost Rules 

Add new VMHost Rule 

• Name: ManagementVMs-to-Preferred-Site 

• Type: Virtual Machines to Hosts 

• VM Group: Management-VM-Group 

 

For Must run on hosts in group: 

• Host Group: Preferred-Site-Hosts 

vSphere HA Rule Settings 

VM to Host affinity rules: vSphere HA should respect rules during failover.

Table 139: vSphere Distributed Resource Scheduler Settings

The following table shows the distributed switch and port group policies. 

Property

Setting 

Default 

Revised 

General 

Port Binding 

Static 

– 

Policies: Security 

Promiscuous mode 

Reject 

– 

MAC address changes 

Accept 

Reject 

Forged transmits 

Accept 

Reject 

Policies: Traffic Shaping 

Status 

Disabled 

– 

Policies: Teaming and Failover 

Load balancing 

Route based on the originating virtual port ID 

Route based on physical NIC load 

Failover detection 

Caution Link Status only 

– 

Notify switches 

Yes 

– 

Policies: Resource Allocation 

Network I/O Control 

Disabled 

Enabled 

Advanced 

Maximum MTU 

1500 

9000 

Table 140: Distributed Switch Settings

 

Details for storage used in this reference architecture for validation are listed in the following table. 

Function 

Device Backing

File System

Storage Policy

ESXi local install 

1 x 16-GB SD card 

VMFS v6 

vSAN 

  • 1 x Disk Group per ESXi 
  • Caching: 1 x Intel S3700 DC 400 GB SSD 
  • Capacity: 5 x Intel S3700 DC 400 GB SSD 

Disk Format v5 

Default 

Table 141: Storage

Steps for Building vSAN Stretched Cluster Recovery Services

This section covers the high-level steps required to build out the active/passive service (using a vSAN stretched cluster), which can be seen from a blueprint perspective in the following figure.

Blueprint for a Stretched Cluster Active/Passive Service 

Figure 148: Blueprint for a Stretched Cluster Active/Passive Service 

 

The following table outlines the steps required for creating a vSAN stretched cluster.

Step 

Details

Prerequisites 

Ensure the vSAN prerequisites in Prerequisites and Settings for a vSAN Stretched Cluster Active/Passive Service are met.

Witnesses 

  • Deploy a vSAN witness appliance on a vSphere HA/DRS cluster in Witness Site 3. 
  • Add the vSAN witness appliance to vCenter Server as a standalone ESXi host.

vSphere clusters 

  • Create the required vSphere stretched cluster by adding the ESXi hosts from Site 1 and Site 2.
  • Enable vSAN for the cluster.
  • Configure the fault domains and select the relevant witness hosts created earlier.

DRS and HA 

Configure DRS and HA settings as per Prerequisites and Settings for a vSAN Stretched Cluster Active/Passive Service.

Affinity 

To pin the management servers as a unit to a particular site, you must create VMHost groups and VMHost rules.

See Prerequisites and Settings for a vSAN Stretched Cluster Active/Passive Service.

Complete 

  • Configure Horizon 7 servers and the VM template for the virtual desktops.
  • Provision Horizon 7 full-clone desktops.

Table 142: Steps for Configuring a vSAN Stretched Cluster Active/Passive Service

The following table outlines the steps for creating the virtual desktops and published applications to be provided by a vSAN stretched cluster.

Step 

Details 

Load balancing 

Verify both global and local load balancing are functional.

Master VM 

Build out a master VM image in Site 1 to meet requirements.

Create desktop pool 

Create a desktop pool based on the master VM image. 

Entitlements 

Entitle the users to the desktop pool as required.

Table 143: Steps for Creating the Windows Component of a vSAN Stretched Cluster Active/Passive Service

Note: With regards to the environmental infrastructure design, including Active Directory, distributed file systems, load balancing, and DHCP, you can use the same design as is used for the multi-site active/active and active/passive use cases, as described in vSphere and Environment Infrastructure Design.

Reference Architecture Validation for vSAN Stretched Cluster Active/Passive Service 

This section details the impact to both users and services during failure and the behavior after failover for all the services.

Type of Access

During Failure

After Failover

Logged-in user 

Some sessions are terminated (depends on the location where the desktop is running).

N/A 

New user logging in 

User cannot log in.

After management services have resumed, users can log in as normal.

Access to user data 

If the desktop is not disconnected, a full-clone user has access to data.

User has access to data.

Table 144: vSAN Stretched Cluster Active/Passive Service Failure Impact

Test/Recovery Plan for Active/Passive Horizon 7 Service Failover on vSAN Stretched Cluster

For this test, a whole site failure was simulated for one of the data sites in a vSAN stretched cluster configuration consisting of Horizon 7 management server VMs and virtual desktops running on a vSAN stretched cluster.

Users were logged in to full-clone virtual desktops when the failure occurred.

Horizon 7 Service Failover Plan on vSAN Stretched Cluster

Figure 149: Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster

 

The following table lists the preliminary tests and checks to be performed. 

Test 

Name 

Description 

Expectation 

Outcome 

0.1 

Identify candidate site for simulated failure 

Select the site where all management VMs are running.

Management machines are pinned to the data site using DRS affinity rules.

Site 1 selected

0.2 

Verify virtual desktops are ready for test 

Check full-clone pool deployed across desktop vSAN stretched cluster.

Full-clone virtual desktops are available for login across both sites.

As expected 

0.3 

Verify vSAN fault domain, HA, and DRS settings 

Verify that vSAN is operating effectively, with no errors.

Also, verify that vSphere HA and DRS are enabled and configured correctly to support vSAN site failover.

vSAN reports no issues with configuration. vSphere HA and DRS settings are optimal.

As expected 

0.4 

Users log in to virtual desktops 

Log in test users to full-clone virtual desktops; one in each of Site 1 and Site 2.

Users are logged in to full-clone virtual desktops in Site 1 and Site 2.

As expected 

0.5 

Prepare to record the time period of the failover 

Prepare a timer device to record the time it takes for failover of services from Site 1 to Site 2.

Time source starts recording time when failover occurs.

As expected 

Table 145: Active/Passive on vSAN Stretched Cluster Preliminary Tests

The following list of tests includes descriptions of occurrences during a vSAN stretched cluster active/passive service failover, the recovery steps required, and the test results.

Test

Name 

Description

Expectation 

Outcome 

1.0 

Site failure simulation initiated 

Power is killed to all ESXi servers in Site 1: one server for management VMs, three servers for hosting desktops.

The ESXi server that hosts the management VMs goes offline. Full-clone virtual desktops in Site 1 are unavailable. Virtual desktop sessions to full-clone desktops in Site 1 are disconnected. Virtual desktop sessions to full-clone desktops in Site 2 are unaffected.

As expected 

2.0 

vSphere HA fails the management VMs over to Site 2 

vSphere HA starts up management VMs (vCenter Server, AD domain controller, SQL Server, Connection Servers, Composer, VMware vRealize Operations for Horizon) in Site 2.

vSphere HA restarts the management VMs within 30 seconds.

vSphere HA restarts management VMs within 25 seconds.

Management VMs show vSAN storage policy non-compliance. 

2.1 

vSphere HA fails over full-clone desktops to Site 2 

vSphere HA starts up all full-clone desktops that had been running in Site 1 before failure occurred.

vSphere HA restarts virtual desktops.

vSphere HA powers on all virtual desktops in 2 minutes.

Desktop VMs show vSAN storage policy non-compliance. 

Table 146: Active/Passive on vSAN Stretched Cluster Test Results

About the Authors and Contributors

Graeme Gordon is a Senior Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware.

Caroline Arakelian is a Senior Technical Marketing Manager in End-User-Computing Technical Marketing, VMware.

Camilo Lotero is a Senior Technical Marketing Manager in End-User-Computing Technical Marketing, VMware.

Donal Geary is a Reference Architect Engineer in End-User-Computing Technical Marketing, VMware.

Frank Anderson is a Solutions Architect in End-User-Computing Technical Marketing, VMware.

Hilko Lantinga is an End-User-Computing Architect in End-User-Computing Technical Marketing, VMware.

Justin Sheets is a Senior Technical Marketing Manager in End-User-Computing Technical Marketing, VMware.

Geoff Wilmington is a Senior Technical Product Manager with the Networking and Security Business Unit, VMware.

The following people contributed content to previous papers whose content has been subsumed into this paper:

  • Rasmus Jensen, Lead Systems Engineer, VMware
  • Jim Yanik, Senior Manager, End-User-Computing Technical Marketing, VMware
  • Chris Halstead, Staff Engineer in End-User-Computing Technical Marketing, VMware
  • Kevin Sheehan, End-User-Computing Senior Product Manager, VMware
  • Shardul Navare, Senior Technical Marketing Architect in End-User-Computing Technical Marketing, VMware
  • Roger Deane, Senior Solution Architect Manager in End-User-Computing Technical Marketing, VMware
  • Adarsh Kesari, Staff Solutions Architect, VMware
  • Stéphane Asselin, Lead Product Architect in End-User Computing, VMware
  • Matt Coppinger, Director of Technical Marketing and Enablement in End-User-Computing Technical Marketing, VMware
  • Alex Birch, formerly of VMware

To comment on this paper, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.