Horizon Cloud Pods — Remedies for Common Pre-Check Failures

This topic describes the remedies to take for common maintenance pre-check failures. When the system's pre-checks reveal conditions that would block maintenance activity on a pod, those errors are surfaced to you in the Horizon Universal Console so that you can take the actions required to remedy them.

Important: If you receive any notifications about pod update errors, you must take the specified actions to remedy the errors in a timely fashion. Time is of the essence. Failure to act to remedy those errors in the time that the service requires, the pod will go into an unsupported state due to the failure to remedy the pod update process. .

As described in Horizon Cloud Pods - Maintenance and Updates, the system notifies you of the maintenance-blocking conditions that are under your control in your Microsoft Azure environment. Because the remedy is in your control and cannot be resolved by us, if you see notification of update errors in the console or you receive a notification email about such errors, you must complete the actions to resolve them and then contact Horizon Cloud Support team to continue the maintenance activity.

Update-Blocking Errors that can Typically Occur

These are the update-blocking errors that can typically occur and which you can remedy in your Microsoft Azure environment.

• Subscription policies are blocking use of Azure Marketplace offers from the service's publisher.

  As described in this documentation page, starting in early calendar year 2022, the service enhanced the upgrade code to programmatically use offers that we provide in the Azure Marketplace. When the upgrade pre-checks determine that programmatic use of those offers is prevented in the subscription, you must complete the actions as described in that documentation page to resolve the update-blocking errors.

• Subscription does not have enough of the appropriate cores (vCPUs) or VM sizes available to instantiate all of the VMs for the parallel to-be VMs.

  When the green components are built out, for each VM in your current pod, another VM gets created. As a result, you will have a duplicate number of pod manager VMs and Unified Access Gateway VMs from the time the green components are built out until the migration from the blue components to green components occurs at the time you scheduled in the console. To accommodate creating these green VMs, your subscription's quota levels for cores (vCPUs) from the relevant Microsoft VM families must be enough to encompass the parallel to-be VMs along with the quota you have already used from that subscription for its existing associated pods. See the quota and cores table below for the necessary cores for the various VM types and usages.

• Pod is currently offline, or is not currently able to communicate with Horizon Cloud.

  On the Capacity page, verify that the to-be-updated pod is reporting online status. Log in to the Microsoft Azure portal and check if the pod manager VM and its Unified Access Gateway VMs (if your pod has those) are running. If a VM is not running, power it on. For details about the resource groups in which those VMs are located, see First-Gen Tenants - Resource Groups Created For a Pod Deployed In Microsoft Azure.

• Permission to create or delete resource groups is not enabled for this Microsoft Azure subscription.

  The system pre-check validates that the service principal associated with this pod has the required permissions that the service requires. If the permission to create or delete resource groups is not enabled in the pod's subscription, that automation is blocked. To remedy this situation, follow the validation's guidance message on how to enable the required permissions using the Microsoft Azure Portal. For more information about the permissions that the service requires the service principal to have to perform the operations required by the service, read When Your Organization Prefers to Use a Custom Role.

Quota and Cores Needed For the Time from Deploying the Green VMs to When the Migration From the Blue VMs is Completed

If you are notified about an update error due to lack of available cores, use the following table to see the additional quota you need. For the various VM types used in the current as-is pod, the table at the end of this topic describes the quota used by those types, the additional quota needed when the green pod VMs are created, and the total quota needed for running both the blue and green VMs from when the green VMs are created until the migration to the green build-out completes. For details about the VM family types and cores used by a pod, see the page VM requirements for a pod in the Deployment Guide.