First-Gen Tenants - System Architecture of IMS

This documentation page describes the relationship between the core components of the Horizon Image Management Service with a first-generation Horizon Cloud tenant.

Using this Page

Attention: This information applies solely when you have access to a first-gen tenant environment in the first-gen control plane. As described in KB-92424, the first-gen control plane has reached end of availability (EOA). See that article for details.

As of August 2022, Horizon Cloud is generally available and has its own guide, Using Horizon Control Plane Horizon Cloud.

An indication of which environment you have, Horizon Cloud or first-gen, is the pattern that appears in the browser's URL field after you log in to your environment and see the Horizon Universal Console label. For a Horizon Cloud environment, the console's URL address contains a portion like /hcsadmin/. The first-gen console's URL has a different section (/horizonadmin/).

Image Catalog

IMS maintains an image catalog that offers a consolidated view of the images associated with your first-gen tenant environment, categorized by deployment type:

• Horizon deployments based on Connection Server technology, called Horizon pods for short.
• First-generation Horizon Cloud on Microsoft Azure deployments, called Horizon Cloud pods for short.

You can perform the same image management operations on images from either type. Along with these common features, images in first-gen Horizon Cloud on Microsoft Azure deployments support additional features such as the ability to redo and undo the publishing of image versions.

Components in the IMS Workflows in a First-Gen Horizon Cloud Environment

As the following diagram illustrates for a first-gen tenant's pod fleet, IMS manages images from both deployment types, using workflows that are separate and independent from each other.

• Horizon pods - IMS workflows

  For these deployments, IMS stores copies of image versions in datastores managed by the vCenter Server instances within participating pods.

  These stored copies correspond to the images listed in the tenant's image catalog.

  During publishing, IMS replicates image versions using the content library shared between the vCenter Server instances. IMS then deletes the temporary objects in the content library that were used for the replication process.

• Horizon Cloud pods - IMS workflows

  For these deployments, IMS stores copies of image versions in the Azure resource groups of participating pods.

  These stored copies correspond to the images listed in the tenant's image catalog.

  During publishing, IMS replicates image versions across different Azure regions and subscriptions using the Microsoft Azure Shared Image Gallery definitions within the pods. IMS then discards the temporary objects in the Shared Image Gallery that were used for the replication.

Note: IMS does not currently support the cross-platform migration of images between different deployment types

Example

The following diagram shows an example of a first-gen Horizon Cloud pod fleet that consists of both Horizon pods and Horizon Cloud pods.

In this example, the Horizon pods consist of on-premises deployments.

First-Gen Tenants - Understanding the Image Management Workflow within a First-Generation Horizon Cloud Tenant

This section describes the end-to-end workflow that takes place in a first-generation Horizon Cloud environment for using Horizon Image Management Service to set up, customize, and publish images to desktop assignments.

The end-to-end workflow involves a certain sequence of tasks.

Definitions of Terms

• Image

  An entity that under a particular operating system contains desktop image versions and copies or server image versions and copies. Versions and copies are organized in a hierarchy and managed by an administrator.

• Version

  A particular customization of an image in terms of installed applications or software. Version numbering includes a major version and a minor version (for example, a major version of 1 and a minor version of 2 results in version number 1.2), which helps trace the lineage of a version. Versions can also be marked with markers for use by multi-cloud assignments.

• Copy

  An instance of a version available on a particular pod after the version is published to the destination pods. The copy is a view-only entity that provides information about the status and location of the pod-specific instance of the version.

• Pool

  Within the context of understanding the IMS workflow within a first-gen Horizon Cloud tenant, this term applies to Horizon pod deployments in the tenant's pod fleet. Such deployments are based on Connection Server software. For such pods, a pool is a collection of virtual machines provisioned from a specific image version.

• Assignment

  Within the context of understanding the IMS workflow within a first-gen Horizon Cloud tenant, this term applies primarily to the Horizon Cloud on Microsoft Azure deployments in the tenant's pod fleet. For such pods, an assignment is a collection of virtual machines provisioned from a specific image version. This assignment concept is a parallel concept to the pool concept used for Horizon pods.

• Marker

  A special tag unique to an image that instructs a pool or assignment as to which version of an image to use to provision workflows.

• Horizon deployment, Horizon pod

  Briefly, a deployment that uses Horizon Connection Server software and is referred to as a Horizon pod for short.

• Horizon Cloud on Microsoft Azure deployment, Horizon Cloud pod

  Briefly, in the first-gen Horizon Cloud service, a deployment that uses the Horizon Cloud pod-manager technology and is referred to as a Horizon Cloud pod for short.

First-Gen Tenants - Working with Images Using IMS

As defined in the preceding section, an image is a collection of image versions that can be associated with pools or assignments across a first-generation Horizon Cloud tenant's pod fleet.

Before you can use IMS to work with images, you must perform the preparatory requirements for importing an image into the image catalog and publishing that image to the pod deployment type you plan to use with IMS.

• Horizon type

  Specify the login credentials for the vCenter Server instances that you want to configure for this use. See Configure the vCenter Server instances.

• Horizon Cloud on Microsoft Azure type

  Ensure you meet the relevant criteria in the System Requirements and that all your tenant's Horizon Cloud pods are online and healthy.

The steps that follow apply to a collection of pods. For example, a collection might consist of seven pods. The steps summarize the process of importing an image into the image catalog and publishing that image to those pods.

Note: Because of the distinct software technology underlying the two pod types, the process and terminology for creating images differ slightly between Horizon pods and Horizon Cloud pods.

• Horizon pod - creating images

  You create an image by selecting a vCenter VM template or snapshot.

  Then you customize the image, publish the image, add a marker to the image, and map pools to the marker.

• Horizon Cloud pod - creating images

  You create an image by selecting an OS image from the Microsoft Azure Marketplace or a custom image available in the user subscription.

  Then you customize the image, publish the image, add a marker to the image, and map assignments to the marker.

Pictorial Diagram of the IMS Workflow

The following diagram applies to both pod types (Horizon, Horizon Cloud). The diagram depicts the process of importing an image into the image catalog and publishing that image to those pods.

Create an Image Instance

An image is a collection of one or more versions. When you initiate the import action on a selected image, Horizon Image Management Service registers the image with the service by storing the metadata of the image in the image catalog. Horizon Image Management Service also performs certain preparation steps on the image in its source pod.

• Horizon pods

  Horizon Cloud Connector enables the connection between the image's source pod and the service. One of the pods in the fleet is the source pod.

  For example, a pod named "On-premises Pod 4" is the source pod for a Win10POS image undergoing the import operation. See First-Gen Tenants - IMS and Horizon 8 Pods - Import an Image from vCenter into the Image Catalog.

• Horizon Cloud on Microsoft Azure type

  The service and Horizon Cloud pod components enable the image to be cloned in Microsoft Azure (when importing from Azure Marketplace) and synchronized with the images catalog at the end of the import process.

  For example, a pod named "Azure Pod 4" is the source pod for a Win10POS image undergoing the import operation. See First-Gen Tenants - IMS and Horizon Cloud on Microsoft Azure Deployments - Import an Image into the Image Catalog.

After the import operation is complete, the image is added to the image catalog as image version 1.0. This image version shows the Deployment Complete status, indicating that it is ready to be published.

For this example, Win10POS becomes a newly created image in the catalog.

Important:

In the IMS workflow's step 3 of publishing an image, the publishing operation will adhere to the pod type.

• Images from Horizon pod deployments are only published to Horizon pod deployments.
• Images from Horizon Cloud on Microsoft Azure deployments are only published to Horizon Cloud pods in your Microsoft Azure cloud capacity.

2. Customize the Image

Once the image is imported, you can customize the image version content by accessing the image directly.

• For Horizon deployments, you access the image directly using vCenter Console Access.
• For Horizon Cloud on Microsoft Azure deployments, you access the image directly with an RDP session.

In both cases, you log in to the image VM using local admin credentials. See Customize an Image.

3. Publish

When you initiate the Publish action on image version 1.0, Horizon Image Management Service publishes the image version to all the pods of the same capacity type that are present in the pod fleet at the time of publication.

The publishing operation will adhere to the pod type. For an imported image from a Horizon pod, the Publish action publishes that image to all the eligible Horizon pods, unless you select a subset of destinations. The same behavior applies for an imported image from a Horizon Cloud pod.

You can also select a subset of eligible pods and publish the image to that subset. For this use case, after you select Publish, toggle Select Destination under Destination to choose the target pods for replication. When you toggle Select Destination, the system displays a list of available pods. Select the check box next to each pod to select it. The source pod for the image is selected by default and cannot be deselected.

The service replicates and places a copy of the image version in the infrastructure supporting each pod.

• For Horizon pods, each image copy resides in a datastore within the vCenter Server instance of that pod.
• For Horizon Cloud on Microsoft Azure deployments, the image copy is placed as a VM in the resource groups corresponding to the pod.
• You might observe detailed error messages for a copy status in the image copy details page due to infrastructure issues such as the Microsoft Azure quota being exceeded, timeouts, or socket exceptions.

See First-Gen Horizon Cloud - IMS - Publishing the Image Version.

4. Define the Marker (Use Case)

Once published, before an image can be use for a pool or an assignment, the image version must be marked for that purpose, using what is called a marker.

The marker communicates to a pool or assignment which version of the image to use.

Versions can have one or more markers linked to different pools and assignments, while a pool and assignment can only use one marker.

This design allows you to stagger updates by having different sets of pools and assignments following different markers.

See First-Gen - Working with IMS Markers.

5. Link to a Pool or Assignment

You link a pool or assignment to its image by specifying the image and a marker.

When markers are moved to a different version, the linked pools and assignments receive refresh instructions.

Non-persistent pools and assignments rebuild when refreshing while persistent pools and assignments provision new workloads based on the latest updated image version.

For details, refer to:

• Horizon Pods - Create a New Desktop Pool for Multi-Cloud Assignments
• Horizon Pods - Create an Automated Farm from a Managed Image
• Horizon Cloud in Microsoft Azure - Creating VDI Multi-Cloud Assignments with Managed Images

6. Create a New Version

Once published, you can use any version to create the next version in an unpublished state. Refer to Create a New Image Version.

After which, you can perform this procedure again starting at the Customize the Image workflow step.

When you create a new image version, you can move the marker you created earlier to this new image version, instead of creating a new marker.

That move-marker action instructs the pools or assignments associated with that image to refresh to the new image version.

If you need a new marker for a different use case, you can always add a new marker.

First-Gen - Working with IMS Markers in a First-Gen Horizon Cloud Environment

This section describes how to use IMS markers.

Brief Introduction to IMS Markers

You use markers to associate your desktop assignments with specific image versions in an image stream.

As described in the Definitions of Terms section of page First-Gen - Understanding the Image Management Workflow, a marker is a special tag unique to an image that instructs a pool or assignment as to which version of an image to use to provision workflows.

Example of Using Markers with Images

Note: The following images depict use of markers with images from Horizon 8 pods. The concepts also apply to use of markers with images from first-gen Horizon Cloud on Microsoft Azure deployments.

The following figure depicts the initial state of an image management scenario.

In this scenario, several desktop pools/assignments use different versions within the Win10CorpKnow image stream. The administrator uses markers to associate specific image versions with specific pools/assignments. For example, the administrator has provisioned Pool 1 to a user group dedicated to user acceptance testing. By tagging both Pool 1 and image version 19 with the UAT marker, the administrator ensures that the desktops in Pool 1 are cloned from image version 19.

Now suppose that the administrator wants to provide the user acceptance testers with a modified desktop image. To accomplish this task, the administrator creates a new version 20 in the image catalog. Then they customize the underlying image on the source pod and publish the customized version 20 to all the other pods. Finally, they reassociate or move the UAT marker from version 19 to version 20, as shown in the following figure.

By reassociating or moving the UAT marker, the administrator redefines the image used for Pool 1.

• For Horizon pods, the marker reassociation triggers an automatic process in which all the desktops in Pool 1 are updated with image version 20.
• For pods in Microsoft Azure, the marker reassociation prompts IMS to first validate whether Pool 1 is online and ready to receive an image update. If the validation is successful, IMS proceeds to update all the desktops in Pool 1 with image version 20.