Solution

  • Horizon

Type

  • Blog

Level

  • Intermediate

Category

  • Technical Overview

Product

  • Horizon Cloud Service

OS/Platform

  • Azure

Phase

  • Design
  • Deploy

Senior Technical Marketing Architect, End User Computing, VMware.
Rick has been working on the VMware's EUC Technical Marketing team since 2014, and has been at VMware since 2008. He is a regular speaker at VMworld on different topics. Prior to VMware, he had different roles at NetIQ, at Appetizers And, Inc. and at Arthur Andersen. Rick has a degree in Computer Science from Western Illinois University and enjoys woodworking, gardening and traveling and watching way too much sports.

New Custom Deployment Methods in Horizon Cloud on Microsoft Azure

February 11, 2020

Horizon Cloud on Microsoft Azure is a simple solution for providing desktops and streamed applications to your end users. The deployment is straightforward and simple - you prepare and provide information to VMware on a Microsoft Azure subscription, and the Horizon Service deploys a Horizon Cloud on Microsoft Azure pod into the subscription on your behalf.

Some customers need more flexibility in pod deployment options. For example, what if you want your application development team to leverage Horizon Cloud on Microsoft Azure to access segregated development, QE, and production environments, yet access them all from the same Horizon Cloud on Microsoft Azure pod? In this case, using the new custom deployment options available in Horizon Cloud on Microsoft Azure may help you.

For a basic Horizon Cloud on Microsoft Azure deployment, all components of the pod are deployed into the same Microsoft Azure VNET in the same subscription.

Figure 1. Basic Horizon Cloud on Microsoft Azure Pod Deployment Configuration

Starting with Horizon Cloud on Microsoft Azure 2.2, two deployment options have been added facilitate these architectures.

Using these two deployment options allow you deploy Horizon Cloud on Microsoft Azure to accommodate a hub-spoke architecture built within Microsoft Azure. 

When you choose either of these new deployment options, the Unified Access Gateway configuration components are deployed into a separate VNET or Subscription from the rest of the Horizon Cloud on Microsoft Azure pod, and will require you to follow an amended set of pre-requisites to make Horizon Cloud on Microsoft Azure function properly.  

Using a different subscription for an External Gateway

You can choose to deploy your Unified Access Gateways into a separate subscription by toggling this option in the Horizon Cloud on Microsoft Azure deployment UI. 

Figure 2. Use a Different Subscription for External Gateway

This option allows you to deploy the Unified Access Gateway components into a separate subscription as depicted below:

Figure 3. UAG in separate VNet - Separate Subscription

With this configuration, you will need to make sure that the two subscriptions are line-of-sight visible to each other via network peering across subscriptions or by other means such as a site to site virtual gateway.  You can find details on the critical prerequisites for this configuration in the Horizon Cloud Deployment Guide.

Deploying Unified Access Gateways into a Different VNET

You can choose to deploy your Unified Access Gateways into a separate virtual network by toggling this option in the Horizon Cloud on Microsoft Azure deployment UI:

Figure 4. Use a Different Virtual Network

This option allows you to deploy the Unified Access Gateway components into a separate subscription as depicted below:

With this configuration, you will need to make sure that the two subscriptions are line-of-sight visible to each other via virtual network peering or other methods. You can find details on the critical prerequisites for this configuration in the Horizon Cloud Deployment Guide.

Using the two options in other configurations

The use of these two deployment options opens the door to a number of deployment configurations that were not available until now.  The diagrams below describe typical configuration examples that customers have demonstrated using these features to deploy a more complex configurations, where external traffic flows through another VNET who's purpose is to provide a separate VNET where Network Virtual Appliances are deployed to provide a DMZ to manage internet based traffic prior to access to the UAGs.   This follows the Hub-Spoke network topology with shared services in Azure example.

Using a sseparate VNet with "trusted" traffic

The configurations depicted below shows how you can deploy the components leveraging a separate subnet for NVA appliances, with a trusted connection to the Horizon Cloud on Microsoft Azure components.

Figure 5. UAG in separate VNET – Same Subscription with NVA – UAG Trusted Traffic

Figure 6. UAG in separate VNET – Separate Subscription with NVA – UAG Trusted

Using a separate VNet with "untrusted" traffic

The configurations depicted below shows how you can deploy the components leveraging a separate subnet for NVA appliances.  In this example, the traffic is still considered to be untrusted from the UAGs , and introduces another layer of security by routing traffic back to the NVA's to handle trusted and untrusted connections.  

Figure 7. UAG in Separate VNET - Same Subscription with NVA - Front End & Back End Interfaces on NVA - UAG Untrusted Traffic

 

Figure 8. UAG in Separate VNET - Separate Subscription with NVA - Front End & Back End Interfaces on NVA - UAG Untrusted Traffic

Using a separate VNet with front- and back-end NVA

The configurations depicted below shows how you can deploy the components leveraging an additional separate subnet for more NVA appliances.  In this example, the traffic is still considered to be untrusted from the UAGs , and introduces another layer of security by routing traffic into additional NVA's to handle trusted and untrusted connections.  

Figure 9. UAG in Separate VNET - Same Subscription with Front End NVA & Back End NVA

 

Figure 10. UAG in Separate VNET - Separate Subscription with Front End NVA & Back End NVA

 

 

Filter Tags

  • Horizon
  • Intermediate
  • Technical Overview
  • Blog
  • Horizon Cloud Service
  • Azure
  • Design
  • Deploy
February 11, 2020

Senior Technical Marketing Architect, End User Computing, VMware.
Rick has been working on the VMware's EUC Technical Marketing team since 2014, and has been at VMware since 2008. He is a regular speaker at VMworld on different topics. Prior to VMware, he had different roles at NetIQ, at Appetizers And, Inc. and at Arthur Andersen. Rick has a degree in Computer Science from Western Illinois University and enjoys woodworking, gardening and traveling and watching way too much sports.