Select Page

Horizon and Workspace ONE Architecture for 250k Users Part 1

Disclaimer: This article is based on my own thoughts and experience and may not reflect a real-world design for a Horizon/Workspace ONE architecture of this size. The blog series focuses only on the Horizon or Workspace ONE infrastructure part and does not consider other criteria like CPU/RAM usage, IOPS, amount of applications, use cases and so on. Please contact your partner or VMware’s Professional Services Organization (PSO) for a consulting engagement.

To my knowledge there is no Horizon implementation of this size at the moment of writing. This topic, the architecture and the necessary amount of VMs in the data center, was always important to me since I moved from Citrix Consulting to a VMware pre-sales role. I always asked myself how VMware Horizon scales when there are more than only 10’000 users.

250’000 users are the current maximum for VMware Horizon 7.8 and the goal is to figure out how many Horizon infrastructure servers like Connection Servers, App Volumes Managers (AVM), vCenter servers and Unified Access Gateway (UAG) appliances are needed and how many pods should be configured and federated with the Cloud Pod Architecture (CPA) feature.

I will create my own architecture, meaning that I use the sizing and recommendation guides and design a Horizon 7 environment based on my current knowledge, experience and assumption.

After that I’ll feed the Digital Workspace Designer tool with the necessary information and let this tool create an architecture, which I then compare with my design.

Scenario

This is the scenario I defined and will use for the sizing:  

Users: 250’000
Data Centers: 1 (to keep it simple)
Internal Users: 248’000
Remote Users: 2’000
Concurrency Internal Users: 80% (198’400 users)
Concurrency Remote Users: 50% (1’000 users)

Horizon Sizing Limits & Recommendations

This article is based on the current release of VMware Horizon 7 with the following sizing limits and recommendations:

Horizon version: 7.8
Max. number of active sessions in a Cloud Pod Architecture pod federation: 250’000
Active connections per pod: 10’000 VMs max for VDI (8’000 tested for instant clones)
Max. number of Connection Servers per pod: 7
Active sessions per Connection Server: 2’000
Max. number of VMs per vCenter: 10’000
Max. connections per UAG: 2’000 

The Digital Workspace Designer lists the following Horizon Maximums:

 

Horizon Maximums Digital Workspace Designer

Please read my short article if you are not familiar with the Horizon Block and Pod Architecture.

Note: The App Volumes sizing limits and recommendations have been updated recently and don’t follow this rule of thumb anymore that an App Volumes Manager only can handle 1’000 sessions. The new recommendations are based on “concurrent logins per second” login rate:

New App Volumes Limits Recommendations

 

Architecture Comparison VDI

Please find below my decisions and the one made by the Digital Workspace Designer (DWD) tool:

Horizon ItemMy DecisionDWD ToolNotes
Number of Users (concurrent)199'400199'400
Number of Pods required2020
Number of Desktop Blocks (one per vCenter)100100
Number of Management Blocks (one per pod)2020
Connection Servers required100100
App Volumes Manager Servers802024+1 AVMs for every 2,500 users
vRealize Operations for Horizonn/a22I have no experience with vROps sizing
Unified Access Gateway required22
vCenter servers (to manage clusters)20100Since Horizon 7.7 there is support for spanning vCenters across multiple pods (bound to the limits of vCenter)

Architecture Comparison RDSH

Please find below my decisions* and the one made by the Digital Workspace Designer (DWD) tool:

Horizon ItemMy DecisionDWD ToolNotes
Number of Users (concurrent)199'400199'400
Number of Pods required2020
Number of Desktop Blocks (one per vCenter)20401 block per pod since we are limited by 10k sessions per pod, but only have 333 RDSH per pod
Number of Management Blocks (one per pod)2020
Connection Servers required100100
App Volumes Manager Servers142024+1 AVMs for every 2,500 users/logins (in this case RDSH VMs (6'647 RDSH totally))
vRealize Operations for Horizonn/a22I have no experience with vROps sizing
Unified Access Gateway required22
vCenter servers (to manage resource clusters)440Since Horizon 7.7 there is support for spanning vCenters across multiple pods (bound to the limits of vCenter)

*Max. 30 users per RDSH

Conclusion

VDI

You can see in the table for VDI that I have different numbers for “App Volumes Manager Servers” and “vCenter servers (to manage clusters)”. For the amount of AVM servers I have used the new recommendations which you already saw above. Before Horizon 7.7 the block and pod architecture consisted of one vCenter server per block:

Horizon Pod vCenter tradtitional

That’s why, I assume, the DWD recommends 100 vCenter servers for the resource cluster. In my case I would only use 20 vCenter servers (yes, it increases the failure domain), because Horizon 7.7 and above allows to span one vCenter across multiple pods while respecting the limit of 10’000 VMs per vCenter. So, my assumption is here, even the image below is not showing it, that it should be possible and supported to use one vCenter server per pod:

Horizon Pod Single vCenter

RDSH

If you consult the reference architecture and the recommendation for VMware Horizon you could think that one important information is missing:

The details for a correct sizing and the required architecture for RDSH!

We know that each Horizon pod could handle 10’000 sessions which are 10’000 VDI desktops (VMs) if you use VDI. But for RDSH we need less VMs – in this case only 6’647.

So, the number of pods is not changing because of the limitation “sessions per pod”. But there is no official limitation when it comes to resource blocks per pod and having one connection server for every 2’000 VMs or sessions for VDI, to minimize the impact of a resource block failure. This is not needed here I think. Otherwise you would bloat up the needed Horizon infrastructure servers and this increases operational and maintenance efforts, which obviously also increases the costs.

But, where are the 40 resource blocks of the DWD tool coming from? Is it because the recommendation is to have at least two blocks per pod to minimize the impact of a resource block failure? If yes, then it would make sense, because in my calculation you would have 9’971 RDSH users sessions per pod/block and with the DWD calculation only 4’986 (half) per resource block.

*Update 28/07/2019*
I have been informed by Graeme Gordon from technical marketing that the 40 resources blocks and vCenters are coming from here:

App Volumes vCenters per Pod

I didn’t see that because I expect that we can go higher if it’s a RDSH-only implementation.

App Volumes and RDSH

The biggest difference when we compare the needed architecture for VDI and RDSH is the number of recommended App Volumes Manager servers. Because “concurrent logins at a one per second login rate” for the AVM sizing was not clear to me I asked our technical marketing for clarification and received the following answer:

With RDSH we assign AppStacks to the computer objects rather than to the user. This means the AppStack attachment and filter drive virtualization process happends when the VM is booted. There is still a bit of activity when a user authenticates to the RDS host (assignment validation), but it’s considerably less than the attachment process for a typical VDI user assignment.

Because of this difference, the 1/second/AVM doesn’t really apply for RDSH only implementations.

With this background I’m doing the math with 6’647 logins and neglect the assignment validation activity and this brings me to a number of 4 AVMs only to serve the 6’647 RDS hosts.

Disclaimer

Please be reminded again that these are only calculations to get an idea how many servers/VMs of each Horizon component are needed for a 250k user (~200k CCU) installation. I didn’t consider any disaster recovery requirements and this means that the calculation I have made recommend the least amount of servers required for a VDI- or RDSH-based Horizon implementation.

VMware Mirage – Alternatives

As some of you know Mirage was (and still is) a revolutionary technology at the time Wanova released it in 2011 and in 2012 Mirage became part of VMware.

VMware Mirage is used by customers for their desktop image management and for backup and recovery requirements.

VMware Mirage provides next-generation desktop image management for physical desktops and POS devices across distributed environments. Automate backup and recovery and simplify Windows migrations.

Mirage is and was the solution for certain use cases and solved common desktop challenges. Therefore not all customers are happy that Mirage reaches end of support (EOS) on June 30, 2019. 🙁

But why is VMware Mirage being removed from support?

Well, the answer is very simple. Today, the market is heading in two directions – it’s all about the applications and end-user devices (called the Digital Workspace). That’s why customers should move or are somehow forced to move to a Unified Endpoint Management solution which is considered to be “the” Windows desktop management solution of the future. The future of Windows is apparently cloud based and Mirage has not been designed or architected for this.

What are the alternatives?

VMware has no successor or product which can replace all of the features and functions Mirage provided, but Workspace ONE is the official alternative solution when it comes to Windows desktop management.

There are really a lot of use cases and reasons why customers in the past decided to choose Mirage:

  • Reduce Management Complexity (e.g. single management console)
  • Desktop Backup and Recovery (automated and continuous system or user data backup)
  • Image Management (image layering)
  • Patch Management
  • Security & Compliance (auditing and encrypted connections)
  • Simple Desktop OS Migrations (e.g. Windows 7 to Windows 10 migrations)

VMware Mirage really simplified desktop management and provides a layered approach when it comes to OS and applications rollouts. Customers also had the use case where the physical desktop not always was connected to the corporate network and this is a common challenge IT department were facing.

The desktop images are stored in your own data center with secure encrypted access from all endpoints. You can also customize access rights to data and apps.  Even auditing capabilities are available for compliance requirements.
And the best and most loved feature was the possibility for a full system backup and recovery!

IT people love Mirage because it was so simple to restore any damaged and lost device to the most recent state (snapshot).

For branch offices where no IT was onsite Mirage was also the perfect fit. An administrator just can distribute updates or Windows images to all remote laptops and PCs without any user interaction – maybe a reboot was now and then required. But that’s all!

In case of bandwidth problems you could also take advantage of the Branch Reflector technology which ensured that one endpoint downloads images update and then distribute it locally to other computers (peers), which saved relieved the WAN connection drastically.

Can WorkspaceONE UEM replace Mirage?

From a technical perspective my opinion is definitely NO. WorkspaceONE has not the complete feature set compared to Mirage when it is about Windows 10 desktop management, but both are almost congruent I have to say.

I agree that WorkspaceONE (WS1) is the logical step or way to “replace” Mirage, but this you have to know:

  • WS1 cannot manage desktop images for OS deployments. Nowadays, it is expected that a desktop is delivered pre-staged with a Windows 10 OS from the vendor or that your IT department is doing the staging for example with WDS/MDT.
  • WS1 has no backup and recovery function. If you use Dell Factory Provisioning then you can go back to a “restore point” where all of your pre-installed and manually installed applications get restored after a device wipe let’s say for example. But if the local hard disk has a failure and this restore partition is gone, then you have to get your device or hard disk replaced. Without Dell Factory Provisioning this means that IT has, again, still to deploy the desktop image with WDS/MDT.

For some special use cases it is even necessary to implement VMware Horizon, User Environment Manager, OneDrive for Business etc, but even then WS1 is a good complement since it can also be used for persistent virtual desktops!

As you can see a transition from Mirage to WS1 is not so easy and the few but most important differences are the reasons why customers and IT admins are not so amused about the EOS announcement of VMware Mirage.

VCAP7-DTM Design Exam, Part 12

I failed the VCAP7-DTM Design exam, but expected it and the first try of the exam showed me what stuff I need to learn better and where my weaknesses are. Let me tell you about my exam experience.

I arrived on time at the PearsonVUE test center, but they had PC problems and so I had to wait first for 30min until I could start the exam. The timer showed me that I have two hours for the 60 questions. The most of the time I was guessing and eliminating the obviously wrong answers and so I was through 50% of the questions of 50% of the time. If you would know a little bit more than I do and you work/worked with all the products on a daily basis, I would say that the exam is a piece of cake!

Nevertheless, I answered all 60 questions 15 minutes before the timer ended, but I didn’t review any of them, because I knew that I still wouldn’t have the better or correct answers. This may sound to you like I failed with a score of 0, but no. I had 252 of the 300 needed points and this is a sign for me that I just need to improve my weak spots and the topics I didn’t check during my preparation time.

Today I’m going to travel to VMware Airwatch in Milton Keynes (UK) for my VMware Workspace ONE: Deploy and Manage [V9.x] training which starts tomorrow. And I have to prepare a presentation for a roadshow with five events where I will be the speaker of a 30min slot. This means no time for studying yet.

But I’m lucky that I still got a seat at the Digital Workspace Livefire Architecture & Design training taking place in three weeks. This will be last part of my preparation for the retake which I planned for 23rd November 2018. But first I have to wait for my new exam voucher. 🙂

I cannot tell you which topics/technologies or questions were asked during the exam, but I can assure you that I didn’t expect some of the questions – they were just craaaaazy or about veeeery old stuff.

This is also one of my problems. You have to study things which are not valid anymore for the today’s product version or implementation. In a few cases the configuration limits or some parts of an architecture have changed.

So, I read the exam blueprint again and checked some of the attached URLs and document links again. In my opinion the following products and versions you should know for the exam:

  • Horizon 7.2
  • VMware Identity Manager 2.8
  • App Volumes 2.12
  • User Environment Manager 9.1
  • ThinApp 5.1
  • Unified Access Gateway 2.9
  • vSAN 6.2
  • vSphere 6.5
  • vRealize Operations 6.4
  • Mirage 5.x

So, this was my exam experience of the VCAP7-DTM Design exam and my advices after. It is totally okay to fail, because it will just help you if you are not prepared well enough or just went to early for your first shot.

My last advice: Use the note board for the difficult answers and topics you have no clue of. If you have enough time, reviewed your answers and you are ready to end the exam, memorize all your notes. Just in case you didn’t pass, you now have the notess in your mind and could transfer themto your personal notebook. This is totally legal and really helpful! 🙂

Good luck to you if you take the exam. I have another four weeks now to fill the gaps. 🙂 See if I passed or not.

VCAP7-DTM Design Exam, Part 11

My last article was about the Horizon reference architecture and four weeks have already passed since then. My VCAP7-DTM Design exam is scheduled for October 18 – that’s in five days!

I haven’t opened my books the last three weeks, because I think it’s important to take a break and get some distance of your books and documents, which allows you to understand things better and faster and see connections between things you haven’t seen before. And another reason was my pregnant wife who delivered our beautiful daughter on October 4! 🙂

I started from scratch and repeated reading all my training material and PDF documents.

Infrastructure Assessment

To design a Horizon 7 environment you have to follow a process to work out a VMware EUC solution that meets the customer’s requirements and follow the VMware design guidelines and use the reference architectures while considering customer constraints. It is very important that all customer business drivers and objectives are clearly defined. Then you will start to gather and analyze the business and application requirements and document the design requirements, assumptions, risks and constraints. For example, if you talk about technical requirements with your customer, the following categories should be covered:

  • Virtualization infrastructure and data center hardware
  • Storage
  • Networking
  • Security
  • Application
  • Directory services and GPOs
  • Monitoring and performance
  • Management
  • Profile management
  • Peripherals
  • Printing
  • Backup and recovery (business continuity)
  • Endpoints
  • Users/Use cases: correlation between hardware, software and user requirements)
  • High availability
  • Licensing

With the information from the assessment phase, the design work can begin and you create the conceptual design before you head over to create a logical design. Advice: Minimize risks and keep things simple!

Horizon Logical Design

The logical design (high level design) follows the conceptual design and defines how to arrange components and features. It is also useful to understand and evaluate the infrastructure design. The easiest and most common way to create a logical design is the use of architecture layers. Each layer contains one or more components and has functional and technical inter-dependencies:

  • User Layer
    • Self-Service portal
    • Authentication
  • Application Layer
    • Application deployment and type (cloud-based, locally installed, enterprise apps etc.)
  • Desktop Layer
    • Use cases and type of user
    • Scalability and multi-site
    • Desktop types and OS
  • Virtualization Layer
    • Hypervisor
    • Compute, network and storage
    • Graphics
  • Hardware Layer
    • Server
    • Network and storage
  • Management Layer
    • Patching
    • Monitoring
    • Cluster and resources
    • Capacity
    • Backup
  • Security Layer
    • Internal and external
    • Authentication and authorization
    • Policies
    • Antivirus etc.

A Horizon logical design could look like this:

Horizon Logical Architecture

If you need to write down use cases and their attributes, here an example:

AttributeDefinition
Business UnitFinance
User ClassificationTask Worker
Time of use07:00-18:00, mo-fr
User deviceThin Client
PeripheralsNone
ConnectivityLAN
PersistencyNon-persistent desktop
Data centerBasel DC1
AuthenticationWindows Login

Horizon Block and Pod Design

In part 4 I covered this topic how to use a repeatable and scalable approach to design a large scale Horizon environment.

Horizon Component Design

To have a complete design you must define the amount and the configuration of Horizon components required for your environment. You have to include certain design recommendations and design the configuration for Horizon components for your use cases. These are some required infrastructure components:

  • VMware Identity Manager
    • Load Balancing for resiliency and scale
    • Database required
    • Connection to Active Directory
    • SaaS-based implementation recommended
    • Approx. 100’000 users per virtual appliance
  • vCenter Server
    • Up to 10’000 virtual machines per vCenter
      • Recommendation: 2’000 desktops per vCenter
    • Dedicated vCenter Server instance per resource block
    • Database required
  •  Connection Server
    • Up to 2’000 sessions per Connection Server (4’000 tested limit)
    • Database required
    • Install at least one Replica Server for redundancy
    • Max. 7 Connection Servers per pod
      • Load-balanced
    • Max. 10’000 sessions per pod recommended
    • Cloud Pod Architecture
      • Max. 175 Connection Servers
      • Max. 120’000 sessions
      • Max. 5 sites
    • View Composer needed?
      • Database required
  • Security Server (not recommended anymore, use UAG)
    • Should not be member of AD domain
    • Load Balancing
    • Should be hardened Windows server (placed in DMZ)
    • 1:1 mapping with Connection Servers
  • Unified Access Gateway (UAG)
    • Virtual appliance (placed in DMZ) based on linux (Photon OS)
    • Scale-out is independent of Connection Server
    • Does not need to be paired with a single Connection Server
    • Load Balancing

Pool and Desktop Configuration

  • Desktop Configuration
    • Specification (OS, apps, RAM, disk, network)
    • Operating System Builds (master images)
      • Image Optimization (use OSOT)
    • Application Deployment
  • Pool Configuration
    • Map use cases to pools
    • Pool Design
      • Type
      • User Assignment
      • User Experience Settings
      • Pool Size
      • Performance
      • AD Groups
    • Pool Types
      • Automated Desktop Pool
      • Manual Desktop Pool
      • RDS Desktop Pool
    • Desktop Persistence
      • Dedicated
      • Floating
    • Desktop Pool Definition
      • Full Clones
      • Linked Clones (Composer)
      • Instant Clones
    • Remote Display Protocol
      • Blast (H.264 capable, TCP/UDP)
      • PCoIP (UDP)
      • RDP (TCP)
    • 3D Rendering (Horizon 7.2)
      • Nvidia GRID vCPU (shared GPU hardware acceleration)
      • Hardware
      • Virtual Shared Graphics Acceleration (vSGA)
      • Virtual Dedicated Graphics Acceleration (vDGA)
      • Soft 3D (Software-accelerated graphics)
      • AMD Multiuser GPU using vDGA
      • Pool must use PCoIP or Blast
      • (Live vMotion of vGPU VMs is supported since Horizon 7.6)

VMware Infrastructure Design

You need to map the Horizon desktop building block and the Horizon management building block to vSphere and identify factors and design decisions to figure out the sizing of the VMware infrastructure.

  • ESXi Hosts
    • ESXi Host Specifications
    • CPU requirements
    • Memory requirements
    • Storage requirements (specially if using vSAN)
    • Host density (max. VMs/desktops per ESXi host)
    • vSphere cluster requirements (HA and DRS)
  • Storage
    • Storage performance and desktop I/O requirements
      • Types of disks (SSD, SAS, SATA)
      • Dedicated array for VDI
      • FC/Network connectivity
    • Shared Storage recommended
      • vSAN recommended for Horizon desktops
      • Datastore sizing
    • Storage requirements depending on pool configuration
      • E.g. Instant Clones use significantly less storage

Network and Security Design

The network design should be simple, scalable and secure. More secure does not always mean less “user simple” (user experience), but it does less risks and does not imply more complexity.

  • Network
    • UAG appliance load-balanced in DMZ
    • Connection Servers load-balanced inside corporate firewall
      • Security Server would be placed in DMZ if no UAG
    • Know the key firewall considerations for Horizon 7
    • Bandwidth requirements for different types of users
    • LAN considerations
    • WAN considerations (e.g. latency, WAN optimization)
    • Optimization/Policies for display protocols (LAN/WAN)
    • vSphere networking requirements
      • Separate networks for management, VMs, vMotion etc.
      • Physical redundancy
      • Use vSphere Distributed Switch
  • Security
    • Secure your desktops (lockdown, GPOs, UEM)
    • Use secure client connections (secure gateways/tunnel)
    • Use Unified Access Gateway for remote access (use three NICs)
      • View Security Server (if needed)
    • User authentication method from internal and external
      • Two Factor Authentication for external connections
    • Restrict access (tags, AD groups)
    • Use NSX for micro segmentation
    • Install signed SSL certificates

Session Management

Our objective of a Horizon implementation is to provide better support to users than the physical solution. Session management is an aspect of this. Configuration and different settings on the sessions or client device are essential for a smooth user experience.

  • Personalization
    • Profile Management (mandatory profiles recommended)
      • Use folder redirection
    • User User Environment Manager (UEM) for Windows and application settings
      • Personalization
      • Application Configuration Management
      • User Environment Settings
      • Application Migration
      • Dynamic Configuration
  • Just-in-Time Management (JMP) Platform
    • App Volumes (real-time application delivery)
    • Instant Clones (rapid desktop provisioning)
    • User Environment Management (contextual policy management)
  • End-User Desktop Maintenance
    • Maintaining linked-clone desktops with Composer
      • Recompose – Patch and update desktop
      • Refresh – Revert OS disk to the base image snapshot
      • Rebalance – Management of datastore capacity
    • Manage Instant Clones by pushing an image
  • User Authentication Method
    • Smartcard
    • Two Factor Authentication (RSA, RADIUS, SAML, vIDM)
    • True SSO (short-lived certificate for Windows login process)
      • Enrollment Server required
  • ADMX template files for secure remote desktops
  • Client Devices
    • Thin clients, zero clients, fat clients, tablet and smartphones
    • Different Horizon Clients
    • Printing

Delivering Applications

The last topic I quickly repeat is about delivering and managing applications. Horizon has different methods of application delivery and the method of application delivery depends on many factors.

  • Applications in general
    • New or existing applications
    • App Lifecycle
    • Dependencies and conflicts
    • Performance and stability
  • Application delivery methods
    • RDS-hosted apps
    • ThinApp package (containerized applications, isolated from OS)
    • Natively installed Windows apps (in master image)
    • Citrix published apps
    • SaaS
    • App Volumes (real-time application delivery with LCM)
  • ThinApp
    • Isolation modes
      • Merged mode (full write access)
      • WriteCopy mode (restricted write access)
      • Full mode (no read/write access)
    • Package format
      • EXE
      • DAT (when EXE is larger than 200MB)
      • MSI

These are the topics you should cover when you prepare for the VCAP7-DTM Design exam. In addition I also read the following documents:

This is my recommendation. Within the last 8 weeks I’ve effectively studied 5 weeks for the exam. I work approx. since 4 months with Horizon products in a pre-sales role, not as a consultant. I will update you after the exam if the experience combined with learning was enough to pass! 🙂

Did I forget anything? Let me know! Jump to part 12

VCAP7-DTM Design Exam, Part 10

In part 10 of my VCAP7-DTM Design exam series we take a look at the Horizon 7 Enterprise Reference Architecture.

To be honest, I didn’t study that much the last two weeks but I checked a few documents about App Volumes, Mirage, ThinApp and User Environment Manager.

This time I would like to summarize what I have learned from the reference architecture and the VMworld 2018 session called Architecting Horizon 7 Enterprise: The Official Reference Architecture (WIN3451BUR).

I only focus on the component design part since I already covered topics like use cases, business drivers, design methodology etc.

Horizon 7

A successful deployment depends on good planning and a very good understanding of the platform. The core elements include Connection Server, Composer, Horizon Agent and Horizon Client. Part 4 to part 9 cover the Horizon 7 component design and also provide more information on the following components.

Horizon 7 Logical Architecture

Identity Manager

VMware Identity Manager (VIDM) can be implemented on-premises or in the cloud, a SaaS-based implementation. If you decide to go with the SaaS implementation, a VIDM connector needs to be installed on-prem to synchronize accounts from Active Directory to the VIDM service in the cloud.

If cloud is no option for you, you still have the possibility for the on-prem deployment and use the Linux-based virtual appliance. There is also a Windows-based installer available which is included in the VMware Enterprise Systems Connector. VMware’s reference architecture is based on the Linux appliance.

VMware Identity Manager Architecture

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

VIDM comes with an embedded PostgreSQL database, but it’s recommended to use an external database server for production deployments.

For high availability, based on your requirements, at least two VIDM appliances should be deployed behind a load balancer. After you have deployed your first appliance, you simply clone it and assign a new hostname and a new IP address.

App Volumes

As you still may know from part 8, App Volumes has two functions. The first is the delivery of applications for VDI and RDSH. The second is the provision of writable volumes to capture user-installed applications and the user profile.

app volumes architecture

For high availability, always use at least two App Volumes Managers which are load-balanced.

AppStacks are very read intensive, hence, you should place AppStacks on storage that is optimized for read operations. Writable volumes should be placed on storage for random IOPS (50/50). There reference architecture uses vSAN to provide a single highly available datastore.

For the SQL database it is recommended using an AlwaysOn Availability Group.

User Environment Manager

When User Environment Manager design decisions need to be made, you have to think about user profiles (mandatory, roaming, local) and folder redirection. As already described in part 9, VMware recommendation is to use mandatory profiles and folder redirection. Use appendix B if you need help configuring the mandatory profile.

vmware user environment manager

The first key design consideration is using DFS-R to provide high availability for the configuration and user shares. Note: Connect the management console only to the hub member when making changes. DFS-R will replicated those changes to the spoke members.

The second consideration one is using GPO loopback processing.

Unified Access Gateway

In part 6 I mentioned that a UAG is typically deployed within the DMZ.

VMware Unified Access Gateway

UAG appliances are deployed in front of the Horizon 7 Connection Servers and sit behind a load balancer. The Unified Access Gateway also runs the Content Gateway as part the AirWatch (WorkspaceONE UEM) service.

You have two sizing options during the appliance deployment:

  • Standard (2 vCPU, 4GB RAM, 2’000 Horizon server connections, 10’000 AirWatch service connections)
  • Large (4 vCPU, 16GB RAM, 2’000 Horizon server connections, 50’000 AirWatch service connections)

As you can see, the big difference here are the estimated AirWatch service connections per appliance. In production you would deploy dedicated UAG appliances for each service. Example:

  • 2 standard size UAGs appliances for 2’000 Horizon 7 sessions (n+1)
  • 3 large size UAG appliances for 50’000 devices using Content Gateway and per-App Tunnel which gives us a total of 100’000 sessions. The third appliance is for high availability (n+1)

vSphere and Physical Environment

The software-defined data center (SDDC) is the foundation that runs all infrastructure servers and components. The products and the licensing for the foundation are outside of the Horizon 7 product (except vSAN), but are required to deliver a complete solution.

And in my opinion this is what makes the whole solution so brilliant. Even I work for VMware, I would never say from the beginning that Horizon is better than XA/XD. This was also the case when I worked as a consultant for Citrix before I joined VMware in May 2018.
It depends on the requirements and use cases which need to be satisfied. That are the most important things if you choose a vendor or a specific technology. Our goal is to make the customer happy! 🙂

But I would say that VMware Horizon including WorkspaceONE is very hard to beat if you use the complete stack! But that’s another topic.

The vSphere infrastructure in the reference architecture includes vSAN and NSX. In part 5 I covered the basics of vSAN, but I think I maybe need to write a short overview about NSX and how you can use it with Horizon.

vSAN provides a hyper-converged storage optimized for virtual machines without the need for an external SAN or NAS. This means that the physical server not only provides the compute and memory resources, but also storage in a modular fashion. You can use vSAN for the management and resource block  and follow a hybrid approach for the management resources and use all-flash vSAN for the Horizon resources.

VMware vSAN

I will not cover the vSphere design, but it’s important to understand that all components are operating redundantly and that you have enough physical resources to meet the requirements.

vSphere Networking

A general recommendation is to use at least 10 GbE connections, to separate each traffic (mgmt, VM traffic, vSAN, vMotion) and make sure that each of them has sufficient bandwidth.

NSX for vSphere

NSX provides several network-based services and performs several security functions within a Horizon 7 implementation:

  • Protects VDI infrastructure
  • Protects desktop pool VM communication with applications
  • Provides user-based access control (user-level identity-based micro-segmentation)

VMware NSX for vSphere

If you want to use NSX you have to think about a NSX infrastructure design as the NSX platform adds new components (e.g. NSX manager) and new possibilities (distributed firewall and identity firewall).

The most important design consideration for Horizon 7 is the concept of micro-segmentation. In the case of Horizon 7, NSX can block desktop-to-desktop communications, which are normally not needed or recommended. Each VM can now be its own perimeter and this desktop isolation prevents threats from spreading:

NSX isolation

The Horizon 7 reference architecture of probably the best document to prepare yourself for the VCAP7-DTM exam. What do the current VCAP7-DTM certified  people say? What else needs to be covered? Jump to part 11

VCAP7-DTM Design Exam, Part 9

This is the 9th part of my VCAP7-DTM Design exam series. In part 8 I covered the creation of an application architecture design for Horizon 7. Let’s have a look at the last part of the exam blueprint, which is about session management and client devices:

Section 8 – Incorporate Endpoints into a Horizon Design
Objective 8.1 – Incorporate Session Connectivity Requirements in a Horizon End Point Design
Objective 8.2 – Incorporate Management Requirements in a Horizon End Point Client Design
Objective 8.3 – Incorporate Security Requirements in a Horizon End Point Design

User Personalization

In a Windows environment several types of user profiles are available:

  • Local Profile
  • Roaming Profile
  • Mandatory Profile

The user profile include user-specific data and application settings which allows the users to have a persistent appearance regardless which desktops a user logs in to.

As a general leading practice, it is recommended to redirect as much user data as possible to a network share. But in a Windows environment, administrators have often experienced issues with roaming profiles. From my experience, a smaller profile causes less trouble and it’s worth to spend time to have a proper profile management strategy configuration.

VMware User Environment Manager

VMware’s solution for profile management is called User Environment Manager (UEM) which is part of the Just-in-Time Management (JMP) platform. JMP is composed of the Instant Clone technology for fast desktop provisioning, App Volumes for real-time application delivery and User Environment Manager for the profile and session management.

vmware uem architecture

When I worked with Citrix products, the recommendation was to use Citrix UPM (roaming profile) and configure folder redirections via GPO.

One of the things I have learned when I joined VMware, is the different approach when it comes to profile management. VMware recommends mandatory profiles and the dynamic configuration capability of UEM:

User Environment Manager manages user and Windows settings and dynamically configures the desktop. For example, it can create drive and printer mappings, file type associations, and shortcuts. User Environment Manager can also manage and provide shortcuts to applications such as ThinApp to users.

This is Microsoft’s definition of a mandatory user profile:

A mandatory user profile is a special type of pre-configured roaming user profile that administrators can use to specify settings for users. With mandatory user profiles, a user can modify his or her desktop, but the changes are not saved when the user logs off. The next time the user logs on, the mandatory user profile created by the administrator is downloaded.

If you need to know how you create a mandatory user profile, check Microsoft’s article for Windows 10.

Very important to know when using UEM with mandatory profiles: Only the settings you have defined in UEM are kept for your sessions. Settings that you didn’t configure with UEM are not preserved and are discarded after a logout. This is called personalization.

Once you have configured your mandatory profile, the configuration in UEM is waiting:

  • Personalization (e.g. configuration files for Windows settings)
  • Application Configuration Management (initial settings for applications)
  • User Environment Settings (printer/drive mappings, environment variables, shortcuts etc.)
  • Dynamic configuration based on conditions (user, location, client device etc.)

If you need to know more about UEM, read the blog VMware User Environment Manager, Part 1: Easier, Faster Windows Logins with Mandatory Profiles, where you find information about installing and configuring VMware User Environment Manager.

Client Devices

Identify the customer’s client device characteristics and compare it with the requirements. Depending on the requirements you have the following client device options:

  • Chromebook
  • Tablets and Smartphone
  • Fat Clients (the traditional PCs or laptops including Mac)
  • Thin Clients
  • Zero Clients

For each device a different Horizon Client (depending on the OS) is available for download.

As already mentioned earlier in this series, Blast should be the primary protocol for your Horizon sessions. If you have endpoints where a Horizon Client cannot be used or installed, you still have the HTML access option.

Smart Policies

Configuration for Smart Policies are done in the UEM console. Some of the settings you have configured via Group Policies before can now be done in UEM. I’m talking about configuration based on conditions like client location, launch tag or pool name. But it’s also possible to fill in your own personal View client properties:

With Smart Policies, administrators have granular control of a user’s desktop experience. A number of key Horizon 7 features can be dynamically enabled, disabled, or controlled based not only on who the user is, but on the many different variables available through Horizon 7: client device, IP address, pool name, and so on.

horizon smart policies

Example: Based on the client device used you can set different settings for USB redirection, clipboard and bandwidth profile.

Smart Policies can be enforced and evaluated at login/logout and reconnect/disconnect and at defined refresh intervals. This allows IT to maintain endpoint and session security even the user changes the network, the endpoint or both.

These are the basics about session management and client devices. We have now covered all sections of the exam blueprint:

Section 1 – Create a Horizon Conceptual Design
Section 2 – Create a Horizon Logical Design
Section 3 – Create a Physical Design for vSphere and Horizon Components
Section 4 – Create a Physical Design for Horizon Storage
Section 5 – Create a Physical Design for Horizon Networking
Section 6 – Create a Physical Design for Horizon Desktops and Pools
Section 7 – Incorporate Application Services into a Horizon Physical Design
Section 8 – Incorporate Endpoints into a Horizon Design

What’s Next?

I know the basics about a Horizon 7 implementation but I need to gain more technical knowledge about each product. As a Solution Architect I have a customer-facing pre-sales role and in general have no hands-on experience. As a consultant, who works with the Horizon suite on a daily basis, I’m sure that the VCAP-DTM Design exam would a piece of cake. 🙂

The next weeks I will  read a lot of the PDFs (reference architecture and admin guides) mentioned in the exam blueprint and they are about:

  • Horizon 7.2 (including Mirage, ThinApp, UAG)
  • App Volumes 2.12
  • IDM 2.9
  • UEM 9.2
  • vROps 6.4
  • vSAN 6.2
  • vSphere 6.5

Because I have a quite big home office and love whiteboards, I decided to order whiteboard papers which hold to the walls by static charge. This should help me to note important stuff down. 😀

whiteboard paper

I have left six weeks to prepare! Let’s do this! 🙂 Jump to part 10