This documentation page describes how to create VDI multi-cloud assignments from Horizon Cloud pods and view their details. These pods are the ones built on the Horizon Cloud pod-manager technology.
You use the Assignment configuration wizard to create VDI multi-cloud assignments of desktops provisioned by multiple Horizon Cloud pods in Microsoft Azure.
- Maximum number of Horizon Cloud pods per VDI multi-cloud assignment
The supported maximum number of Horizon Cloud pods in a VDI multi-cloud assignment is five (5). Using more than five increases the concurrent load on Universal Broker, which is the brokering technology configured in your tenant environment for use with VDI multi-cloud assignments. Increasing that concurrent load can lead to the end users encountering failures when they click on the assignment's displayed tile in the client and the service attempts the operation to log in the user to the virtual desktop.
In addition to adhering to the five-pod maximum per VDI multi-cloud assignment, you can further reduce the likelihood of end users encountering failures at the point when they click on the assignment's displayed tile in the client by including an additional desktop capacity of three percent (3%) in the VDI multi-cloud assignment. As an example, when you are defining a VDI multi-cloud assignment for provisioning 1,000 virtual desktops to 1,000 users, size the assignment for 1,030 desktops.
- About the URL that your end users should use in their clients to properly access desktops that are provisioned from one of these VDI multi-cloud assignments
Only when your environment is configured to use Universal Broker with your Horizon Cloud pods will you be able to create a VDI multi-cloud assignment using those Horizon Cloud pods. When your environment is configured to use Universal Broker with those pods, your end users are expected to use your environment's configured Universal Broker URL in their clients to access the entitled VDI desktops that are provisioned by those multi-cloud assignments. Avoid having your end users use the old-style method, the Unified Access Gateway FQDN in their clients, when your environment is configured to use Universal Broker. Otherwise, unexpected results might occur if you have your end users bypass the Universal Broker and go directly to a Unified Access Gateway FQDN.
- About the labels depicted on the desktop tiles that your end users will see in their clients
Please note that when an end user uses the Universal Broker URL in their client, the label on the desktop tile in their client will display the name that is specified in Assignment Name in the multi-cloud assignment form, as described in the following assignment-creation steps.
However, if you instead tell your end users to use the previously used, single-pod brokering method of using the Unified Access Gateway FQDN, the desktop tile will display a variation of the name that is specified in Assignment Name, and not the precise name that is specified in Assignment Name. The tile will depict the assignment name that appears in the Assignment Name field, plus a unique 8-character suffix.
As an example, if Assignment Name is specified as Dedicated-Sales in the multi-cloud assignment's definition, then:
- Client using Universal Broker URL - the end user sees a desktop tile that is labeled
Dedicated-Sales. - Client instead using the Unified Access Gateway FQDN - the end user sees a desktop tile that is labeled
Dedicated-Sales-nnnnnnnn, where nnnnnnnn is a unique, random alphanumeric string. If two end users both use the Unified Access Gateway FQDN instead of the Universal Broker URL for their desktops in this example, one end user's desktop tile could be labeledDedicated-Sales-d1f466f1while the other end user's tile would be labeled likeDedicated-Sales-6bdbb611.
Important: When these pods are configured to use Universal Broker, end users are expected to use the Universal Broker URL in their clients to access their VDI desktops provisioned from these assignments.
Prerequisites
- VDI multi-cloud assignments are available in tenant environments that are configured to use Universal Broker with your pod-manager-type of pods. Such pods are those that are deployed into Microsoft Azure using the automated pod deployment wizard. Verify that your tenant is configured to use Universal Broker is configured as the brokering method to use with those pods. See Start the Universal Broker Enablement Using the Horizon Universal Console and Configure Universal Broker Settings.
- Configure sites and home site associations for your brokering environment, as described in Configuring Sites for Universal Broker and Configuring Home Sites for Universal Broker.
- Verify that you have at least one published image, with a Microsoft Windows client operating system, in each pod that you plan to select to participate in the assignment. You cannot create a VDI multi-cloud assignment without such an image in each of the participating pods. For example, when you intend to select a single pod for the assignment, that pod must have a published image. When you intend to select multiple pods for this assignment, each of those pods must have at least one published image. To verify, navigate to the Images page and make sure it lists the appropriate images. For steps on creating a published image, see Convert a Configured Image VM to an Assignable Image in Horizon Cloud on a Per-Pod Basis.
- Decide whether you want the desktops to have encrypted disks. You must specify disk encryption when creating the VDI multi-cloud assignment. You cannot later add disk encryption after the assignment is created. For a description of the disk capability, see Using Microsoft Azure Disk Encryption with Your Farms and VDI Desktops in Your Horizon Cloud Environment.
Important: This release does not support having disk encryption for floating VDI assignments that use image VMs with attached data disks. Make sure the image that you plan to use in the assignment does not have data disks.
- Decide whether you want the ability to use NSX Cloud features with the desktop VMs. You must enable NSX Cloud management when creating the VDI multi-cloud assignment. You cannot later enable the assignment for NSX Cloud management after the assignment is created. The published image you select for this assignment must have the NSX agent installed in it. You must have installed the NSX agent before publishing the image. See NSX Cloud and Horizon Cloud Pods in Microsoft Azure and its subtopics.
Important: To use both NSX Cloud features and disk encryption, ensure the image's installed NSX agent is the latest agent version. Using disk encryption with previous versions of the NSX agent is not supported.
- When a pod is configured to have multiple VM subnets, you can decide whether you want those desktop VMs that are deployed in that pod's subscription to be connected to one of those VM subnets or to that pod's primary VM subnet (also known as the tenant subnet). When a pod that is running manifest 2298 or later has been edited to add additional VM subnets, you can specify use of those subnets for the assignment's desktop VMs that get instantiated for that specific pod. For this use case, you must verify that the VM subnet you want to use is listed on the pod's details page's Networking section in a
Readystate so that the subnet will available for you to select in the workflow steps. For details, see Overview of Using Multiple Tenant Subnets with Your Horizon Cloud Pod for Your Farms and VDI Assignments.
Important: When you specify use of a VM subnet for the assignment, the selected VM subnet remains in effect and cannot be changed after the assignment is created. Also, the total number of IP addresses provided by the selected subnets must be greater or equal to the specified Max VMs setting. For example, when selecting to have the assignment use the primary subnet or to use multiple VM subnets with a result of having 100 available IP addresses for the assignment, the Max VMs cannot exceed 100.
Procedure
-
In the left pane of the console, click Assignments and select the submenu option for VDI desktops.
-
On the Assignments page, click New and select the submenu option for desktops in Microsoft Azure.
The New Desktop Assignment window opens to the first wizard step.
- In the wizard, configure the required settings.
Note: You might have to use the scroll bar to see all the settings.
| Setting | Description |
|---|---|
| Desktop Type | Select one of the following:
|
| Assignment Name | Enter a user-friendly name for the assignment. As described earlier in this documentation topic, entitled end users will see a form of this assignment name on the desktop tile in the client they use to access their desktops. The name must contain only letters, hyphens, and numbers. Spaces are not allowed. The name cannot start with a non-alphabetic character. |
| Description | Enter an optional description for the assignment. |
| Select Pod(s) | Select the check box next to each pod that you want participating in this assignment. The assignment's desktop VMs get instantiated in the selected pods' subscriptions in Microsoft Azure. Note: As stated in the prerequisites section, each selected pod must have an image of at least one published image, with a Microsoft Windows client operating system. If a selected pod does not meet this requirement, the system will prevent completion of the wizard's next step, in which you specify the image from each participating pod. |
| Scope |
To specify where the broker can search for desktops in response to a user's desktop request, select one of the following options:
|
| Connection Affinity |
This setting specifies a certain geographic site as the default site for the user. When the user requests a desktop, the broker begins searching in the default site for available desktops. If no available desktops are found in the default site and no site restrictions are in effect, the broker continues searching for desktops beyond the default site.
Select one of the following options:
|
After you configure the Definition settings, click Next to proceed to the next page of the wizard.
- On the Desktops page of the wizard, configure the required settings.
Note: You might have to use the scroll bar to see all the settings.
| Setting | Description |
|---|---|
| Filter |
Set one or more filters to control the models available in the Models drop-down menu. You can filter models by type, series, number of CPUs, memory, and tags. For more information about selecting models, see Managing VM Types and Sizes for Farms and Assignments in the Horizon Universal Console, which describes the options on the VM Types & Sizes page (Settings > VM Types & Sizes).
To set a filter, you first select the criterion in the drop-down menu and then enter one or more desired values. By default, there is a single filter with the criterion 'Tag' and value 'Recommended'. You can edit this first filter and add more filters connected by And and Or operators. The following are the criteria you can use for filters and descriptions of the values you can enter for each. Type 
When you select this option, there is only value available in the second drop-down menu:
Series 
When you select this option, you can then select a series of models from a second drop-down menu. You can also filter this list by entering text in the Filter text box at the top of the list. CPUs 
When you select this option, you can then enter a CPU range. Important: For production environments, to avoid unexpected end-user connection issues, use VM models that have a minimum of two (2) CPUs. Memory 
When you select this option, you can then enter a range of memory in GBs. Tag 
When you select this option, you can then select a tag from a second drop-down menu. You can also filter this list by entering text in the Filter text box at the top of the list. Tags available in the drop-down menu are both hard-coded system tags and custom tags that you created on the VM Types & Sizes page (Settings > VM Types & Sizes). You can set additional filters by performing the following steps for each filter:
|
| Model | Select the model to use for the desktop instances. The menu only displays model choices that are available in all the selected pods participating in the assignment. This selection defines the set of underlying resources that are used when the desktop instances are created, in terms of capacity (compute, storage, and so on). Important: For production environments, select a VM model that has a minimum of two (2) CPUs. First-gen Horizon Cloud scale testing has shown that using 2 CPUs or more avoids unexpected end-user connection issues. Even though the system does not prevent you from choosing a VM model with a single CPU, you should use such models for tests or proof-of-concepts only. |
| Disk Type |
Select a supported disk type from the available options. The menu only displays disk type options that are available in all the selected pods participating in the assignment.
Disk type options are based on the model selected, and your Azure subscription and region. The following are some commonly available disk types.
|
| Disk Size |
Enter the OS disk size in GB for the VMs in this assignment.
|
| OS System | Specify the operating system of the VMs that you want to include in the assignment. Tip: This selection acts as a filter for the subsequent Image menu. Only images with the operating system selected here will be available for selection in the subsequent Image menu. |
| Domain | Select the Active Directory domain registered with your environment. |
| Encrypt Disks | Select Yes if you want the desktop instances to have encrypted disks.
Important:
|
| NSX Cloud Managed | Select Yes if you want to use features of NSX Cloud with the assignment's desktop instances. For a description of using NSX Cloud features with your desktops in Microsoft Azure, see NSX Cloud and Horizon Cloud Pods in Microsoft Azure and its subtopics.
Important:
|
| Image |
Select the image on each pod that you want to assign to end users. To view information about the selected image, click Details.
Only those published images in each pod corresponding to the OS System selection are listed here. A published image, sometimes called a sealed image or an assignable image, is one that was published to the system by converting a golden image into a desktop.
Note: If the error message "Please select a valid image to continue" appears when you attempt to select an image, there might be a problem with the image. Go to Inventory > Images to view the status of the problem image and perform the suggested remediation procedure.
Since you can select a different image to use for each pod participating in the assignment, end users might receive different session experiences based on how Universal Broker brokers resources from the assignment. For example, one user might receive a desktop from Pod A which uses a specific image. However, another user who receives a desktop from Pod B might have a different session experience based on the desktop image used by Pod B.
Important:
|
| VM Names Prefix | Base name for the desktop VMs created in this assignment. The VM names have numbers appended to this base name, for example, win10-1, win10-2. The name must start with a letter and can contain only letters, dashes, and numbers. The end users see this name when they go to access a desktop from this assignment. For example, when an end user runs Horizon Client to use one of the desktops, this name is the one displayed in Horizon Client. |
| Default Protocol | Select a default display protocol you want the end-user sessions to use. Circumstances might occur that cause another protocol to be used instead of the default protocol. For example, the client device does not support the default protocol or the end user overrides the default protocol selection. Note: For images with the Microsoft Windows 7 Enterprise operating system, RDP is the only supported choice. |
| Preferred Client | Select the preferred client used when end users start their desktops from the Workspace™ ONE™ platform's portal, either Horizon Client or a browser for Horizon Web Client. Note: For images with the Microsoft Windows 7 Enterprise operating system, Horizon Client is the only supported choice. |
| Do you have a Windows Client License | The wizard asks you to confirm you have an eligible license to use the Microsoft Windows operating system that is in the image and which will be in the desktop VMs. Follow the on-screen instructions. For a client operating system, Horizon Cloud sets the assignment's desktop VMs to use the Windows Client license type by default and you cannot change that setting. |
| Power Off Protect Time | Specify the number of minutes that you want the system to wait before automatically powering off a powered-on desktop. You can enter a value from 1 to 60. The default is 30 minutes. This protect time is used primarily for the situations where the system will automatically power off a desktop VM. You can use this Power Off Protect Time setting to tell the system to wait the specified time before starting to power off the VM to meet the threshold setting in the Power Management field. The system waits the time specified for the Power Off Protect Time before powering off the VM to match the configured schedule. The default wait time is 30 minutes. |
Optionally configure the advanced properties.
| Option | Description |
|---|---|
| Computer OU | Active Directory Organizational Unit where the desktop VMs are to be located. Enter the Active Directory Organizational Unit using the distinguished name, for example, OU=RootOrgName,DC=DomainComponent,DC=eng, and so on. The OU and each path in a nested OU can contain any combination of letters, numbers, special characters, and spaces, and can have a maximum of 64 characters.
If you must use nested Organization Units, see Considerations For Using Nested Active Directory Domain Organizational Units.
Note: If the Computer OU is set to CN=Computers, the system uses the default Active Directory Computers container for VMs. Your Active Directory might have this default container redirected to an organizational unit class container. |
| Run once script |
(Optional) Location of a script that you want run in the assignment's desktop VMs after the VM creation process.
Note: The script must end with a reboot step to reboot the VM. Otherwise, the end user will not be able to log in the desktop until doing a manual restart.
A sample reboot line as a Windows command is: shutdown /r /t 0
The reason why the script must end with a reboot step is due to the sequence when the script is run after the sysprep process. When the system creates a desktop VM for the assignment, the VM boots up and completes the sysprep process in the Windows operating system. When the sysprep process completes, the agent in the desktop VM reaches out to do the domain join. At the same time, the agent gets the script path you specify here. The agent sets the Windows RunOnce path (System run once) and then restarts the desktop VM. On the next restart, the system logs in to the Windows operating system using the local administrator account and runs the script. It is only after another subsequent restart, specified in the script, that the desktop VM is ready for a user to log in. |
| Log off Disconnected Sessions | Specify when you want the system to log the user out of a disconnected desktop session. Note: The sessions governed by the Log off Disconnected Sessions, Session Timeout Interval, and Max Session Lifetime settings are the user logins to the desktops' Windows operating system. These sessions are not the user logins in Horizon Client, Horizon Web Client, or Workspace ONE. The user's session begins when the user authenticates to the desktop's Windows operating system. |
| Session Timeout Interval | This time interval is the amount of time the end users' sessions can be idle before the system forces a log out from the desktops. This time-out applies to the logged-in session to the underlying Windows operating system. The time you specify here is different from the time-out settings that govern end users' Horizon Client or Horizon Web Client logged-in sessions. CAUTION: When the system forces the log-off in the underlying Windows operating system session, any unsaved data is lost. To prevent an unintended loss of data, set this interval high enough to accommodate the business needs of your end users. The default interval is one week (10080 minutes). Note: If no user activity occurs before the timeout interval is reached, a message appears in the desktop that indicates that the user will be logged off if they do not click OK in the next 30 seconds. If the logout occurs, any unsaved user data, such as documents or files, is lost. |
| Max Session Lifetime | Specify the maximum number of minutes the system should allow for a single user session. |
| Power Management Mode |
Note: This setting is only available if you have set the desktop type to Floating.
The power management settings are related to the thresholds at which the system automatically increases and shrinks the number of powered-on desktop instances in the floating VDI desktop assignment according to usage. When the usage increases above an upper bound, the system automatically powers up a new desktop instance. When the usage shrinks below a lower bound, the system shuts down deallocates desktop VMs as end users log out from the desktops.
The power management selections balance capacity cost with faster availability:
|
| Azure Resource Tags |
(Optional) Create custom tags to be applied to Azure resource groups. Azure resource tags are only applied to the resource groups, and are not inherited by the resources in the groups.
To create the first tag, enter information in the Name and Value fields. To create an additional tag, click Add and then enter information in the Name and Value fields that appear below the existing ones.
|
After you configure the Desktop settings, click Next to proceed to the next page of the wizard.
-
On the Capacity page of the wizard, make the following settings.
-
If you are creating a dedicated VDI desktop assignment, you can click Global Configuration for all Pods and configure settings that apply to all pods participating in the assignment.
Note:
- Settings that you make here can be overridden for a particular pod when you specify the per-pod settings in the following step.
- These settings do not apply to pods with manifest versions prior to 2474.0. If the assignment uses pods with manifests prior to 2474.0, a message will appear indicating that these settings will not be in effect for desktop VMs located in those pods.
| Option | Description |
|---|---|
| Max Desktop Deletions | This sets the number of desktop VMs that can be deleted in the assignment before counting them against the rate you set for Deletion Protection on the Settings > General Settings page. Select one of the following options from the drop-down menu.
|
| Custom Delete Count | If you selected Custom for Max Desktop Deletions, enter the number of additional desktop VMs that can be deleted before counting them against the rate you set for Deletion Protection. The number you enter must between 1 and 2000. |
Configure the required settings for each participating pod by clicking the arrow icon next to the pod in the pod list.
| Option | Description |
|---|---|
| Add Power Management Schedule |
To help optimize savings and performance of the desktop VMs in Microsoft Azure, you can optionally configure schedules to adjust the minimum number of powered-on desktop instances on a recurring weekly basis.
Note: In a Floating assignment, you can manage any of the desktop instances using the power management schedule. In a Dedicated assignment, you can only manage unassigned desktop instances with the schedule.
For example:
|
| When creating a floating VDI assignment - Min VMs, Max VMs | Specify the minimum number and maximum number of desktops you want in the selected pod for this assignment. When the assignment is first created, the system deploys the number of desktop VMs in the pod as specified in the Max VMs setting, and then powers off the desktop VMs except the number specified for Min VMs. Only the minimum number of desktop instances is initially powered on. As end-user demand increases, the system powers on additional desktops, up to the Max VMs number. Then as end-user demand shrinks, the system powers off the desktops, until it reaches the Min VMs number. A desktop must be free of a logged-in user session before the system will power it off. When you specify zero (0) for Min VMs, it indicates that you want the system to power off all the assignment's desktops until there is end-user demand for a desktop. Important: The subnets you specify in Specify VM Subnet(s) must accommodate the number of IP addresses required to match your Max VMs value. |
| When creating a dedicated VDI assignment - Min VMs, Max VMs |
Tip: This Min VMs setting for a dedicated VDI desktop assignment works slightly different from how the setting works for a floating VDI desktop assignment. For a dedicated VDI desktop assignment, the Min VMs setting refers to the unassigned desktops. When a desktop becomes assigned to a user, that desktop VM is no longer an unassigned desktop, and as a result, is not considered part of the set of desktops governed by the Min VMs setting. If the number of unassigned desktop VMs in the assignment are less than the value for Min VMs, you will observe that the number of powered-on VMs is less than the Min VMs value
|
| Quiescing VMs |
This setting comes into play for the use case where you edit the assignment to change the image that is specified for selected pod. The resulting behavior on the desktop VMs is slightly different for a floating VDI desktop assignment than for a dedicated VDI desktop assignment.
|
| Max Desktop Deletions Custom Delete Count | These options appear for dedicated VDI desktop assignments only. See the descriptions in the table in the preceding step. Changes you make to these settings for a selected pod override the corresponding settings that you made in the previous step, in the global configuration settings. |
| Specify VM Subnet(s) | Enable this toggle to select one or more specific subnets that are configured for the selected participating pod. These subnets are the ones defined in that pod's configuration, as described in Overview of Using Multiple Tenant Subnets with Your Horizon Cloud Pod for Your Farms and VDI Desktop Assignments. The assignment's desktop VMs will be connected to these subnets. After enabling the toggle, you can select the specific subnets from the displayed list.
When this toggle is switched off, the assignment's desktop VMs will be connected to the pod's primary VM subnet by default. Important:
|
After you configure the Capacity settings, click Next to proceed to the next page of the wizard.
- On the Users page, specify the users and user groups that you want to entitle to the assignment.
| Option | Description |
|---|---|
| Domain | Specify the Active Directory domain in which the users and groups reside. Note: Only cloud-configured domains are available for selection. |
| Find Users | Type the first few characters of the user or group name, and select the users or group of users from the list that appears. Your selection is added to the Selected Users / User Groups list. You can use the Remove button to delete a selected user or group from the list. |
| Assign Home Site |
Note: This setting is available only if you selected Home Site for Connection Affinity on the Definition page of the wizard.
Use this optional setting to configure a home site override for the selected user or group accessing this assignment. In this case, Universal Broker begins searching for available desktops in the override site instead of the user or group's configured home site.
For example, suppose that a user has a home site in San Francisco but you specify New York as the override site. When the user accesses the assignment, Universal Broker first searches for available desktops in New York instead of in San Francisco.
To specify a home site override, select the user or group and click Assign Home Site. The Assign Home Site menu displays all the available sites for pods participating in this assignment.
|
After you configure the Users settings, click Next to proceed to the next page of the wizard.
- On the Summary page, review the configuration and then click Finish.
Results
The system begins the process of configuring the desktop instances in the specified pods to provide VDI desktops to the selected users.
Note: Creation of an encrypted desktop VM takes approximately twice as long as creating a non-encrypted VM. As a result, the end-to-end time to complete creating a VDI desktop assignment that has disk encryption enabled is approximately twice as long as creating that VDI desktop assignment without disk encryption enabled.
What to do next
If the image for this floating VDI desktop assignment has applications that require opening special ports, you might need to modify this assignment's associated Network Security Group (NSG) in Microsoft Azure. For details about the NSG, see About Network Security Groups and VDI Desktops in a Horizon Cloud Pod.
If you specified NSX Cloud management for this assignment, you can use your NSX Cloud environment's Service Manager (CSM) to see that the desktop VMs are managed in NSX Cloud. Log in to your environment's CSM and navigate to Clouds > Azure > Instances. When that Instances page shows a status of Managed for the desktop instances, you can start implementing NSX policies on them.
Horizon Cloud Pods in Microsoft Azure - View Details About a VDI Multi-Cloud Assignment
You can use the Assignments page and its detailed subpages to monitor the status of a VDI multi-cloud assignment based on Horizon Cloud pods in Microsoft Azure.
Information on the Assignments Page
The following columns on the main Assignments page provide useful information about a VDI multi-cloud assignment. To show optional columns, use the customization button at the bottom left of the Assignments page.
| Information Column | Description |
|---|---|
| Configuration | Indicates the current progress of a request to change the assignment configuration. A configuration change can involve the creation of a new assignment or the editing or deletion of an existing assignment. When the change request has been propagated across all the participant pods in the assignment, this column displays the Complete status. |
| Health | Indicates the assignment's state of readiness. While the assignment undergoes configuration changes, such as when desktops are provisioned from participant pods during the creation of an assignment, this column displays the In Progress status with cycling arrows. To view details about the task in progress, click the assignment's name to open the assignment details page as described in the next section of this topic. When all configuration tasks on all participant pods are complete and the assignment is ready for use, this column shows the Online status with a green checkmark. |
| Site | Hovering over this column displays a list of all the sites associated with participant pods in the assignment. |
| Pod | This column displays the total number of pods participating in the assignment. Hovering over this column displays a list of all the participant pods. |
| Capacity | Total capacity of the assignment, expressed as an integer value. This value is calculated as the sum of the maximum number of virtual machines provided by all desktop pools associated with the assignment. For example, suppose that the assignment includes four desktop pools, and each of these desktop pools provides a maximum of one virtual machine (VM). The total capacity is calculated as follows: (Maximum VM count for the first desktop pool) + (maximum VM count for the second desktop pool) + (maximum VM count for the third desktop pool) + (maximum VM count for the fourth desktop pool) = 1+1+1+1 = 4. |
| User Group | This optional column indicates the total number of user groups that are entitled to the assignment. |
| Occupancy |
This optional column indicates the used or assigned portion of the assignment's total capacity, expressed as a percentage value.
The occupancy is based on users logged in through both global entitlements (such as this VDI multi-cloud assignment) and local entitlements at the pod level.
|
Information on the Assignment Details Page
To view more information about the health status of an assignment, click the assignment's name on the main Assignments page to open the assignment details page.
On the Summary tab of the assignment details page, you can view a list of the participant pods, including the individual health status of each pod.
To view more details about the health status of a pod, click the System Activity tab and select the name of the pod from the drop-down menu. The System Activity tab displays a list of current and recent tasks running on the pod and the status of each task. Clicking a task description in the list displays further details about the task's processes.
If the pod has a problem condition, a description of the problem appears in the System Activity tab. In this case, you can use the information to troubleshoot the problem condition and bring the assignment's Health status back to Online.
Was this page helpful?