From the Horizon Universal Console, you can use the Add Horizon Edge UI to add and deploy a Horizon Edge into your Microsoft Azure subscription. The Horizon Edge is a thin-edge cloud infrastructure. For Microsoft Azure deployments, an Azure subscription is the provider.
Note: You can define a Horizon Edge as a traditional single tenancy deployment or as a multitenancy deployment.
After your environment is configured with at least one Active Directory domain and an identity provider, the Horizon Universal Console makes the Add Horizon Edge UI flow available.
Note: After you deploy an Edge VM, you cannot change its IP address. Attempting to do so causes Edge Gateway downtime as the Kubernetes cluster stops working and must be reinitialized. Changing the IP address of a deployed Edge VM is not supported.
Understanding Multitenancy Deployment
Single tenancy is the traditional deployment method for Horizon Edges of any capacity type in Horizon Cloud, but multitenancy deployment is available for the Horizon Cloud on Microsoft Azure provider type.
Configuration options for specifying whether the Edge is to be created using the single tenant method or the multitenant method are available in the Edge creation flow as you step through the Add Horizon Edge UI page.
Creating a Horizon Edge for Microsoft Azure as an Omnissa-managed Enterprise App registration type (also known as the multitenancy method) in Horizon Cloud allows administrators to use Omnissa-managed credentials to access Azure subscriptions, eliminating the need for customers to manually manage service principal secrets and key rotations.
With multitenancy, your organization accepts our consent link and Omnissa creates a service principal on your tenant. The app ID and secrets key become something that Omnissa owns and manages on your organization’s behalf. Using this method in Horizon Cloud requires you to grant Omnissa's service principal (app ID) access to your subscription through the Microsoft Azure portal. This process is built-in to the Horizon Edge creation process, as described below in the Procedure section.
Note: If you delete a multitenant app in Horizon Cloud, you must also delete it from your Microsoft Azure portal.
The Omnissa-managed method (Omnissa-managed Enterprise App registration type) takes the responsibility of maintaining the service principal secrets key from the customer organization and places that responsibility on Omnissa. This provides an added degree of security, as organizations do not need to provide their secrets key information to Omnissa.
The traditional single tenancy method of Horizon Edge deployments for Horizon Cloud on Microsoft Azure (Manual Enterprise App registration type) continues to be available.
The Omnissa-managed method (Omnissa-managed Enterprise App registration type) is the recommended method.
Multitenancy Prerequisites
The prerequisites for granting consent to a multitenant application are described in Grant tenant-wide admin consent to an application in Microsoft product documentation.
Horizon Edge Gateway Deployment Considerations
Configuration options for specifying the Horizon Edge Gateway are available when you get to the Horizon Edge Gateway section of the Add Horizon Edge UI stepper page.
As an administrator, you can specify that a Horizon Edge Gateway be deployed in Microsoft Azure as either a Single Virtual Machine or as an Azure Kubernetes Service (AKS). The preferred mode is AKS.
If you choose to deploy the Horizon Edge Gateway as a single virtual machine during initial setup, you can also change the deployment to AKS later on. However, once the Edge Gateway is deployed successfully in AKS mode, you cannot revert back to single VM mode. If during this change workflow, AKS deployment fails, you can review the error message and retry the workflow to move to AKS or you can revert back to single VM mode.
Note: You cannot change the network connectivity type (Internet to Azure private link) while making the Horizon Edge Gateway deployment mode change (single VM to AKS). Only one operation is supported at a time.
Decide which Horizon Edge Gateway deployment type to use based on the qualities that you need.
| Deployment Type | Key Qualities | Details |
|---|---|---|
| Azure Kubernetes Service (AKS) |
| AKS is a Microsoft Azure standard for enterprise cloud-native apps in Microsoft Azure data centers. The AKS type provides an Edge Gateway of a clustered architecture, which provides for replicated services supporting the SSO login experience and monitoring data collections. AKS also allows for high availability (HA). |
| Single Virtual Machine |
|
Even though the Single VM type is simpler to deploy due to less prerequisites than the AKS type, if the deployed VM becomes unavailable, the following may occur:
|
General Prerequisites
As you select items in the Add Horizon Edge UI stepper pages, the system attempts to confirm that specific items are fulfilled. If those requirements are unfulfilled, you are blocked from completing the UI steps. For example, when deploying the AKS deployment type, if the selected NAT gateway in Cluster outbound type is not connected to the selected Management Subnet, when you click Deploy, the UI displays a message and prevents further progress. At that point, you'll have to back out of the UI steps, complete that requirement to connect the NAT gateway with the management subnet, and restart the UI steps from the beginning.
Before you begin to create the Horizon Edge, verify that you or your IT team have completed the following prerequisites.
-
Review the Requirements Checklist for Deploying a Microsoft Azure Edge and ensure that those requirements are fulfilled. Note that the requirements for traditional single tenancy (manual) and multitenancy are slightly different.
-
Review the preparatory items described in the hyperlinked pages within the page Microsoft Azure Edge Deployments and ensure that those items are completed.
-
Review the Omnissa Community forum article Understanding Omnissa Horizon Edge Gateway: Purpose, Architecture & Best Practices.
-
Verify you have the Azure subscription information, network information, FQDNs, and such items so that you can specify those in the wizard's fields and lists.
-
Verify that the necessary outbound ports are allowed. See Make Appropriate Destination URLs Reachable to Deploy a Horizon Edge Gateway in a Microsoft Azure Environment.
-
If you plan to use a proxy server for routing traffic, it must be reachable from the Edge's Management subnet.
-
Decide whether you want this Horizon Edge's primary provider to be dedicated to the Horizon Edge Gateway and Unified Access Gateway instances, or if you want the primary provider to also deliver the end-user desktops and applications. If you want the primary provider dedicated to this Horizon Edge's gateway appliances, you'll need the Azure subscription information for the UI's step of specifying a secondary provider for the desktops and applications.
Prerequisites for Configuring UAG Advanced Mode
Configuration options for specifying the Horizon Unified Access Gateway are available when you get to the Unified Access Gateway section of the Add Horizon Edge UI stepper page. Be sure to meet these prerequisites before you begin to add the Horizon Edge.
-
Ensure that all Horizon Clients connecting to the Edge (for which UAG Advanced mode is being configured) have been upgraded to the latest Horizon HAI agent. See the Horizon Cloud Release Notes for related information about HAI agent version requirements.
-
UAG Advanced Mode is available across all supported platforms, including Native Desktop, Mobile, and Web clients.
-
When editing a deployed Horizon Edge, if there is a change in the deployment type from Basic to Advanced or Advanced to Basic, the load balancer IP address in the Unified Access Gateway section of the Edge deployment UI page might change. If a change in the load balancer IP does occur, you must update the DNS record with the new IP address.
-
If the Unified Access Gateway load balancer has a private front-end IP address allocated from a DMZ or VM subnet, the load balancer IP address will change if you select a different subnet while changing the deployment type to or from Basic and Advanced. For more information, see Update Unified Access Gateway Deployment Type and Load Balancer IP Address Impact.
Prerequisites for Deploying the UAG Outside of the Azure Marketplace
When you deploy a UAG, if your Azure Subscription is Azure China, Horizon Cloud automatically creates a storage account in a new resource group and imports the UAG VHD. We then create an image from that VHD in your Azure Subscription. The image version is valid for create, scale-out, scale-in, and upgrade operations. The name of the auto-generated resource group is hcsappimg-{providerInstanceId}-rg. The storage account name is randomly generated because it must be unique across all of Azure. If you do not want Horizon Cloud to automatically create that new resource group or new storage account, you must contact Omnissa Customer Connect and provide Support with the Storage Account ID for one of your existing resource groups or storage accounts so that we can run an API ahead of time to import the VHD into your existing storage account and create the image in an existing resource group. Currently, this capability is available only for an Azure China provider.
Considerations When Enabling High Availability Mode
You can optionally enable High Availability mode when defining or editing a UAG. In UAG High Availability zones, VMs are distributed across availability zones in a region. A fallback VM model helps to reduce deployment failures while deploying UAG VMs across availability zones. For example, if a selected VM model is not available for deployment, then a fallback VM model is chosen for deployment until a deployment status of either success or failure occurs.
The recommended fallback VM models are selected by default. You can choose up to five fallback VM models. The fallback VM models are pre-selected based on a similar compute to the VM model, however you can update the VM selections.
An existing UAG deployment can be updated to a High Availability UAG deployment by editing the UAG and enabling the High Availability option.
Procedure for Creating the Horizon Edge for Microsoft Azure
During this procedure you'll make various configuration choices for your Horizon Edge on Microsoft Azure, including whether to deploy for single tenancy or multitenancy.
The Horizon Universal Console in Horizon Cloud makes the Add Horizon Edge UI page available from various entry points. Your starting point in the console for this step typically depends on whether your environment is greenfield or it has existing Horizon Edge deployments.
-
No Horizon Edges yet - If your environment has no Horizon Edges, you can start the wizard by clicking START DEPLOYMENT. Alternatively, you can click Capacity and clicking Start > Microsoft Azure to open the UI stepper.
-
At least one Horizon Edge - If there is at least one Horizon Edge for Microsoft Azure that has already been created and deployed in your Horizon Cloud environment, click Capacity > Horizon Edges > Add > Horizon Cloud > Microsoft Azure from the Horizon Universal Console to open the Add Horizon Edge stepper page.
-
Log in to the Horizon Universal Console. See Log in to Horizon Cloud.
-
Click Capacity > Horizon Edges in the left pane navigation.
-
From the Horizon Edges tab, click Add and from the drop-down menu, select Horizon Cloud > Microsoft Azure.
-
Respond to all subsequent UI stepper pages as described below.
General Information
Enter a unique Horizon Edge Name that will distinguish this Horizon Edge from others that you'll see in the console. You can add an optional description. Click Next to continue.
Primary Provider
Complete the entries in the Primary Provider page and then click Next to continue.
-
For Azure Subscription, either select one of your environment's existing providers or use Add New to provide new provider subscription information. If you select an existing Azure subscription, the following fields are populated and no editable.
When adding new provider subscription information, provide:
-
A unique Provider Name that will distinguish it from others you'll see in the console.
-
Your Microsoft Azure Subscription ID from the Microsoft Azure Portal.
-
Select the Azure Cloud Type, Azure Region, and Directory ID applicable for that Microsoft Azure subscription ID.
-
Provide the service principal's information (the Application ID, Application Key, and Expiry Date) that you created in the Microsoft Azure portal for this purpose.
For related information about expiry of the service principal application key, see Monitoring and Managing Notifications.
-
-
For the Enterprise App Registration Type, select either Manual for the traditional single tenant method or Omnissa Managed (Recommended) for the multitenant method, as described in onscreen help.
-
Optionally select the Dedicate to Horizon gateway appliances checkbox to dedicate this provider to the Horizon Edge Gateway and Unified Access Gateway instances and use a separate provider for delivering end user entitled resources. If unselected, this provider will also deliver the end user entitled resources.
Enterprise App Registration
Complete the Enterprise App Registration page and click Next to continue. Note that the options differ based on whether you selected Manual or Omnissa Managed (Recommended) on the Primary Provider page.
-
If you specified Omnissa Managed (Recommended) on the previous stepper, you can add multitenant apps (or select an available multitenant app) for subscription IDs of which you have been granted access as described in onscreen help. You can also optionally select the checkbox to Propagate to all Horizon Edges, UAGs, images, and pools.
-
Click Add and in the Multitenant Apps section of the page to add a new multitenant application, or select an existing multitenant app from the table.
-
In the Status column for the specific multitenant app row, note that the status displays as Consent Not Granted.
-
In the Actions column for the specific multitenant app row, click Consent Link to open a permissions request page.
-
Note: If you are not allowed to click external links (such as the Consent Link), you can perform an alternative consent process that does not require you to use the Consent Link. To consent without using the Consent Link, you can create the multitenant app service principal by using Microsoft Graph, Azure CLI, or Microsoft Graph PowerShell. The easiest approach is to use the Azure CLI, by running the following commands:
az login --tenant <your-tenant-id> az ad sp create --id <omnissa-application-id>-
From the Microsoft Permissions requested page, click Accept. A message appears stating that a service principal has been created for this tenant and that the name will match the application name from the row in which you selected Consent Link. You are then redirected to your Microsoft Azure portal.
-
The process of granting access permission to the service principal is done in your Microsoft Azure portal in the Access Control (IAM) application. The minumum role assignment required is Contributor. For information about assigning access rights, see topics such as Assign Azure roles using the Azure portal in Microsoft product documentation.
-
After you have granted permission to the service principal, exit your Microsoft Azure portal and refresh your Add Horizon Edge UI page to note that the Status column entry has changed from Consent Not Granted to Role not assigned.
-
-
If you specified Manual on the previous stepper and are choosing to create a traditional single tenant deployment, you'll be prompted to specify the Application ID, the Application Key, and the Expiry date for the service principal as described in onscreen help. You can optionally add additional service principals.
-
(Optional): In the Additional Service Principals section, click Add to add service principals.
In addition to the main service principal for the provider, you can create four additional and unique service principals for that provider. To support a total of 5,000 VMs, add four additional service principals. When you have multiple service principals, they share the subscription ID and directory ID, but each service principal has its own application ID.
Important: You must use the same role for each service principal.
-
(Optional): Expand the Advanced node to add Azure resource tags as needed. For related information, see Using Azure Resource Tags.
Secondary Providers
Complete the Secondary Providers page and click Next to continue.
While you can optionally add secondary providers as described in onscreen help, the secondary provider must be in the same Azure region as the primary provider.
Networks
On the Networks page, select the tenant (desktop) subnets to use for the primary and secondary providers and then click Next to continue.
Note: You can select the subnets at a later stage. However, the system prevents deploying any resources into a provider until the Horizon Edge has at least one associated tenant subnet.
Site
On the Sites page, select from an existing site in your environment or select Add New to add new site information. For a new site, provide a unique name and an optional description. Click Next to continue.
Connectivity
Complete the Connectivity page and click Next to continue.
-
In the Connectivity section, select the Network connection type type for this Horizon Edge as either Azure Private Link (Recommended) or Internet as described in onscreen help.
For related information, see Requirements Checklist for Deploying a Microsoft Azure Edge.
Note: Because Microsoft Azure Government subscriptions do not support Azure Private Link, the connectivity type is fixed as Internet if you selected Azure - US Government as your Azure Cloud Type on the Primary Provider page.
-
In the App Volumes Application Storage section, select the Private endpoint subnet for the Azure private endpoint as either Use Edge Gateway management subnet or Configure custom subnet as described in the following table and then click Next to continue.
Note: After configuring the private endpoint, users should log out from their virtual machines and log in again.
Option Description Use Edge Gateway management subnet Edge Gateway management subnet where a private endpoint resource is created. It is recommended to use this default option. Configure custom subnet Ensure that you have set up the prerequisites. For information about these prerequisites, see Azure Private Endpoint for an App Volumes Application Storage Account. - Select the confirmation check boxes.
- Select a virtual network from the Private Endpoint vNet drop-down.
- Select the corresponding subnet from the Subnet drop-down.
After the Horizon Edge is deployed and the private endpoint is successfully created, status of the private endpoint is Configured. If the status is Not Configured, the private endpoint can be configured again using the Configure Private Endpoint option in the App Volumes Application Storage section of the Horizon Edge. For more information about using this option, see the Configure Private Endpoint for an App Volumes Application Storage Account section in View Horizon Edge Details.
If there are connectivity issues between any of the existing desktop pools and file shares affecting application delivery and you want to revert to the public network access for the storage account until you troubleshoot these issues, then you can use the Remove Private Endpoint option. This option removes the configured private endpoint and automatically enables public network access for the storage account in the Azure portal. After fixing the issues, you can configure the private endpoint using the Configure Private Endpoint option.
Horizon Edge Gateway
Complete the Horizon Edge Gateway page and click Next to continue
- In the Horizon Edge Gateway section, select a deployment type (Azure Kubernetes Service or Single Virtual Machine) as described in onscreen help.
-
Azure Kubernetes Service - This option is for Edge Gateway (AKS). The following screenshot shows the type of information displayed and prompted for when you select the Azure Kubernetes Service deployment type. This deployment type is typically used for a production environment.
-
Single Virtual Machine - This option is for Edge Gateway (VM). The following screenshot shows the type of information displayed and prompted for when you select the Single Virtual Machine deployment type. This deployment type is typically used for a simple or proof-of-concept environment.
Note: The UI displays a High Availability string based on the selected deployment type. For the Single Virtual Machine deployment type, the displayed string means that if the VM is unavailable, end users will see the login flow without the SSO login experience and the desktops' monitoring data is not recorded when the VM is unavailable. For the Azure Kubernetes Service deployment type, the displayed string means the SSO login experience and monitoring data collection are handled through replicated services that enable a full failover of those functions.
Note: As stated earlier, you can initially deploy the edge using the Single Virtual Machine deployment type and later change to the Azure Kubernetes Service (AKS) deployment type. You cannot, however, change a successfully deployed edge from the Azure Kubernetes Service (AKS) deployment type to the Single Virtual Machine deployment type.
- After selecting the deployment type, configure the Horizon Edge Gateway settings using the instructions for that specific deployment type, as follows. When you have completed the UI fields as displayed for your chosen deployment type, continue to follow the on-screen prompts.
| Deployment Type | Steps |
|---|---|
| Azure Kubernetes Service (AKS) |
For the Azure Kubernetes Service option,
|
| Single Virtual Machine |
For the Single Virtual Machine option,
|
Unified Access Gateway (UAG)
Complete the Unified Access Gateway page and then click Save to create the Edge.
Reference the Prerequisites for Configuring UAG Advanced Mode section above if you intend to use the Advanced deployment type.
For information about proxy options when specifying UAG outputs, see Port and Protocol Requirements for Your Horizon Cloud Deployment in Microsoft Azure.
For information about deploying the UAG without the use of the Azure Marketplace, see the Prerequisites for Deploying the UAG Outside of the Azure Marketplace section at the top of this page.
-
In the Deployment section, select the Deployment Type of Basic or Advanced. The deployment type setting specifies that load balancer distribution uses either source-ip-affinity or hash.
- Basic - Use for a load balancer scenario with source-ip-affinity to support up to 2000 connections for each Horizon Edge if NAT gateway or firewall configured in front of an Azure load balance.
- Advanced - Use for a load balancer scenario with hash-based affinity to support up to 18000 connections for each Horizon Edge. Use of this option requires that you use a new management subnet with a subnet mask of /28. This UAG management subnet should be in the same vNet, or in a peered vNet, as the Edge management subnet. The new UAG management subnet must be provided with a /28 subnet mask selected from the list.
For example, in scenarios where you deploy a NAT gateway or firewall in front of an Azure load balancer with Basic/source-ip-affinity UAG enabled, only 2000 connections are supported for each Horizon Edge. With Advanced/hash UAG deployment enabled, up to 18000 connections can be supported for each Horizon Edge.
When you click Save to configure the UAG Advanced mode, a message appears stating that UAG advanced mode configuration is in progress. The UAG Advanced mode configuration may take up to 15 minutes to complete.
After the successful configuration of the UAG Advanced mode, the UAG load balancer IP might change. If so, you might have to update the DNS record with the new IP address.
Note: If the Unified Access Gateway load balancer has a private front-end IP address allocated from a DMZ or VM subnet, the load balancer IP address will change if you select a different subnet while changing the deployment type to or from Basic to Advanced. For more information, see Update Unified Access Gateway Deployment Type and Load Balancer IP Address Impact. For related information about Azure load balancers, see Azure Load Balancer distribution modes in Microsoft documentation.
If you select Advanced, you can perform one or more of the following operations:
- If you are deploying the UAG as Blast Extreme, you can specify that either port 8443 or port 443 be used.
- The deployer service automatically enables 8445 inbound UDP port on the UAG management NSG.
- You can specify an NTP server and Proxy information, as shown and described in the onscreen help for those options.
- You can manage Azure resource tags as needed, which includes viewing inherited tags, editing and deleting existing tags, and adding tags to be applied to the resource groups specific to this Unified Access Gateway. For related information, see Using Azure Resource Tags.
If you select Advanced, you will also see a Cipher Suites option. A cipher suite is a standardized set of cryptographic algorithms that are used to secure communication over a network. All cipher suites are enabled by default. You can choose to disable or enable one or more cipher suites from the following onscreen list:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Note: At least one of the selected cipher suites should be a GCM cipher suite.
-
In the Gateway Access section, select an Access Type from the following options:
- Internal access over a corporate network - if you want to reach your VMs over the intranet (internal corporate network) only. A layer 4 load balancer will be deployed with a frontend in the Desktop network.
- External access over the internet - if you want to reach your VMs over the Internet. A layer 4 load balancer will be deployed with a public IP.
- Internal and external access - allow both internal and external access.
Note: For all three options, outbound Internet access to
*.horizon.omnissa.comis required. When using Internal access over a corporate network, either user-defined routing or NAT Gateway can be applied to the Management subnet to allow outbound traffic. When the external access is configured externally with a DMZ network, external access to*.horizon.omnissa.commust be configured on the DMZ network.If you are using a supported Horizon Edge version, you can also deploy a UAG with a proxy that uses HTTPS instead of HTTP or deploy a UAG with a proxy without being required to provide trusted certificates. To enable these options, contact Omnissa Customer Connect.
-
In the Access Configuration section, select the toggle to enable Automatic Public IP for Unified Access Gateway, or switch off if you prefer to go with manual public IP.
The toggle is switched on by default. If a manual custom IP address is selected, an external Unified Access Gateway is deployed with a private front-end IP address on the DMZ network. You must then take care of the routing from this private IP address to the customer provided public one.
-
In the Access Configuration FQDN section, provide the FQDN or FQDNs for the Unified Access Gateway deployment. The FQDN(s) must be reachable.
When configuring internal and external access, if you want to use the same FQDN, enter the same FQDN in both fields: External FQDN and Internal FQDN.
-
In the Gateway VMs section for the Certificate Type field, select between PEM and PFX from the drop-down menu.
-
In the Gateway VMs section for the Certificate field, upload the certificate that allows clients to trust connections to the Unified Access Gateway in Microsoft Azure.
A self-signed certificate is supported.
The 'SHA256withRSA' signature algorithm is supported and required.
The certificate must only contain Server Authentication EKU and must not include Client Authentication EKU.
-
In the Gateway VMs section, select the VM Model to use for the UAG from the list of available VM models.
-
In the Gateway VMs section, optionally toggle the Enable High Availability option on to create UAGs in different availability zones.
-
In the Gateway VMs section, enter the number of gateway VMs required in the UAG VMs field. For related information, see Consideration When Enabling High Availability Mode above.
-
In the Networking section, use onscreen help to specify virtual network, VM subnet, UAG Management subnet, and DMZ subnet information.
-
(Optional) Expand the Advanced option and use onscreen help to specify blast extreme TCP port, NTP server, outbound proxy, and Azure resource tag information as described in onscreen help and below.
You can manage Azure resource tags as needed, which includes viewing inherited tags, editing and deleting existing tags, and adding tags to be applied to the resource groups specific to this Unified Access Gateway.
If deploying in Azure China, the Azure Marketplace image for the the UAG is not supported. In this scenario, the Unified Access Gateway is copied to an auto-created Azure Storage Account as part of the deployment. This capability is automatically triggered when the UAG deployment uses an Azure China provider. However, you must also add the Storage Blob Data Contributor role to your service principle to support this workflow.
When you deploy a UAG, if your Azure Subscription is Azure China, Horizon Cloud automatically creates a storage account in a new resource group and imports the UAG VHD. We then create an image from that VHD in your Azure Subscription. The image version is valid for create, scale-out, scale-in, and upgrade operations. The resource group, storage account container, and image name will all have the name prefix hcs-app-img. The name of the auto-generated resource group is hcs-app-img-{providerInstanceId}-rg. The storage account name is randomly generated and cannot contain the dash (-) character, thus the name follows the hcsappimg{random-suffix} naming convention.
To instead specify an existing resource group or storage account for this process, contact Support at Omnissa Customer Connect as described in the Prerequisites for Deploying the UAG Outside of the Azure Marketplace section at the top of the page.
-
Click Save.
What to do next
After you complete this procedure, create DNS records that match the FQDN you entered for the Unified Access Gateway instances. See Configure DNS Records After Deploying Horizon Edge Gateway and Unified Access Gateway.
After you complete the Horizon Cloud deployment and entitle desktops or applications to end users, be aware of how the following Unified Access Gateway behavior affects end users using Horizon Web Client. If a Unified Access Gateway instance goes into maintenance mode or enters an unhealthy state and becomes inaccessible, ongoing sessions for end users using Horizon Web Client will reconnect to a healthy Unified Access Gateway instance. The reconnection period can take a couple of minutes. Be aware that refreshing the SSL certificate for the Unified Access Gateway terminates end user sessions.
Note: If you delete a multitenant app in Horizon Cloud, you must also delete it from your Microsoft Azure portal.
For information about monitoring your deployment, see Monitoring Your Environment.
Was this page helpful?