Before you begin using this release of Horizon Image Management Service (IMS), review the following list of known issues and feature limitations.

Use this list in conjunction with the two pages for the Horizon Cloud Service known limitations and known issues, which apply to Horizon Cloud Service overall.

Note: In the current service release, the supported Horizon deployment model is the on-premises deployment type. For details on the requirements that must be met for IMS support with the supported on-premises deployment type, see the IMS System Requirements page.

Known Limitations - IMS and Horizon Cloud on Microsoft Azure Deployments

Important: To be supported for use in Horizon Cloud on Microsoft Azure, all imported base images must be built from Windows-based VMs that are sourced from the Azure Marketplace. Even if you try an image obtained from other origins and the console does not prevent you from using it within the console's workflows, use of such images is unsupported.

If the image is running a Windows 11 operating system, in addition to the requirement to be directly sourced from the Azure Marketplace, the image cannot have been subsequently processed for it to be validly supported in Horizon Cloud on Microsoft Azure. Importing Windows 11 VM from any other sources such as Shared Image Gallery (SIG), Azure Managed Images, Azure VM snapshot, and the like is currently unsupported.

For additional considerations about supported combinations of Gen-1 and Gen-2 machines for the image-related workflows with Horizon Cloud on Microsoft Azure deployments, which OSes are supported for which machine generation, refer to Support for Images Sourced from Pods on Microsoft Azure.

  • You cannot create single-pod VDI assignments with multi-pod images.
  • All pods on Microsoft Azure must be on the manifest version specified in Horizon Image Management Service System Requirements or a later manifest version.
  • The maximum length for a VM name is 15 characters. Horizon creates the VM name by combing the image name with the image version. Both major and minor versions are included. Therefore, if the image name is azure-image and the version is 1.0, the VM name is azure-image-1-0. The image name can be up to 11 characters only if the major and minor versions are one character each, like 1.0 or 9.9. If the version number was 12.1 or 1.13, then the image name must be shorter to avoid error messages.
  • The currently supported Microsoft Azure Marketplace VM sizes are:
    • Standard_DS2_v2 for normal non-graphical workloads, non-Windows 11 OSes
    • Standard_D4s_v3 for normal non-graphical workloads, Windows 11 OSes
    • Standard_NV12s_v3 for graphical workloads, both Windows 11 and non-Windows 11 OSes for which GPU is supported with IMS
    • Standard_NV4as_v4 for graphical workloads and non-Windows 11 OSes.
  • Currently, the Azure GPU-capable NVv4 VMs that use the AMD Radeon Instinct graphics drivers are supported for use only when they are imported using the custom import method. The custom import method is also referred to as a manual import in this documentation. The automated Import Virtual Machine from Marketplace wizard does not provide this feature currently. To use manually imported VMs with IMS, use the Move to Multi-Pod Images feature after you have imported the VM and installed the agents in the VM.

    Also, the service does not currently support use of Windows 11 with these NVv4 VMs and the AMD Radeon Instinct graphics drivers. That use has not been qualified.

  • Support for Windows 11 has some known considerations, limitations, and issues. For those details, see Support for Windows 11 Guest Operating System - Considerations, Known Limitations, and Known Issues.

    These considerations, limitations, and known issues apply also to manual import of a VM and using that with IMS, also sometimes referred to as the custom image workflow. As described at the preceding link, IMS supports use of Microsoft Azure Gen-1 machines only with Windows 10 guest operating systems. IMS supports use of the Gen-2 machines only with Windows 11 guest operating systems.

  • The pod’s Microsoft Azure subscription must be within a single Microsoft Azure Active Directory (AAD) tenant.
  • Intermittently, image status might not match the underlying version status. Eventually, subsequent operations on the image correct the image status.
  • Related to actions from the console's Multi-Pod Images page, the following workflows and actions are not supported for images located in Horizon Cloud on Microsoft Azure deployments:
    • Publishing an image created with New Image or New Version actions from a pod of a higher version to a pod of a lower version.
    • Image expansion or the shrinking of available images on new pods added after publishing.
    • Altering or modifying publish options during the Republish action of a failed image.
    • Console buttons Enable, Disable, and Edit.
    • Migrating existing or legacy images on a pod version other than the manifest versions specified in Horizon Image Management Service System Requirements.
  • Because systemic checks do not occur in the following situations, confirm that all prerequisites are met before you publish.
    • Prior availability of all the pods
    • The sufficiency of Microsoft Azure subscription quotas for compute core or public IPs
    • The capacity sufficiency of the subnets in the pods for holding on to the new IPs created as part of image copies
    • Microsoft Azure VMs are powered on. Otherwise Horizon Image Management Service might encounter an error while publishing the image. This situation is probable because Microsoft Azure VMs might be powered off due to a power policy setting.
  • Limited support is provided for recovering from image publishing errors that can occur during the processing of the Republish action. While the following situations are typical during republishing, the publishing process might not recover because of other unknown or unrecoverable states of the image.
    • The pod goes off line.
    • Due to the implementation of a power policy, Microsoft Azure turns off source or target image copies during the long haul operation of image replication. You can turn the image copies on again and attempt to republish the image copies.
    • Microsoft Azure quotas are exceeded.
    • Certain transient conditions, such as timeouts, may require another publishing attempt.
  • Frequently unpublishing and publishing an image can reduce the stability of the image due to the number of times Sysprep runs on the image.

Known Limitations - IMS and Horizon (Connection Server Type) Deployments

As of the current service release, the supported Horizon deployment model currently is the on-premises deployment type.

Horizon pod deployments in locations other than on-premises deployments are currently unsupported.

The following limitations apply to use of IMS with those Horizon pod deployment models that IMS supports:

  • Horizon Image Management Service only supports vCenter Server authentication based on user name and password credentials.
  • During image publishing operations, you must prevent activities from occurring in vCenter Server that can cause guest VM migrations on the image's underlying VMs. Guest VM migrations that occur at the same time as image publishing operations on the VMs can affect the image publishing operations.
  • The system-default setting for concurrent operations on images is to have three import or publish operations in progress at a time. As an example, importing can be in progress for one image while publishing is in progress for two images. You can change the default on the console's General Settings page. Increasing the setting increases the time to complete the replication.
  • Horizon Image Management Service does not support the management of images for linked-clone workspace assignments. In addition, if you have Horizon View Composer on any pods you want to use with IMS, you must deactivate Horizon View Composer on those pods. You cannot publish images successfully when Horizon View Composer is enabled.
  • Horizon Image Management Service requires the privileges of the full, built-in Windows administrator to create a directory and install Horizon Agent on the virtual machines (VMs) cloned from managed images. For more information, see the following Microsoft documentation topic about the Microsoft Windows built-in administrator account.
  • In some situations, when an image is published, more than one image copy is created on the same Horizon pod and vCenter. The publishing process is not impacted. However, do not remove any of these copies from vCenter as they are necessary for proper functioning.
  • Certain options that can be selected in the Publish workflow with the Horizon pods are not supported for use in the Import, New Image, and New Version workflows. When using the console's Import, New Image, or New Version options, you cannot select a cluster, resource pool, datastore, or network. In this situation, the same parameters are used that were selected during the previous Publish operation. If the image is being imported for the first time, the system will select a cluster, resource pool, datastore, and network.

Known Issues - IMS and Horizon Cloud on Microsoft Azure Deployments

During the image publishing process, a timeout error occurs and the VM remains powered on, and prevents the publish flow from successfully completing (2954270, 2962049)
This issue is the result of an issue in the Microsoft Azure hypervisor that occurs when running the sysprep step of the publishing process. The issue occurs in some Azure VM models. For additional details, refer to VMware Knowledge Base article KB88343.

Based on the Microsoft Azure team's recommendation, to provide a resolution for Horizon Cloud customers, the default Azure VM model used by the service's automated Import VM from Marketplace wizard is changed in the service's v2204 release to use the Standard_DS2_v2 model for the automated import of non-GPU Windows 10 VMs (both single-session and multi-session):

  • For single-pod images, the automation's default VM model is changed from the previously used Standard_D4_v3 VM model to use Standard_DS2_v2.
  • For multi-pod images, the automation's default VM model is changed from the previously used Standard_D2_v2 model to use Standard_DS2_v2.

As of the v2204 release, please include quota for the Azure DSv2-series in your pod's Azure subscriptions.

Publish and republish might occasionally fail with an AGENT_PAIRING or SYSPREP error. (270721)
The message indicates that the AGENT_PAIRING or SYSPREP step in the publish workflow might have errored out. In these situations, attempt the Republish action as described in Republish an Image Version Using the Horizon Universal Console, which sometimes results in recovery.
Publish might occasionally fail with the error "AGENT_PAIRING: Timed out after max retries”. (2741491)
In a multi-pod environment, at some point during the process of publishing the image version, you might find some or all image copies in a failed state, displaying the error message “AGENT_PAIRING: Timed out after max retries.” Perform the following workaround.
  • Restart the VM in the Microsoft Azure Portal and publish the image again.
  • If the publish does not succeed, log in to the VM manually, restart the VM, and re-publish the image.
An image being published on the Multi-Pod Images page might also temporarily appear on the Images page. (2683426)
When you publish an image, the image appears on the Multi-Pod Images page. However, the same image can also appear on the Images page for a brief period of time. You can ignore the in-transition appearance of the image on the Images page, which you cannot act upon and which disappears after a short period of time.

Known Issues - IMS and Horizon (Connection Server Type) Deployments

Image replication fails on publish with error 'Error reading entity from input stream' (2956616)
This issue is due to a failed API call from the Image Locality Service (ILS) in the Horizon Cloud Connector versions 2.2.x and earlier when used with deployments involving vCenter Server 7.0.3. The ILS supports Horizon Image Management Service (IMS) features.

This issue is resolved in Horizon Cloud Connector version 2.3.0 and later.

Pool creation fails when you use the console's feature to select the datastores and networks in the target pod's vCenter Server for the image copy (2982388)
For Horizon Cloud Connector versions 2.2.x and earlier, a known issue exists related to the console's feature for selecting the datastores and networks for the image copy. Due to this known issue, the system always selects E1000 NIC for the template that is created for publishing the image, and the pool creation fails.

This issue is resolved in Horizon Cloud Connector version 2.3.0 and later.