Vmware Horizon 7 Enterprise Edition Reference Architecture Multi Site

TECHNICAL WHITE PAPER – NOVEMBER 2017
VMWARE HORIZON 7
ENTERPRISE EDITION
MULTI-SITE REFERENCE
ARCHITECTURE
VMware Horizon 7 Version 7.2 and Later
VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
JMP – Next-Generation Desktop and Application Delivery Platform . . . . . . . . . . . . . . . . . . . . . . . . . 8
VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Business Drivers and Use Cases Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Meeting Business Requirements with Multi-Site Horizon 7 Deployments . . . . . . . . . . . . . . . . . . . . 10
Use Case Recovery Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Recovery Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Multi-Site Architecture Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Horizon 7 Pod and Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Architectural Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
General Multi-Site Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Horizon 7 Component Design with a Disaster Recovery Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

VMware Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Horizon 7 with Cloud Pod Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Unified Access Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
App Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
User Environment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
vSphere Infrastructure Design for Active/Active and Active/Passive Services . . . . . . . . . . . . . . . . . . 44

View Pod and Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Storage Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Environment Infrastructure Dependencies Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Distributed File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Global Load Balancing and Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Microsoft RDS Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Microsoft KMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
T E C H N I C A L W H I T E PA P E R | 2
Horizon 7 Components Required for Recovery Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Reference Architecture Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
vSAN Stretched Cluster Active/Passive Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Recovery Service Definition for Stretched vSAN Active/Passive Service . . . . . . . . . . . . . . . . . . . 65
Architectural Approach for the Stretched Active/Passive Service. . . . . . . . . . . . . . . . . . . . . . . . . . 66
vSphere Infrastructure Design Using vSAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Horizon 7 Components Required for vSAN Stretched Cluster Recovery Services. . . . . . . . . . . . . 71
Reference Architecture Validation for vSAN Stretched Cluster Active/Passive Service . . . . . . 72
Appendix A: Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Appendix B: Active/Active and Active/Passive Services with Replicating

Storage Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix C: Infrastructure Design for the Stretched vSAN Active/Passive Service . . . . . . . . . . . . . 76
Appendix D: Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Active/Active Horizon 7 Service Failover Test/Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Active/Passive Horizon 7 Service Failover Test/Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster . . 86
Appendix E: F5 Load-Balancing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements. . . . . . . . . . 90
Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple Sites. . . . . . . . . 91
Create a Windows Server Failover Cluster and Configure Shared Storage. . . . . . . . . . . . . . . . . . . 92
Install the SQL Server Failover Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance. . . . . . . . . 95
Create the VMware Identity Manager Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Create and Configure the SQL Server Always On Availability Group for
VMware Identity Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Deploy and Set Up VMware Identity Manager Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configure Failover and Redundancy for VMware Identity Manager . . . . . . . . . . . . . . . . . . . . . . . 109
Deploy and Set Up the VMware Identity Manager Connectors
Inside the Corporate Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Finalizing Failover Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Appendix H: Setting Up VMware App Volumes for High Availability in Multiple Sites. . . . . . . . . . . 114
Create a Windows Server Failover Cluster in Each Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Install SQL Server 2014 Stand-Alone in All VMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Create the App Volumes Databases and Enable Availability Groups for the Clusters. . . . . . . . . 120
Create Always On Availability Groups for App Volumes Databases. . . . . . . . . . . . . . . . . . . . . . . . . 122
Configure Cluster Quorum Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Install App Volumes to Use a Highly Available Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Appendix I: Configuration Procedures for a Clustered App Volumes Database . . . . . . . . . . . . . . . . . 131

Create the App Volumes Clustered Database Using Backup and Restore. . . . . . . . . . . . . . . . . . . 132
Install and Configure App Volumes Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Executive Summary
Building and implementing a VMware Horizon® 7 Enterprise Edition environment to deliver services from
multiple sites can be done for a variety of reasons such as geographical usage, scale, or to provide
business continuity. This reference architecture designs and validates the most typical configuration and
requirements for a two-data-center strategy.
One initial aim that organizations have is to provide disaster recovery with the lowest possible Recovery
Time Objective (RTO) and Recovery Point Objective (RPO) in case of a site failure while providing a
consistent end-user experience. Ultimately, organizations want to keep the business operating during an
extended or catastrophic technology outage, providing continuity of service and allowing staff to carry
out their day-to-day responsibilities. With services, applications, and data delivered by Horizon 7, that
means providing continuity of service and mitigating against component failure, all the way up to a
complete data center outage.
This reference architecture details and shows validation of a Horizon 7 Enterprise Edition solution that
delivers business continuity and disaster recovery to a set of identified use cases. The services designed
and delivered to users focus on availability and recoverability, but can be easily adapted to general
multi-site requirements.
Service Desktop Pool/ Apps Profile

RDSH Farm
Desktop / RDSH Clone
Home
Instant or Writable IT User File
Site 1
User Apps Linked Clone AppStacks Volume Config Settings Shares
Attached Apps Active
Windows OS Master VM
User
Standby Service
Replication
Client(s) Desktop / RDSH Clone
Site 2
User Apps Active
Attached Apps
Failover
Windows OS
Desktop Pool/
RDSH Farm Apps Profile
Figure 1: Example Service Blueprint
To build the environment necessary to deliver highly available services to users, each product and
component in Horizon 7 Enterprise Edition is architected and designed specifically to meet these
requirements. This includes virtual desktops and published applications (RDSH), applications delivered
through VMware App Volumes™ AppStacks and writable volumes, profile data with VMware User
Environment Manager™, secure external access through VMware Unified Access Gateway™ (formerly
called Access Point), and a single-sign-on workspace with VMware Identity Manager™. The availability of
each part is considered, as is the replication and recovery of any data portion required to ensure the
service is available at the second site.
Note: In Table 1:
• A low RTO means that the service is recovered within a brief period, such as 30 to 60 seconds. A
medium RTO target might be 45 to 60 minutes. These time periods can vary dramatically, depending
on the components included in the recovery service.
• A low RPO means a brief time period during which data might be lost, such as 30 to 60 seconds. A
medium RPO target might be 45 to 60 minutes. These time periods can vary dramatically, depending
on the components included in the recovery service.
• 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.
USE CASE AND DESCRIPTION SOLUTION

OBJECTIVES
Active/Active • User requires the lowest possible recovery time for service Horizon 7 Enterprise Edition
RTO = Low (for example, health worker). using Cloud Pod
• Mobile user might roam from continent to continent. Architecture (CPA) and
RPO = Low
storage area network
• User needs to get served from nearest geographical data capable of multi-site
center per continent. replication
• Service consumed is available in both primary and secondary
data centers without manual intervention.
Active/Passive • User normally works in a single office location. Horizon 7 Enterprise Edition
RTO = Medium • Service consumed is pinned to a single data center. using CPA and storage area
network capable of multi-
RPO = Medium • Failover of the service to the second data center ensures site replication
business continuity.
Stretched • Environment uses full-clone desktops and IT wants to Horizon 7 Enterprise Edition
Active/Passive implement disaster recovery. using a single pod
RTO = Medium • 1:1 relationship between a user and a desktop. recovered in a second site
using VMware vSAN™
RPO = Medium • 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 1: Use Case Overview
To validate the design, an environment was built out and tests were run to simulate a real environment
and use cases. To provide replicating storage, we used all-flash arrays in the two use cases for sites in
geographically dispersed locations.
Important: Although we used all-flash arrays, you can use any other type of array that is capable of
replication and that would suit these use cases (where appropriate replication is available).
For the third use case, in which data centers are near each other, such as in a metro or campus network
environment with low network latency between sites, a stretched VMware vSphere® cluster using
VMware vSAN is used between the two data centers. This provides both the data replication required
and the high availability to recover the server components, desktops, and RDS hosts.
The integration of components to provide the service is done in a modular fashion, allowing for choices
to be made in how parts of the service are reproduced at the second site. It also allows for choices that
balance which components need to be recovered in an outage with allowing the user to be functional as
quickly as possible. This ultimately allows for the lowest possible RTO and RPO to be achieved for each
use case.
Audience
This paper describes how to address business requirements and use cases by integrating the various
components of VMware Horizon 7 Enterprise Edition to build services. It begins by defining business
requirements and drivers, which can be mapped to use cases that can be adapted to most scenarios.
This paper is intended to help organizations—IT architects, consultants, and administrators—involved in

the early phases of planning, design, and deployment of Horizon 7 Enterprise Edition in two data centers
for Business Continuity (BC) and Disaster Recovery (DR) purposes. It offers a standard, repeatable, and
highly scalable approach to design and integration that can easily be adapted to specific environments
and requirements.
The reader should understand desktop and application virtualization, including infrastructure elements
such as vSphere, storage, networking, Active Directory, and load balancing. Some familiarity with View
desktops in VMware Horizon 7, including capabilities and features introduced in Horizon 7 Enterprise
Edition, is also helpful.
Design Methodology
When building a Horizon 7 Enterprise Edition environment, it is important to follow proper design
methodology. The first steps are to address business requirements, identify users’ needs and organize
these into use cases, and then to align and map those use cases against a set of integrated services built
on Horizon 7 Enterprise Edition.
8
User
Experience
Business
Drivers and
2
Design Use Case
Definition
Services
Integration Services
Design Definition
7
3
Environment Architectural
Infrastructure Principles and
Design Concepts
vSphere 6 Horizon 7
Design Enterprise
Edition
6 Component
Design 4
Figure 2: Reference Architecture Design Methodology
A Horizon 7 Enterprise Edition design should use components that address the identified use cases.
Before these components can be assembled and integrated to form a service, the underlying Horizon 7
and vSphere infrastructure must be designed, built, and, typically, unified into the existing infrastructure
environment.
As suggested by Figure 2, this process is cyclical. All important decisions should be revisited to make
sure that subsequent decisions have not affected them in unexpected ways.
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.
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.
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 Horizon 7 Enterprise Edition Multi-Site Reference Architecture is intended to provide configuration
information and example architecture for deploying Horizon 7 Enterprise Edition in a two-site
configuration for primarily active/active workloads. One of the uses is to show how to build a resilient
environment that can deliver disaster recovery of Horizon 7 workloads.
This reference architecture does not provide performance data or stress-testing metrics; however, it
does provide data for all functional tests carried out to prove the architecture and the achieved RTO and
RPO numbers.
For details of the in-scope and out-of-scope components of this paper see Appendix A: Scope.
For detailed information on how to design and configure the individual Horizon 7 Enterprise Edition
components within a single site, refer to the VMware Horizon 7 Enterprise Edition Reference
Architecture. Additional information can also be found in the product documentation as referenced
throughout this paper and in Appendix C: Active/Passive Service Stretched with vSAN.
Business Drivers and Use Cases Definition

There are many ways and reasons to implement a multi-site solution for a Horizon 7 Enterprise Edition
environment. The most typical setup and requirement is for a two-data-center strategy. The aim is to
provide disaster recovery, with the lowest possible RTO and RPO; that is, to keep the business running
with the shortest possible time to recovery and with the minimum amount of disruption.
Meeting Business Requirements with Multi-Site Horizon 7 Deployments

The overall business driver for disaster recovery is straightforward: to keep the business operating
during an extended or catastrophic technology outage, providing continuity of service and allowing staff
to carry out their day-to-day responsibilities.
With services, applications, and data delivered by Horizon 7, 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:
• Provide essential services, and access to applications and data delivered by Horizon 7, to users, even
when an outage has occurred.
• Minimize interruptions during outages.
• Provide the same or similar user experience during outages.
• Cope with differing levels and types of outages and failures.
• Develop predictable and planned steps to recover functionality in the event of failures.
• Provide mobile secure access.
Table 2 describes the strategy used for responding to each of the business requirements from the
preceding list.
BUSINESS DRIVER COMMENTS
Provide essential services, and By designing an architecture where all intra-site components are
access to applications and data deployed in pairs and all services are made highly available—with
delivered by Horizon 7, to users, services able to be delivered from multiple sites, either in an
even when an outage has active/active or active/passive manner—the highest service level
occurred. possible is delivered, minimizing downtime in case of an outage.
Minimize interruptions during
outages.
Provide a familiar user Replicating the parts that a user considers persistent (profile, user
experience during outages. 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 This paper details a design for multi-site deployments to cope
types of outages and failures. with catastrophic failures all the way up to a site outage. The
Horizon 7 environment design ensures that there is no single point
of failure within a site.
T E C H N I C A L W H I T E PA P E R | 1 0
BUSINESS DRIVER COMMENTS
Develop predictable and planned Horizon 7 Enterprise Edition services are constructed from several
steps to recover functionality in components and designed in a modular fashion. A proper design
the event of failures. 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 2: Meeting Business Requirements with Multi-Site Horizon 7 Deployments
Use Case Recovery Requirements

Because this paper focuses on disaster recovery, the main emphasis falls on the availability and
recoverability requirements of the differing types of users.
Designing a Horizon 7 environment includes building out the functional definitions for the use cases and
their requirements. For a detailed description of this process, see VMware Horizon 7 Enterprise Edition
Reference Architecture, which defines five typical use cases that are adaptable to cover most scenarios
and then defines services to deliver the requirements of those use cases. This reference architecture
examines the differing requirement types for disaster recovery and later, when defining the disaster
recovery services, maps them to each of the Horizon 7 services.
This reference architecture caters to three common disaster recovery classifications, which can be
adapted to cope with most scenarios in a disaster recovery–enabled Horizon 7 Enterprise Edition
environment.
USE CASE AND DESCRIPTION

OBJECTIVES
Active/Active • User requires the lowest possible recovery time for service (for example, health worker).
RTO = Low • Mobile user might roam from continent to continent.
RPO = Low • User needs to get served from nearest geographical data center per continent.
• Service consumed is available in both primary and secondary data centers without manual
intervention.
Active/Passive • User normally works in a single office location.

RTO = Medium • Service consumed is pinned to a single data center.
RPO = Medium • Failover of the service to the second data center ensures business continuity.
Stretched • Environment uses full-clone desktops, and IT wants to implement disaster recovery.
Active/Passive • 1:1 relationship between a user and a desktop.
RTO = Medium
• Failover of the service to the second data center ensures business continuity.
RPO = Medium
• Data centers are in a metro or campus network environment with low network latency
between sites.
Table 3: 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.
Recovery Service Definitions

Combining business requirements with a use case enables the definition of a service that can deliver an
appropriate solution. In this reference architecture, the services defined focus on availability and
recoverability. Services are defined by identifying and aligning the right mix of products, features, and
technologies to address each use case. The detail required to build out the products and components
comes later, after the services are defined and the components required are understood.
This paper maps Horizon 7 services from the VMware Horizon 7 Enterprise Edition Reference
Architecture to a disaster recovery service. Some of these services could be mapped to a different
disaster recovery service, depending on the exact mix of Horizon 7 components being used in it.
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/active mode, the loss of a View pod or data center instance 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 active/passive mode, loss of an active View pod or data center instance requires that the passive
instance of the service be promoted to active status for 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.
The following functionality is used across the use cases.
REQUIREMENT COMPONENT
Single sign-on, SaaS applications VMware Identity Manager
Infrastructure platform VMware vSphere
Storage platform All-flash arrays, other types of storage that offer replication, or, for
data centers with low latency between sites, VMware vSAN
Virtual desktops and RDSH-remoted apps VMware Horizon 7
Application deployment VMware App Volumes
User profile, IT settings, and configuration for VMware User Environment Manager
environment and applications
Table 4: Recovery Requirements
Active/Active Service
Requirement: 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 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.
REQUIREMENT 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 • Horizon 7 desktop and application pools are created in both data
both sites 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 apps exist in both data center pools.
Attached applications Applications contained in App Volumes AppStacks are replicated using App
(optional) 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 User Environment Manager user data is replicated to another data center.
(optional) The following RTO and RPO targets apply during a data center outage when
a recovery process is required:
• RPO = Approximately 2 hours
Mobile access Unified Access Gateway, Blast Extreme
Table 5: Active/Active Service Requirements
Active/Active Service Blueprint

At a high level, this service consists of a Windows environment delivered by a desktop or an RDS host
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.

RDSH Farm
Home
Instant or IT User File
Site 1
Linked Clone Config Settings Shares
Active
Windows OS Master VM AppStacks (Optional)

User
tive
Ac tive
Ac
Service
Replication
Site 2
Active
Failover
Windows OS
Desktop Pool/
Figure 3: Active/Active Service Blueprint
Active/Active App Volumes Blueprint

Although applications can be installed in the base OS, they can alternatively be delivered by App
Volumes AppStacks. Applications are attached either to the desktop, at user login, or to the RDS host 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.
Service Apps App Database

Volumes
Desktop / RDSH Clone Managers
Site 1
AppStacks SQL
User
Service
Replication Entitlement
Client(s) Desktop / RDSH Clone Replication
Site 2
Active
Attached Apps
App
Volumes
Apps Managers Database
Figure 4: Active/Active App Volumes Option Blueprint
Active/Active Profile Blueprint

The user profile and data can be included as an optional component of this service. 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).
Service Profile File Server Shares

Home
IT User File Config User Home
Site 1
Config Settings Shares Share Share Share

Profile
and Files
Active
User
ive
t
Ac
e
iv
ct
A
Service
Replication
Home
IT User File
Site 2
Config Settings Shares

Profile
and Files Active
Failover
Profile File Server Shares
Figure 5: Active/Active Profile Option Blueprint
Active/Passive Service
Requirement: 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.
Horizon 7 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 • Horizon 7 pools or farms are created in both data centers.
available in both sites • 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 Applications contained in App Volumes AppStacks are replicated using App Volumes
(optional) storage groups.
User-installed applications App Volumes writable volumes.

(optional) • RTO = 60–90 minutes
• RPO = 1–2 hours (array dependent)
IT settings User Environment Manager IT configuration is replicated to another data center.

• RPO = Approximately 5 minutes
User data and User Environment Manager user data is replicated to another data center.
configuration • RTO = 30–60 seconds
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 6: Active/Passive Service Requirements
Active/Passive Service Blueprint

At a high level, this service consists of a Windows environment delivered by either an instant- or linked-
clone desktop or RDS host, 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.

RDSH Farm
Home
Site 1
User
Standby Service
Replication
Site 2
User Apps Active
Attached Apps
Failover
Windows OS
Desktop Pool/
Figure 6: Active/Passive Service Blueprint
VMware Identity Manager/Workspace ONE Blueprint

Horizon 7 can optionally be integrated with Workspace ONE through VMware Identity Manager. It is not
a required component in all the services defined in Table 6.
Service VMware Database

Identity Manager
Appliances
Workspace ONE
SQL AlwaysOn
Site 1
Apps
Active
User
Standby Service
Replication
Client(s) Workspace ONE
Site 2
Apps
Failover Failover
VMware
Identity Manager Database
Profile
Appliances
Figure 7: VMware Identity Manager/Workspace ONE Option Blueprint
Active/Passive App Volumes Blueprint

App Volumes AppStacks are used to attach applications to either the desktop or the RDS host. Because
these AppStacks are read-only to users and are generally infrequently changed by IT, they are replicated
to the second, and subsequent, locations and are available for assignment and mounting there as well.
If writable volumes are used for content such as user-installed applications, these 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. This 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.

Volumes
Writable
Site 1
User Apps AppStacks Volume SQL
User
Standby Service
Site 2
User Apps Active
Attached Apps
Failover
App
Volumes
Figure 8: Active/Passive App Volumes Option Blueprint
Profile Blueprint
Operational decisions can be made in a recovery scenario as to whether the service in Site 2 would be
made available with reduced functionality (for example, without some of the profile components).

Home
Site 1

Profile
and Files
Active
User
ive
t
Ac
e
iv
ct
A
Service
Replication
Home
IT User File
Site 2

Profile
and Files Active
Failover
Figure 9: Profile Option Blueprint
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.
Horizon 7 Pod and Block

One key concept in a VMware Horizon 7 environment design is the use of pods and blocks, which
enables a repeatable and scalable approach. A View pod is made up of a group of interconnected
Connection Servers running in the same LAN segment that broker desktops or published applications.
Important: A single View 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).
Architectural Approaches
Besides the principles outlined in this section, this paper also adheres to some architectural guidelines
that address the recoverability targets defined in Recovery Service Definitions.
Active/Active Architecture
Active/active architecture uses two or more View pods, 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.
Site 1 Site 2
Pod 1 Pod 2
CPA
Connection Servers Connection Servers
Figure 10: Active/Active Architecture
Active/Passive Architecture
Active/passive architecture uses two or more View pods with at least one 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, with the difference being how the global entitlement and user home sites are
configured.
Site 1 Site 2
Pod 1 Pod 2
CPA
Figure 11: Active/Passive 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.
Site 1 Site 2
Pod 1 Pod 2
vSphere HA
Figure 12: Stretched Active/Active Architecture
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:
• 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)
• VMware Identity Manager
Steps should be taken 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 cover what needs to happen to recover
them.
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 in Site 1. 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 Horizon 7 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.
• Use Cloud Pod Architecture (CPA) 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 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 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 2014, but
Microsoft SQL Server 2016 is also supported.
Logical Architecture
Figure 13 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.
https://identity.company.com
https://horizon.company.com
Site 1 Global Load Balancer Site 2

Local Load Balancer Local Load Balancer
Unified Access Gateways VMware Identity Managers VMware Identity Managers Unified Access Gateways
DMZ DMZ
VMware VMware
Identity Manager Identity Manager
Connectors Connectors
VMware Identity Manager AG Listener
Composer Composer
SQL FCI #1 SQL Always On SQL FCI #2
(Primary) SQL (Asynchronous) SQL (Secondary)
SQL Servers SQL Servers
App Volumes Mangers AppStack Entitlement Replication App Volumes Mangers
Horizon Horizon
Events Events
AG Listener AG Listener
Composer App Volumes App Volumes Composer
Active Directory Active Directory
AG Listener AG Listener AG Listener AG Listener
Services Services
SQL Always On SQL Always On

SQL SQL (Synchronous) (Synchronous) SQL SQL
Site 1 – Management Site 1 – VDI vCenter Site 2 – Management Site 2 –VDI vCenter
vCenter Server Server vCenter Server Server
Volume for SMB Share
iSCSI RDM RDM iSCSI

Storage Replication
Site 1 - Storage Array Site 2 - Storage Array
Figure 13: 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.
Horizon 7 Component Design with a Disaster Recovery Focus

To be able to deliver the Horizon 7 Enterprise Edition services outlined and to address the requirements
and goals, it is necessary to design and build out the infrastructure components required for the two
data centers.
This section covers a high-level design of each of the products or areas that need to be considered. It is
not meant to be an exhaustive configuration or installation guide, for which the reader should consult the
product documentation cited under References. This document does aim to give detail where general
product documentation presents multiple options and the recommendation needs to be clearly stated. It
also gives best-practice recommendations for deploying these components across two data centers.
For this reference architecture design, certain design choices were made for the shared infrastructure
components that are relied upon between sites. For the Microsoft SQL Server Always On primary node
placement,
• Site 1 is the primary site.
• The primary database instance runs in Site 1.
• When services that rely on SQL Server Always On availability groups (VMware Identity Manager, in this
case) are running in Site 2, they incur some cross-site traffic when performing read and write
operations.
VMware Identity Manager does not implement any read-only intent features from SQL Server Always On.
VMware Identity Manager

VMware Identity Manager is the primary entry point for end users to consume Horizon 7 virtual desktops
and all types of applications, including SaaS, web, Horizon 7 published applications, Citrix XenApp, and
mobile apps. Therefore, we deploy it to be highly available within a site, and we deploy VMware Identity
Manager 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 individual appliances 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.
Database
VMware Identity Manager 2.9 (and later) supports Microsoft SQL Server 2014 (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 Figure 14.
Global Load Balancer
Active Connection Standby Connection


Group 2
Group 1
VMware VMware VMware VMware VMware VMware

Identity Identity Identity Identity Identity Identity
Manager Manager Manager Manager Manager Manager
Node 1 Node 2 Node 3 Node 4 Node 5 Node 6
SQL Server
Always On Listener
Primary Secondary
Windows Failover
Windows Failover
SQL Server SQL Server
Database Database
Cluster 2
Cluster 1
Windows Windows Windows Windows

Server 1 Server 2 Server 1 Server 2
Site 1 Site 2
Figure 14: 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 access 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 Appendix G: Setting Up VMware Identity Manager for High
Availability in Multiple Sites.
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.
For detailed guidance on how to configure F5 with VMware Identity Manager, please refer to Appendix
E: F5 Load Balancing Configuration.
Horizon 7 with 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 entitle users and groups to 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.
Figure 15 is 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 View Cloud Pod
Architecture.
Inter-Pod
Communication
Site 1 Site 2
Local A Local A
DLDS and JMS DLDS and JMS
Global ADLDS Global ADLDS
Figure 15: 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 7: Global Entitlement Settings for Roaming User Use Case
The above 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 8: Global Entitlement Settings for Power User Use Case
The above 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.
The home site configuration for the above two groups looks like the following:
GROUP DOMAIN SITE
Site1-PowerUsers VMWEUC Site 1
Table 9: 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
Table 10: 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.
Unified Access Gateway

Unified Access Gateway (formerly known as Access Point) appliances provide secure edge services for
users accessing the environment from outside the corporate network. 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. This document describes the multi-site considerations and does
not cover the design implications of network placement of components.
There is no difference in the deployment method when deploying Unified Access Gateway to be used in
a multi-data-center setup. Unified Access Gateway in itself is only aware of the data center context it is
running in, and the global load balancer is the component that directs users to a site that is available to
serve user requests.
Figure 16 shows the logical deployment model for each site.
DMZ
VMware
Identity
Unified
Horizon Internet Manager
Access
CS
Clients
Gateway
VMware vSphere
Horizon 7 Desktops
and RDS Hosts
CS
Figure 16: Unified Access Gateway Topology
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, with the northbound
connection placed in the DMZ and the southbound connection being 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.
For a full reference on how F5 BIG-IP DNS (GTM) was used in this reference architecture, refer to
Appendix E: F5 Load Balancing Configuration.
App Volumes
App Volumes Manager 2.12.1 is used in this reference architecture to deploy applications to the desktops
and RDS hosts.
VMware App Volumes delivers applications that are not in the master image for VDI and RDSH. App
Volumes groups applications into AppStacks (virtual disks) based on the requirements of each use case.
The AppStacks can then be assigned to a user, group, OU, or machine (RDSH).
For VDI use cases, AppStacks can be mounted either on demand or at login. With RDSH use cases,
AppStacks are assigned to the machine account so AppStacks are mounted only when the App Volumes
service starts.
App Volumes can also provide user-writable volumes for use with VDI desktops. 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 from one session to another.
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 ms, VMware recommends that you use
separate databases. The disadvantage is that user-based entitlement to AppStacks must be replicated in
both sites. This process can be automated, as described in Appendix F: PowerShell Script for Replicating
App Volumes Application Entitlements.
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 would have 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.
Site 1 Site 2
SQL SQL
App Volumes Managers App Volumes Managers
Database Database
vSphere vSphere
Hosts Hosts
Datastore 1 Datastore 2 Datastore 3 Datastore 4 Datastore 5
Storage Group #1 Non-Attachable Storage Group #2
Figure 17: App Volumes Multi-Site Separate-Databases Option
With this option,

• Separate instances of App Volumes are deployed in each site.
• 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 Appendix F: PowerShell Script
for Replicating App Volumes Application Entitlements.
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 1. 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 H: Setting Up VMware App
Volumes for High Availability in Multiple Sites.
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 Active/Active
Applications Delivered Just in Time by App Volumes.
6. Configure and run the PowerShell script for replicating AppStack entitlements between the sites, as
described in Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.
With this design, the following is achieved:
• 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.
• 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 Active/Passive Horizon 7 Service Failover Test/Recovery 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 Writables
operation from the App Volumes Manager at Site 2.
For detailed information on the steps required and the order in which they need to be executed, refer to
Appendix D: Test Plan.
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.
Site 1 Site 2
App Volumes Managers Clustered App Volumes Managers
SQL
Database
P S
vSphere vSphere
Hosts Hosts
Figure 18: 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 Active/Active
Applications Delivered Just in Time by App Volumes.
For details on configuration of a clustered database for App Volumes, see Appendix I: Configuration
Procedures for a Clustered App Volumes Database.
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.
For detailed information on the steps required and the order in which they need to be executed, refer to
Appendix D: Test Plan.
User Environment Manager

VMware User Environment Manager provides profile-like management by capturing user settings for the
operating system and applications. User Environment Manager leverages file shares to store this
configuration and data, so it relies on that underlying infrastructure to be highly available.
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
• 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.
User Environment User Environment

Manager Manager Config Share (Master)
Management
Console
User Environment User Environment User Environment

Manager Manager Manager
Config Share Config Share Config Share
(America) (EMEA) (APAC)
Figure 19: Supported DFS Topology for User Environment Manager IT Configuration Share
User Settings Shares

For user settings file shares, DFS-Namespace is fully supported.
SyncTool
Laptops RDSH or VDI Desktops
DFS-Namespace

Manager Manager
Profile Share Profile Share
Fileserver 1 Fileserver 2
Figure 20: 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.
SyncTool
Laptops RDSH or VDI Desktops
DFS-Namespace

Manager Manager
Profile Share Profile Share
Fileserver 1 Fileserver 2
Figure 21: 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.
vSphere Infrastructure Design for Active/Active and Active/Passive Services

Standard VMware 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 vSphere Infrastructure Design Using vSAN.
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 paper. 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 VMware Horizon 7 Enterprise Edition
Reference Architecture document.
View Pod and Block

Horizon 7 design is based around the use of pods and blocks, which allow for a repeatable and scalable
approach to building systems.
A View pod is a logical entity that can support up to 10,000 users or sessions. A pod contains a
management block and one or more resource blocks for hosting desktops or RDS hosts.
The management block contains all the vSphere and Horizon 7 server virtual machines. One vCenter
Server instance is deployed for managing the management cluster infrastructure, and there is also a
dedicated vCenter Server for each resource block.
A resource block can host up to 2,000 virtual desktops or RDSH server VMs. (Although each vCenter
Server can support up to 4,000 virtual desktops, keeping the number to 2,000 improves operation
times.)
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.
vCenter Server vCenter Server

Management Desktops
Management Block Desktop Block
3 x Dell R720 3 x Dell R720

2 x Intel Xeon E5-2697 v2 2 x Intel Xeon E5-2697 v2
24 C @ 2.7 GHz 24 C @ 2.7 GHz
256 GB RAM 256 GB RAM
Datastores: Datastores:
- Management - Linked Clones
- Instant Clones
1 x vCenter Server - RDSH Servers
(Management) - AppStacks
- Writable Volumes
1 x vCenter Server (Desktop)
Windows 10
Linked Clones
2 x Connection Servers
1 x Composer
2 x SQL Windows 10
Full Clones
2 x App Volumes Managers
Windows 2012 R2
2 x Unified Access Gateways RDSH Servers
3 x VMware Identity Manager

Windows 10
2 x Domain Controller Instant Clones
2 x Load Balancers
Figure 22: Horizon 7 Blocks
Networking
All network components should be configured redundantly, either as active/passive or as active/active
where possible. This design used 10-GbE adapters to simplify networking infrastructure and to avoid
other 1-GB drawbacks such as inadequate bandwidth and lower utilization.
vmk0 vmk1 vmk2 vmk3
ESXi
Virtual
Management vMotion iSCSI 1 iSCSI 2
Machines
Network
vSphere Distributed Switch
10 Gb 10 Gb
10 Gb Switches
Figure 23: vSphere Networking
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.
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 logical diagram Figure 24.
vSphere Cluster vSphere Cluster
Storage Storage
vCenter Server vCenter Server
Connection Server
SQL Composer DC App Volumes VMware Identity

Manager Manager
vCenter Server (Management)

vSphere Cluster (Management)
Storage
Figure 24: 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.
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 Appendix B: Active/Active and Active/Passive Service with Replicating Storage
Arrays.
IP
Network
Site 1 Site 2
\\domain\uem\site1 \\domain\uem\site1
\\domain\uem\site2
\\array1\UEM-S1 \\array2\UEM-S2
Storage Array 1 Storage Array 2
Copy snapshot
to new volume
Figure 25: Asynchronous Replication
Environment Infrastructure Dependencies Design

Several environment resources are required to support a Horizon 7 deployment. In most cases, they
already exist, but some key items are especially important when the environment is used for a multi-site
deployment.
Active Directory
Horizon 7 requires an Active Directory (AD) domain structure for user authentication and management.
See the View Installation guide for details on supported versions and preparation steps. Standard best
practices for an Active Directory deployment should 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.
Group policies can also be associated at a site level.
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)
• ThinApps
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, ThinApps).
More detail on how DFS design applies to profile data can be found in the User Environment Manager
section of this document.
Global Load Balancing and Name Spaces

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 2012 R2–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 Appendix
E: F5 Load Balancing Configuration.
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.
Figure 26 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.
horizon.vmweuc.com
Pod
Pod
Figure 26: 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.
DHCP
In multi-site deployments, the number of desktops a given site is serving usually changes when a failover
occurs. This reference architecture tested deploying 500 desktops in each site, which requires, at a
minimum, a /23 subnet range for normal production.
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. To ensure additional capacity in a failover scenario, a larger /21 subnet was used for the desktop
range, which provided approximately 2,000 IP addresses, meeting the requirements for running 1,000
desktops in either site during a failover while still leaving enough capacity should reservations get
released.
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 to run the
total number of required desktops from each site and within a site in a failover scenario.
As with any virtual desktop environment, consumption of DHCP can be quite fluid, with floating pools
created with clones potentially deleting desktops at logout and recreating replacements. It is therefore
necessary to make sure the lease period is set to a relatively short period (this depends on the frequency
of logouts and the lifetime of a clone).
Microsoft RDS Licensing

Horizon 7 published applications use Microsoft RDSH servers as a shared server platform to host
Windows applications. Microsoft RDS hosts 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 KMS
The cloning process for virtual desktops and RDSH server VMs uses a Microsoft volume license key to
activate Windows. To configure the volume license key, you use Microsoft Key Management Service
(KMS). It is critical to ensure that the KMS service is highly available within each site and also redundant
across sites.
Horizon 7 Components Required for Recovery Services

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 service to be consumed by end users.
The table below details the components required for each service. Some are optional, as indicated in the
Recovery Service Definitions section. The rest of this section details the steps for implementing each of
the 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 the section Horizon 7 Components Required
for vSAN Stretched Cluster Recovery Services.
COMPONENT ACTIVE/ACTIVE ACTIVE/ PASSIVE VSAN STRETCHED

SERVICE SERVICE 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 11: 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
The emphasis in this paper is on the configuration and integration necessary for multi-site deployments
and disaster recovery. For more detail on creating and configuring components such as master VM
images and pools of desktops, refer to the Horizon 7 documentation and the VMware Horizon 7
Enterprise Edition Reference Architecture.
This section covers the high-level steps required to build out the active/active service, which can be seen
from a blueprint perspective in Figure 27.

RDSH Farm
Home
Instant or IT User File
Site 1
Linked Clone Config Settings Shares
Active
Windows OS Master VM AppStacks (Optional)

User
tive
Ac tive
Ac
Service
Replication
Site 2
Active
Failover
Windows OS
Desktop Pool/
Figure 27: Active/Active 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
RDS hosts 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 12: Steps for Creating the Windows Component of an Active/Active 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
Figure 28.

Home
Site 1

Profile
and Files
Active
User
ive
t
Ac
e
iv
ct
A
Service
Replication
Home
IT User File
Site 2

Profile
and Files Active
Failover
Figure 28: Profile 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
• Home file shares for redirected folders (optional)
Set up DFS-N following the guidance given in the User Environment Manager and
Distributed File System sections.
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 13: Steps for Creating the User Profile Component of an Active/Active Service
Active/Active Design for Applications Delivered Just in Time by App Volumes

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.

Volumes
Site 1
AppStacks SQL
User
Service
Site 2
Active
Attached Apps
App
Volumes
Figure 29: Active/Active App Volumes Service Component
APP VOLUMES
STEP DETAILS
Installation 1. Set up two or more App Volumes Managers in Site 1.

2. Set up two or more App Volume Managers in Site 2.
See the App Volumes design section 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 a storage group in Site 1.

• Select Automatically Replicate AppStacks.
• Select all datastores to be used for AppStacks.
• Additionally, select one common datastore to be used to replicate AppStacks to Site 2.
NFS is a good choice for this datastore.
• Mark this common datastore as non-attachable.
Set up a second storage group in Site 2.
• Additionally, select the common datastore to be used to replicate AppStacks from Site 1.
AppStacks 1. Create AppStacks as required to address the use cases. Follow the instructions in Working
with AppStacks in the VMware App Volumes User 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 If you are using the separate-databases configuration, do one of the following:
replication • Manually reproduce entitlements made at one site to the other sites.
• Or, configure PowerShell for replicating application entitlements between the sites, as
described in Appendix F: PowerShell Script for Replicating App Volumes Application
Entitlements.
Table 14: Steps for Creating the Streamlined Application Component of an Active/Passive Service
This section covers the high-level steps required to build out the active/passive service, which can be
seen from a blueprint perspective in Figure 30.

RDSH Farm
Home
Site 1
User
Standby Service
Replication
Site 2
User Apps Active
Attached Apps
Failover
Windows OS
Desktop Pool/
Figure 30: Active/Passive 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 RDS
hosts 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
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 For desktops, create identical desktop pools in both sites based on the master VM.
farm 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 Set up and initialize Cloud Pod Architecture between the two sites.
Architecture • Create sites and assign the pods to their respective sites.
• Create global entitlements.
• Associate pools from both sites.
Table 15: 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 Figure 31.

Home
Site 1

Profile
and Files
Active
User
ive
t
Ac
e
iv
ct
A
Service
Replication
Home
IT User File
Site 2

Profile
and Files Active
Failover
Figure 31: Profile 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
• Home file shares for redirected folders (optional)
Set up DFS-N following the guidance given in the User Environment Manager and
Distributed File System sections.
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 16: Steps for Creating the User Profile Component of an Active/Passive Service
Active/Passive Design for Applications Delivered Just in Time by App Volumes

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.

Volumes
Writable
Site 1
User Apps AppStacks Volume SQL
User
Standby Service
Site 2
User Apps Active
Attached Apps
Failover
App
Volumes
Figure 32: Active/Passive App Volumes Service Component
APP VOLUMES
STEP DETAILS
Installation 1. Set up two App Volumes Managers in Site 1.

2. Set up two App Volume Managers in Site 2.
See the App Volumes design section 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.
APP VOLUMES
STEP DETAILS
Storage groups Set up a storage group in Site 1.

• Additionally, select one common datastore to be used to replicate AppStacks to Site 2.
NFS is a good choice for this datastore.
Set up a second storage group in Site 2.
• Additionally, select the common datastore to be used to replicate AppStacks from Site 1.
AppStacks 1. Create AppStacks as required to address the use cases. Follow the instructions in Working
with AppStacks in the VMware App Volumes User 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 If you are using the separate-databases configuration, do one of the following:
replication • Manually reproduce entitlements made at one site to the other sites.
• Or, configure PowerShell for replicating application entitlements between the sites, as
described in Appendix F: PowerShell Script for Replicating App Volumes Application
Entitlements.
Writable volumes 1. Create writable volumes for each user that requires one. Follow the instructions in Working
(optional) with Writable Volumes in the VMware App Volumes User Guide.
2. Place writable volumes on dedicated LUNs, which can later be configured to be protected
using storage replication.
Table 17: Steps for Creating the Streamlined Application Component of an Active/Passive Service

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.
Service VMware Database

Identity Manager
Appliances
Workspace ONE
SQL AlwaysOn
Site 1
Apps
Active
User
Standby Service
Replication
Client(s) Workspace ONE
Site 2
Apps
Failover Failover
VMware
Identity Manager Database
Profile
Appliances
Figure 33: VMware Identity Manager 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 G: Setting Up
VMware Identity Manager for High Availability in Multiple Sites.
VMWARE IDENTITY MANAGER CONFIGURATION
STEP DETAILS
Load balancing Configure local and global load balancer virtual servers.
First appliance Deploy the VMware Identity Manager OVA in Site 1.

Follow the guidelines in the VMware Identity Manager design section.
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.
VMWARE IDENTITY MANAGER CONFIGURATION
STEP DETAILS
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 18: Steps for Creating the Single Sign-On VMware Identity Manager Component of an Active/Passive 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 Appendix B: Active/Active and Active/Passive Services with Replicating Storage
Arrays.
Replication targets Protect or replicate the datastores holding App Volumes writable volumes.
Table 19: Steps for Setting Up Storage Replication for an Active/Passive Service
Reference Architecture Validation

This section details the impact to both users and services during failure and the behavior after failover
for all the services.
DURING FAILURE AFTER FAILOVER
Logged in user Current sessions terminated. N/A
New user logging in User can log in to failover site User can log in as normal.
immediately.
VMware Identity Manager N/A (The VMware Identity N/A

Manager component is not
supported in active/active mode.)
Access to user profile User User gets temporary profile. User gets own profile.
Environment Manager
Access to AppStacks User has access to AppStacks. User has access to AppStacks.
Access to writable volumes N/A N/A
Table 20: Active/Active Service Failure Impact
Logged in user Current sessions terminated. N/A (After the current session is
terminated, the user must log in
again, and so becomes a new user
logging in.)
New user logging in User cannot log in until CPA home User can log in as normal.
site changed.
VMware Identity Manager User might not have immediate User has access to VMware
access to VMware Identity Identity Manager.
Manager (depends on location of
SQL primary node during failure).
Access to user profile User N/A User gets own profile.

Environment Manager
Access to AppStacks User has access to AppStacks. User has access to AppStacks.
Access to writable volumes Writable volumes unavailable. User has access to writable volume.
Table 21: Active/Passive Service Failure Impact
vSAN Stretched Cluster Active/Passive Service

For the third use case, in which data centers are near each other, such as in a metro or campus network
environment with low network latency between sites, a stretched VMware vSphere cluster using VMware
vSAN is used between the two data centers. This provides both the data replication required and the
high availability to recover the server components, desktops, and RDS hosts.
This use case uses full-clone desktop VMs to address existing Horizon 7 implementations that use full-
clone persistent desktops that cannot easily be transitioned into a nonpersistent use case for various
business reasons.
Recovery Service Definition for Stretched vSAN 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 when used in a stretched cluster configuration between two data centers. The
Horizon 7 server components required 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 View pods per site
with Cloud Pod Architecture for global entitlements.
Horizon 7 services accommodated: Legacy Full Clones, Developer Workspace Service. The overall RTO
is between 15 and 30 minutes with an RPO of 15 to 30 minutes.
REQUIREMENT COMMENTS
Full-clone Windows Persistent use case with 1:1 mapping of a VM to a user.

desktop VMs 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.
• RPO = 30–60 seconds
User data and User Environment Manager user data is replicated to another data center.
configuration (optional) • RTO = 30–60 seconds
Table 22: Stretched vSAN Active/Passive Service Requirements
Stretched vSAN Active/Passive Service Blueprint

This service uses stretched 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.
Service Apps Profile

Desktop
Desktop Pool
Home
Desktop IT User File
Site 1
Clone Installed in Clone OS Config Settings Shares
Active
Windows OS
User
Standby Service
Replication
Client(s) Desktop
Site 2
Failover
Windows OS
Stretched
Storage Apps Profile
Figure 34: Stretched vSAN Active/Passive Service Blueprint
Architectural Approach for the Stretched Active/Passive Service

This architecture relies on a single View 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.
Site 1 Site 2
Pod 1 Pod 2
vSphere HA
Figure 35: Stretched Active/Passive Architecture
vSphere Infrastructure Design Using vSAN

The stretched 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 VMware 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.
In a stretched cluster, within a metro or campus network environment with low network latency between
sites, VMware vSAN provides a radically simple business continuity solution, with short RTO time and no
loss of data. The stretched cluster synchronously replicates data between two sites, providing high
availability and protection against a single-site failure. This design is covered in more detail in Appendix
C: Active/Passive Service Stretched with vSAN.
VMware vSAN supports 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.
Fault Domain A Fault Domain C Fault Domain B
Storage
Witness Appliance
vSAN Stretched Cluster
SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD
Site 1 Site 3 Site 2

(Active) (Witness) (Active)
Figure 36: Stretched vSAN 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.
vCenter Server
Stretched vSAN Cluster
Data site to data site,

L2 network, multicast,
<5 ms latency, 10 Gbps
Preferred Site 1 Secondary Site 2

(Active) (Active)
Witness to data site, Witness to data site,

L3 network, no multicast, L3 network, no multicast,
200 ms latency 200 ms latency
(500 ms latency for two nodes), (500 ms latency for two nodes),
100 mbps 100 mbps
Witness Site 3
Figure 37: Stretched vSAN Networking
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.
View 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.
vCenter Witness
Server Host
VMware vSAN Stretched Cluster vSphere 6.5 HA/DRS Cluster

Sites 1 and 2 Site 3
6 x Dell PowerEdge R730 vSphere 6.5

2 x Intel Xeon E5-2695 v3 HA/DRS Cluster
24 C @ 2.3 GHz
256 GB RAM
Shared Storage
All-Flash vSAN
-1 x 400 GB Caching SSD
-5 x 400 GB Capacity SSD 1 x Witness VA
1 x vCenter Server Appliance
2 x Connection Servers
1 x Witness ESXi
Windows 10 Full Clones
Figure 38: Horizon 7 Blocks on Stretched vSAN
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.
vmk0 vmk1 vmk2
ESXi
Virtual vSphere
Management vSAN
Machines vMotion
Network
vSphere Distributed Switch
10 Gb 10 Gb
10 Gb Switches
Figure 39: vSphere Networking
Horizon 7 Components Required for vSAN Stretched Cluster Recovery Services

This section covers the high-level steps required to build out the stretched active/passive service (using
a vSAN cluster), which can be seen from a blueprint perspective in Figure 40.
Service Apps Profile

Desktop
Desktop Pool
Home
Desktop IT User File
Site 1
Clone Installed in Clone OS Config Settings Shares
Active
Windows OS
User
Standby Service
Replication
Client(s) Desktop
Site 2
Failover
Windows OS
Stretched
Storage Apps Profile
Figure 40: Stretched Active/Passive Service
Table 23 outlines the steps required for creating a vSAN stretched cluster.
STEP DETAILS
Prerequisites Ensure the vSAN prerequisites in Appendix C: Active/Passive Service Stretched with
vSAN are met.
Witnesses Deploy a vSAN witness appliance on a vSphere 6.5 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 Appendix C: Active/Passive Service Stretched
with vSAN.
Affinity To pin the management servers as a unit to a particular site, you must create VMHost
groups and VMHost rules.
See Appendix C: Active/Passive Service Stretched with vSAN.
Complete Configure Horizon 7 servers and the VM template for the virtual desktops.
Provision Horizon 7 full-clone desktops.
Table 23: Steps for Configuring a vSAN Stretched Active/Passive Service
Table 24 outlines the steps for creating the virtual desktops and published applications to be provided
by a vSAN stretched cluster.
STEP DETAILS
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 24: Steps for Creating the Windows Component of a vSAN Stretched 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 Environment Infrastructure Dependencies 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.
Logged in user Some sessions terminated (depends N/A

on location where desktop is
running).
New user logging in User cannot log in. Once management services have
resumed, user can log in as normal.
Access to user data If desktop is not disconnected, User has access to data.
full-clone user has access to data.
Table 25: vSAN Stretched Cluster Active/Passive Service Failure Impact
Appendix A: Scope
Tables 26 and 27 summarize the components, services, and features in use in this reference architecture.
IN SCOPE COMMENTS
Horizon 7 version 7.2
VMware Identity Manager 2.9.1 On-premises version used.
Unified Access Gateway 2.9.1
User Environment Manager 9.2
App Volumes Manager 2.12.1
VMware vSAN 6.6 stretched cluster This component was used only for the Stretched Active/Passive service.
Table 26: In-Scope VMware Components
OUT OF SCOPE COMMENTS
3D workloads
Linux desktops
True SSO
Vendor-specific solutions for load F5 BIG-IP is used for load balancing both inside and between sites; however,
balancing and storage replication F5 is not a requirement.
All-flash array replication was used to replicate App Volumes writable volumes
between sites; however, any vendor that offers crash-consistent replication of
datastores supported by vSphere 6.x can be used.
Table 27: Out-of-Scope Components
Appendix B: Active/Active and Active/Passive Services with Replicating

Storage Arrays
Some vSphere configuration changes are recommended for optimal performance. These changes and
other settings are documented in this section.
VSPHERE HA SETTING
vSphere HA Turn on vSphere HA
Host Monitoring Enabled
Host Hardware Monitoring – VM Component Protection: “Protect against Storage Disabled (default)
Connectivity Loss”
Virtual Machine Monitoring Disabled (default)
Table 28: vSphere High Availability (HA) Settings
Leave all other HA settings set to the default.
VSPHERE DRS SETTING
vSphere DRS Turn on vSphere DRS
DRS Automation Fully Automated
Power Management Off
Table 29: vSphere Distributed Resource Scheduler Settings
Leave all other DRS settings set to the default.
Table 30 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 Status Disabled –

Shaping
Policies: Teaming and Load balancing Route based on the originating Route based on
Failover virtual port ID physical NIC load
Failover detection Caution Link Status only –
Notify switches Yes –
Policies: Resource Network I/O Control Disabled Enabled

Allocation
Advanced Maximum MTU 1500 9000
Table 30: Distributed Switch Settings
Appendix C: Infrastructure Design for the Stretched vSAN Active/Passive Service

This appendix provides specifications for designing the infrastructure of the active/passive service
stretched with vSAN, including settings for vSAN, vSphere, distributed switches, and storage.
Table 31 details the vSAN prerequisites.
REQUIREMENTS
Three dispersed sites • Two data sites, each with an equal number of ESXi hosts
• One witness site with dedicated ESXi physical server or virtual appliance, per vSAN
stretched cluster
Network Data site to data site

requirements • < 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 31: vSAN Prerequisites
The vSphere High Availability (HA) settings are summarized in Table 32.
VSPHERE HA SETTING
vSphere HA Turn on vSphere HA
Host Monitoring Enabled
Host Hardware Monitoring – VM Component Protection: Disabled (default)

“Protect against Storage Connectivity Loss”
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 32: vSphere High Availability (HA) Settings
Settings for vSphere Distributed Resource Scheduler are summarized in Table 33.
VSPHERE DRS SETTING
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 33: vSphere Distributed Resource Scheduler Settings
The following table shows the distributed switch and port group policies.
General Port Binding Static –
Policies: Security Promiscuous mode Reject –
MAC address changes Accept Reject
Forged transmits Accept Reject
Policies: Traffic Status Disabled –

Shaping
Policies: Teaming and Load balancing Route based on the originating Route based on
Failover virtual port ID physical NIC load
Failover detection Caution Link Status only –
Notify switches Yes –
Policies: Resource Network I/O Control Disabled Enabled

Allocation
Advanced Maximum MTU 1500 9000
Table 34: Distributed Switch Settings
Details for storage 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 Disk Format v5 Default

Caching: 1 x Intel S3700 DC 400 GB SSD
Capacity: 5 x Intel S3700 DC 400 GB SSD
Table 35: Storage Specifications
Appendix D: Test Plan

This appendix includes sections for all three of the services described in this reference architecture:
• Active/Active Horizon 7 Service Failover Test/Recovery Plan
• Active/Passive Horizon 7 Service Failover Test/Recovery Plan
• Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster
Active/Active Horizon 7 Service Failover Test/Recovery Plan

In the test plan depicted in Figure 41, 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.

DMZ DMZ
VMware VMware
Composer Composer
Horizon Horizon
Events Events
Services Services

iSCSI RDM RDM iSCSI

Storage Replication
Figure 41: 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 Log in with user S1-sales1 to Site 1. User logs in successfully and As expected
login in Site 1 Change the desktop background. the desktop change is
written to the background.
0.2 Test user Log in with user S2-sales1 to Site 2. User logs in successfully and As expected
0.3 Identify Select the site with the master-of- Candidate is identified for the Site 1 identified
candidate operations domain controller/SQL failover test.
site to bring Server Always On primary role, in order
offline to simulate a full site failover.
0.4 Prepare Prepare a time device to record the Time source starts recording As expected
timing to time it takes for failover of services from time when failover occurs.
record the failed site to the remaining site.
failover
Table 36: 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.
1.1 Site failure Power is killed to all ESXi servers in ESXi servers in Site 1 – Desktop
simulation Site 1: three servers for management management cluster and all session for user
initiated VMs, and three servers for hosting management VMs are offline. S1-sales1
desktops. ESXi hosts in Site 1 – desktop terminated
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.
1.2 Verify user Verify that the user experience of the The S2-sales1 user continues As expected
desktop Site 2 user, who is logged in to Site 2, is to work as normal
session to the same as before the failure of Site 1. (AppStacks, VMware Identity
Site 2 (Test Manager, User Environment
0.2) is still Manager configuration and
operating user data).
normally
2 Verify Site 1 User S1-sales1 logs in to Site 2. The S1-sales1 user can log in As expected
user can log and get a temporary profile
in to Site 2 and User Environment
Manager configuration
settings.
No VMware Identity Manager
features are available due to
offline SQL.
3.0 Point the Modify the global load balancer or DNS For more details about this As expected
global load record to point to the load balancer in process, see Failover to
balancer to the secondary data center. Secondary Data Center, in
the load Installing and Configuring
balancer in VMware Identity Manager.
Site 2 for
VMware
Identity
Manager
3.1 Always On Move the primary role to a node on the The Always On availability As expected
failover for SQL Server Always On cluster in Site 2, group comes online in Site 2
VMware for the VMware Identity Manager and can be accessed through
Identity protection groups. the VMware Identity Manager
Manager JDBC connection.
3.2 VMware Use the VMware Identity Manager The sync connector in Site 2 As expected
Identity administration console to select a sync will sync users and groups
Manager connector in Site 2. from the enterprise directory
Sync to the VMware Identity
Connector Manager Service in Site 2.
3.3 VMware VMware Identity Manager recognizes After a few minutes, VMware As expected
Identity the Always On availability group listener Identity Manager should be
Manager has changed. functional again. Verify by
availability logging in as the admin user,
verification and change an entitlement
on an existing resource.
3.4 App Volumes Because App Volumes uses separate The S1-sales1 user can log in As expected
Manager is standalone databases in each site, no and get the correct
unaffected failover action is required. AppStack because AppStack
entitlements are replicated
between sites.
3.5 Active Site 1 had the master-of-operations Seizing of all roles successful As expected
Directory domain controller. Necessary to seize and the DFS management
FSMO roles FSMO roles for the domain controller in console can access the
Site 1. domain-based namespace
hosted fileservers in Site 1.
3.6 DFS Remove unavailable referral points from The \\vmweuc.com\data\ As expected
replication Site 2 and add in a copy from Site 1. s1-user-data folder can be
written to.
4 Verify user Log in again with user S1-Sales1 (Step 2) DFS referral is available, and As expected
login and verify that the user receives a the user receives a profile.
profile.
Table 37: 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.
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.
Site1 User: S1-Finance1

DMZ DMZ
VMware VMware
Composer Composer
Horizon Horizon
Events Events
Services Services

iSCSI RDM RDM iSCSI

Storage Replication
Figure 42: Active/Passive Horizon 7 Service Failover Test/Recovery Plan
0.1 Test user Log in with user S1-Finance1 to Site 1. User logs in successfully and As expected
0.2 Test user Log in with user S2-Finance1 to Site 2. User logs in successfully and As expected
0.3 Identify Select the site with master-of- Candidate is identified for the Site 1 identified
candidate operations domain controller/SQL failover test.
site to bring Server Always On primary role, in order
offline to simulate full site failover.
record the failed site to the remaining site.
failover
Table 38: 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.
1.1 Site failure Power is killed to all ESXi servers in ESXi servers in Site 1 – Desktop
simulation Site 1: three servers for management management cluster and all session for user
initiated VMs, and three servers for hosting management VMs are offline. S1-finance1
desktops. ESXi hosts in Site 1 – desktop terminated
cluster and all virtual
desktops are unavailable.
Site 1 are killed. Virtual
desktop sessions to linked-
clone and full-clone desktops
in Site 1 are unaffected.
1.2 Verify user Verify that the user experience of the The S2-Finance1 user As expected
desktop Site 2 user, who is logged in to Site 2, is continues to work as normal
session to same as before the failure of Site 1. (AppStacks, VMware Identity
Site 2 (Test Manager, User Environment
0.2) is still Manager configuration and
operating user data).
normally
2 Verify Site 1 User S1-Finance1 logs into Site 2. The user gets an error and As expected
user can log cannot launch a desktop.
in to Site 2
3.0 Point the Modify the global load balancer or DNS For more details about this As expected
global load record to point to the load balancer in process, see Failover to
balancer to the secondary data center. Secondary Data Center, in
the load Installing and Configuring
balancer in VMware Identity Manager.
Site 2 for
VMware
Identity
Manager
3.1 Always On Move the primary role to a node on the The Always On availability As expected
failover for SQL Server Always On cluster in Site 2, group comes online in Site 2
VMware for the VMware Identity Manager and can be accessed through
Identity protection groups. the VMware Identity Manager
Manager JDBC connection.
3.2 Mware Use the VMware Identity Manager The sync connector in Site 2 As expected
Identity administration console to select a sync will sync users and groups
Manager connector in Site 2. from the enterprise directory
Sync to the VMware Identity
Connector Manager Service in Site 2.
3.3 VMware VMware Identity Manager recognizes After a few minutes, VMware As expected
Identity the Always On availability group listener Identity Manager should be
Manager has changed. functional again. Verify by
availability logging in as the admin user,
verification and change an entitlement
on an existing resource.
3.4 App Volumes Because App Volumes uses separate The S1- Finance1 user can log As expected
Manager is standalone databases in each site, no in and get the correct
unaffected failover action is required. AppStack because AppStack
entitlements are replicated
between sites.
3.5 Active Site 1 had the master-of-operations Seizing of all roles is As expected
Directory domain controller. Necessary to seize successful and the DFS
FSMO roles FSMO roles for the domain controller in management console can
Site 2. access the domain-based
namespace hosted file
servers in Site 2.
3.6 DFS Remove unavailable referral points from The \\vmweuc.com\data\ As expected
Replication Site 2 and add in a copy from Site 1. s1-user-data folder can be
written to.
3.7 Recover Copy the latest snapshot on the Site 2 The snapshot is copied to a As expected
writable all-flash array from source Site 1 all-flash new volume, COPY-S1-
volumes array. Create a new volume and present writablevolumes-x.
array it to the Site 2 host group of ESXi
snapshot servers.
3.8 Add storage Scan the storage adapters on the ESXi The copy of the Site 1 As expected
to Site 2 ESXi hosts in Site 2. writable volumes datastore is
cluster Add a new datastore and resignature it. presented to all ESXi hosts in
Label the vSphere datastore COPY-S1- Site 2 and mounted
writablevolumes-x. successfully.
3.9 App Volumes Log in to the App Volumes Manager All assignments to the As expected
Manager console. Disable assignments to the writable volumes datastore in
– Disable old S1-writablevolumes-x datastore. failed Site 1 are successfully
Site 1 writable disabled.
volumes
reference
3.10 App Volumes Log in to the App Volumes Manager All assignments to writable As expected
Manager console. Import the COPY-S1- volumes are successfully
– Import new writablevolumes-x datastore. added, but to the new valid
COPY-Site1- location.
writable
volumes-x
datastore
4 Horizon 7 Log in to the Horizon Administrator Override succeeds. As expected

CPA home console and set the home site override
site override on the Finance GE to S1-Finance > Site
for Site 1 user 2.
groups
5 Verify user Log in again with user S1-Finance1 (Step User receives User As expected
login for Site 2) and verify that the user is able to Environment Manager profile,
1 user to Site work as before the site failure writable volume, and VMware
2 Identity Manager portal
access.
Table 39: Active/Passive Test Results
Active/Passive Horizon 7 Service Failover Test/Recovery Plan 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 into full-clone virtual desktops when the failure occurred.
Fault Domain A Fault Domain C Fault Domain B
Storage
Witness Appliance
vSAN Stretched Cluster
Site 1 Site 3 Site 2

(Active) (Witness) (Active)
Figure 43: Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster
0.1 Identify Select the site where all management Management machines are Site 1 selected
candidate VMs are running. pinned to the data site using
site for DRS affinity rules.
simulated
failure
0.2 Verify virtual Check full-clone pool deployed across Full-clone virtual desktops As expected
desktops are desktop vSAN stretched cluster. are available for login across
ready for test both sites.
0.3 Verify vSAN Verify that vSAN is operating effectively, vSAN reports no issues with As expected
fault domain, with no errors. configuration. HA and DRS
HA, and DRS Also, verify HA and DRS are enabled settings are optimal.
settings and configured correctly to support
vSAN site failover.
0.4 Users logged Log in test users to full-clone virtual Users are logged in to full- As expected
into virtual desktops; one in each of Site 1 and clone virtual desktops in
desktops Site 2. Site 1 and Site 2.
record Site 1 to Site 2.
failover
Table 40: Active/Passive on vSAN Stretched Cluster Preliminary Tests
The following list of tests includes descriptions of occurrences during a stretched vSAN active/passive
service failover, the recovery steps required, and the test results.
1.0 Site failure Power is killed to all ESXi servers in The ESXi server that hosts As expected
simulation Site 1: one server for management VMs, the management VMs goes
initiated three servers for hosting desktops. offline. Full-clone virtual
desktops in Site 1 are
unavailable. Virtual desktop
sessions to full-clone
desktops in Site 1 are killed.
full-clone desktops in Site 2
are unaffected.
2.0 vSphere High HA starts up management VMs HA restarts the management HA restarts
Availability (vCenter Server, AD domain controller, VMs within 30 seconds. management
fails the SQL Server, Connection Servers, VMs within 25
management Composer, VMware vRealize® seconds.
VMs over to Operations for Horizon) in Site 2. Management
Site 2 VMs show
vSAN storage
policy non-
compliance.
2.1 vSphere High HA starts up all full-clone desktops that HA restarts virtual desktops. HA powers on
Availability had been running in Site 1 before failure all virtual
fails over occurred. desktops in 2
full-clone minutes.
desktops to Desktop VMs
Site 2 show vSAN
storage policy
non-
compliance.
Table 41: Active/Passive on vSAN Stretched Cluster Test Results
Appendix E: F5 Load-Balancing Configuration

For more information about configuring F5 solutions, refer to the following resources:
• For setting up the global load balancer: Managing Horizon Traffic Across Multiple Data Centers with
BIG-IP (used with Horizon 7 and VMware Identity Manager)
• For setting up the local, site-specific load balancers: Load Balancing VMware Identity Manager
• F5 with App Volumes Configuration Guide
Appendix F: 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)"
Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple

Sites
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.
Global Load Balancer


Group 2
Group 1
VMware VMware VMware VMware VMware VMware

Identity Identity Identity Identity Identity Identity
Manager Manager Manager Manager Manager Manager
Node 1 Node 2 Node 3 Node 4 Node 5 Node 6
SQL Server
Always On Listener
Primary Secondary
Windows Failover
Windows Failover
SQL Server SQL Server
Database Database
Cluster 2
Cluster 1
Windows Windows Windows Windows

Server 1 Server 2 Server 1 Server 2
Site 1 Site 2
Figure 44: 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 2012 R2 Standard operating
system in the VMs that run SQL Server.
• 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:
• .NET Framework 3.5 features
• Failover Clustering, including adding the Failover Clustering tools
For detailed instructions, see the Microsoft blog post Installing the Failover Cluster Feature and Tools
in Windows Server 2012. One of the tools installed is the Failover Cluster Manager, which you will use
for many of the steps that follow.
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.
a. On the domain controller, open Active Directory Users and Groups.
b. On the View menu, make sure that Advanced Features is selected.
c. Navigate to the computer object for one of the SQL Server VMs in the cluster, right-click the
object, and select Properties.
d. 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.
e. In the list of permissions, select the Full Control check box to allow full control, and click OK.

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.

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 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:
a. Select Roles to verify that the SQL Server cluster instance is running.
b. Select Nodes to verify that SQL Server on both SQL Server VMs is running.
c. 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:

a. In Site 1, open Failover Cluster Manager, right-click the cluster for Site 1, and select More Actions >
Configure Cluster Quorum Settings.
b. 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 1 only. Leave the check boxes for the VMs in Site 2 deselected.
• Select Quorum Witness page – Select Configure a file share witness, click Next, and enter the
path to the file share; for example, \\S1-FILE\Quorum. You created this file share in Step 3 of
Create a Windows Server Failover Cluster and Configure Shared Storage.
For detailed instructions, see Configure and Manage the Quorum in a Windows Server 2012
Failover Cluster.
c. To verify that the quorum is configured correctly, in Failover Cluster Manager, select Nodes and
examine the Assigned Vote column.
2. Configure quorum votes for Site 2:

a. In Site 2, open Failover Cluster Manager, right-click the cluster for Site 2, and select More Actions
> Configure Cluster Quorum Settings.
• 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.
a. Select Roles in the left pane.
b. Select the cluster instance for Site 1 in the upper portion of the Roles pane.
c. Click the Resources tab in the lower pane.
d. Scroll down and select the resource under Server Name.
e. Right-click the resource and select Properties.
f. 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.
g. Click OK on the Advanced Properties tab.

h. 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.
5. In Site 1, use SQL Server Configuration Manager to set the default port for all IPs to 1433.
a. Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left
pane, and double-click TCP/IP in the right pane.
b. In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.
c. 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.
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.

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 > 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.
T E C H N I C A L W H I T E PA P E R | 1 0 0
4. Select Data Synchronization page – Select Full.

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.

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.
6. Open a PowerShell prompt and use the following PowerShell commands to configure advanced
listener parameters.
a. 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.
b. 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.
c. Use stop-clusterresource and start-clusterresource to restart the idm-agl_idm-agl

resource so that the new settings can take effect.
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

The VMware Identity Manager virtual appliance is a very standard VMware virtual appliance, with all the
usual deployment wizard prompts. After deploying the virtual appliance, 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
––Local load balancer for Site 1
––Local load balancer for Site 2
––The three VMware Identity Manager appliances in Site 1
––The three VMware Identity Manager appliances in Site 2
––The four VMware Identity Manager connectors (two in Site 1 and two in Site 2)
• 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 Load Balancer Settings to Configure 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 the on-premises
version of Installing and Configuring VMware Identity Manager. For network port requirements, see
Note: In our example, the name of this first VMware Identity Manager appliance is s1-idm1.
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.
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.
4. Configure user attributes before changing any other configuration settings.

a. Under Identity & Access Management, click the Setup button on the right side of the screen, and
choose Change User Attributes.
b. Select the userPrincipalName and distinguishedName attributes.
c. Add the objectGUID attribute.
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.

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.
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
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 Manger 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 virtual appliances 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.

For instructions on generating the activation code, see the topic Generate Activation Code for
Connector in Deploying VMware Identity Manager in the DMZ.
2. Deploy two VMware Identity Manager Connectors in Site 1.

• 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 Install and Configure the Connector Virtual Appliance in Deploying VMware Identity Manager in
the DMZ.
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.
a. Click the link on the Setup is Complete page, which is displayed after you activate the connector.
b. On the Identity & Access Management > Directories tab, click Add Directory and select the type
of directory you want to add.
c. 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.

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
5. Enable the connectors to operate in outbound-only connection mode.

a. In Site 1, enable outbound mode for the s1-idmconn1 connector, as described in the topic Enable
Outbound Mode for the Connector in Deploying VMware Identity Manager in the DMZ.

b. In Site 1, add the s1-idmconn2 connector to the built-in identity provider that you created in the
previous step.
For instructions, see the topic Add New Connector to Built-in Identity Provider in Deploying
VMware Identity Manager in the DMZ.
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.
a. Click the link on the Setup is Complete page, which is displayed after you activate the connector.
b. On the Identity & Access Management > Directories tab, click Add Directory and select the type
of directory you want to add.
c. 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.

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 H: Setting Up VMware App Volumes for High Availability 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.
Site 1 Site 2
SQL SQL
App Volumes Managers App Volumes Managers
Database Database
vSphere vSphere
Hosts Hosts
Figure 45: App Volumes Multi-Site Using Separate Databases
To use this setup, perform the procedures in this appendix in the following order:
1. Create a Windows Server Failover Cluster in Each Site

2. Install SQL Server 2014 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 2012 R2 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.
Inside the OS, the disks are mapped to drive letters as follows.
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:
• .NET Framework 3.5 features
• Failover Clustering, including adding the Failover Clustering tools
For detailed instructions, see the Microsoft blog post Installing the Failover Cluster Feature and Tools
in Windows Server 2012. One of the tools installed is the Failover Cluster Manager, which you will use
for many of the steps that follow.
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.
Install SQL Server 2014 Stand-Alone in All VMs

You install SQL Server Stand-Alone on each VM, rather than creating a SQL Server failover cluster, as
you do for VMware Identity Manager. 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.
For more information about the setup wizard, see Install SQL Server 2014 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).
a. 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.

b. Give the SQL service account full permissions on the folder.

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.
a. Log in to the Management Studio as the sysadmin or as a user account with sysadmin privileges.
b. Connect to the SQL Server instance on the VM, right-click the Databases folder, and select New
Database.
c. 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.

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

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 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.
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 2014 Stand-Alone.

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.
The following screen shot shows the availability group with the secondary replica on the s1-sql5 VM.
3. 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.
• Permissions page – Click Customize permissions and give the WSFC cluster object full control
over the file 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:
a. Open Failover Cluster Manager on the first VM in Site 1, right-click the cluster, and select More
Actions > Configure Cluster Quorum Settings.
• 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.

For detailed instructions, see Configure and Manage the Quorum in a Windows Server 2012
Failover Cluster.
c. 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.

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:
• Choose local or remote database server to use – Select the SQL Server Always On availability
group listener that you created in Create Always On Availability Groups for App Volumes
Databases.
• Name of database catalog to use or create – Select the database that you created in Create the
App Volumes Databases and Enable Availability Groups for the Clusters.
Important: If you see an error message such as the following one, it means you need to enable
named pipes, as described in Step 1.
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 Appendix F: PowerShell Script for Replicating App
Volumes Application Entitlements.
Appendix I: Configuration Procedures for a Clustered App Volumes Database

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).
Note: Because most of the procedures for creating a clustered database for App Volumes are so similar
to those for the VMware Identity Manager clustered database, the links in Steps 1, 2, 3, and 5 in the
following list go to procedures in the VMware Identity Manager appendix. For App Volumes, the only
change you need to make is to give items names that are appropriate for App Volumes, as described in
the following steps.
To create a clustered highly available App Volumes database:
1. Follow the instructions for Create a Windows Server Failover Cluster and Configure Shared Storage.
Note: When creating a file share to use as the quorum witness, if you did this procedure for VMware
Identity Manager, then create a different file share, with a different name, for App Volumes.
2. Follow the instructions for Install the SQL Server Failover Cluster.
Note: When creating the SQL Server failover cluster instances (FCIs), if you did this procedure for
VMware Identity Manager, then use different instance names for the App Volumes SQL Server FCIs.
3. Follow the instructions for Configure Cluster Quorum Settings and Possible Owners for Each Cluster
Instance.
4. Follow the instructions for Create the App Volumes Clustered Database Using Backup and Restore.
5. Follow the instructions for Create and Configure the SQL Server Always On Availability Group for
Note: When creating an availability group listener (AGL), use a different AGL name; for example, use
avm-agl, and point to the App Volumes database rather than the VMware Identity Manger database.
6. Follow the instructions for Install and Configure App Volumes Manager.
After you perform the tasks listed in the first three steps—by clicking the links in those steps to go to the
correct sections—you can continue to the next section in this appendix, Create the App Volumes
Clustered Database Using Backup and Restore.
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.
a. Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left
pane, and double-click TCP/IP in the right pane.
b. In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.
c. Set TCP Port to 1433.
7. 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.
9. Follow the instructions for Create and Configure the SQL Server Always On Availability Group for
Note: When creating an availability group listener (AGL), use a different AGL; for example, use
avm-agl, and point to the App Volumes database rather than the VMware Identity Manger 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.
Additional Resources
VMware documentation:
• VMware Identity Manager 2.x Documentation Center
• VMware Horizon 7 Documentation Center
• VMware vSphere 6.0 Documentation Center
• VMware Horizon 7 Enterprise Edition Reference Architecture
• VMware App Volumes 2.x Database Best Practices
Microsoft articles:
• Microsoft Cluster Services (MSCS)
• MSCS Cluster Support KB – When using 2012 R2 and you have moved your cluster nodes from the
default Computer container
• vSphere 6.0 MSCS configuration and support guidance
Microsoft distributed file system:

• Distributed File System Namespace (DFSN) and Distributed File System Replication (DFSR) Best
practice guidance
• Microsoft support statement in terms of DFSN/DFSR and profile/user data
• Namespace hosting and data placement
• Read-Only replication
General:
Defining GPO security settings for IE trusted zones with VMware Identity Manager
F5 technical articles:
• Load Balancing VMware Identity Manager
• Load Balancing App Volumes Manager instances
About the Authors

Graeme Gordon is a Senior Staff End-User-Computing (EUC) Architect in End-User-Computing
Technical Marketing, VMware.
Donal Geary is a Reference Architect Engineer in End-User-Computing Technical Marketing, VMware.
Caroline Arakelian is a Senior Technical Marketing Manager, End-User-Computing Technical Marketing,

VMware.
Jim Yanik is a Senior Manager, End-User-Computing Technical Marketing, VMware.
Rasmus Jensen co-authored the original version of this white paper. Rasmus is now a Lead Systems
Engineer, End-User-Computing Technical Marketing, VMware.
Matt Coppinger co-authored the original version of this white paper. Matt is the Director of Technical
Marketing and Enablement, End-User Computing, VMware.
To comment on this paper, contact VMware End-User-Computing Technical Marketing at

euc_tech_content_feedback@vmware.com.
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com
Copyright © 2017 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed
at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be
trademarks of their respective companies. Item No: VMW-TWP-HOR7ENTEDMSREFARCH-USLTR-20171116-WEB
11/17

Vmware Horizon 7 Enterprise Edition Reference Architecture Multi Site

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Vmware Horizon 7 Enterprise Edition Reference Architecture Multi Site

Hochgeladen von

Copyright:

Verfügbare Formate

TECHNICAL WHITE PAPER – NOVEMBER 2017

VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Business Drivers and Use Cases Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Recovery Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Multi-Site Architecture Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Horizon 7 Component Design with a Disaster Recovery Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

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

Environment Infrastructure Dependencies Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Horizon 7 Components Required for Recovery Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Reference Architecture Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

vSAN Stretched Cluster Active/Passive Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Appendix B: Active/Active and Active/Passive Services with Replicating

Appendix C: Infrastructure Design for the Stretched vSAN Active/Passive Service . . . . . . . . . . . . . 76

Appendix D: Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Appendix E: F5 Load-Balancing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements. . . . . . . . . . 90

Appendix I: Configuration Procedures for a Clustered App Volumes Database . . . . . . . . . . . . . . . . . 131

Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Service Desktop Pool/ Apps Profile

User Apps Linked Clone AppStacks Volume Config Settings Shares

Attached Apps Active

User Apps Active

Figure 1: Example Service Blueprint

USE CASE AND DESCRIPTION SOLUTION

Table 1: Use Case Overview

This paper is intended to help organizations—IT architects, consultants, and administrators—involved in

Figure 2: Reference Architecture Design Methodology

JMP – Next-Generation Desktop and Application Delivery Platform

VMware Reference Architectures

VMware reference architectures offer customers:

Business Drivers and Use Cases Definition

Meeting Business Requirements with Multi-Site Horizon 7 Deployments

BUSINESS DRIVER COMMENTS

BUSINESS DRIVER COMMENTS

Table 2: Meeting Business Requirements with Multi-Site Horizon 7 Deployments

Use Case Recovery Requirements

USE CASE AND DESCRIPTION

Active/Passive • User normally works in a single office location.

Table 3: Disaster Recovery Classifications

Recovery Service Definitions

The following functionality is used across the use cases.

Single sign-on, SaaS applications VMware Identity Manager

Infrastructure platform VMware vSphere

Virtual desktops and RDSH-remoted apps VMware Horizon 7

Application deployment VMware App Volumes

Table 4: Recovery Requirements

IT settings User Environment Manager IT configuration is replicated to another data

Mobile access Unified Access Gateway, Blast Extreme

Table 5: Active/Active Service Requirements

Active/Active Service Blueprint

Service Desktop Pool/ Apps Profile

Linked Clone Config Settings Shares

Windows OS Master VM AppStacks (Optional)

Figure 3: Active/Active Service Blueprint

Active/Active App Volumes Blueprint

Service Apps App Database

Attached Apps Active

Figure 4: Active/Active App Volumes Option Blueprint

Active/Active Profile Blueprint

Service Profile File Server Shares

Desktop / RDSH Clone

Config Settings Shares Share Share Share

Config Settings Shares