Troubleshooting for Administrators of Horizon Cloud Environments

You can troubleshoot issues that you might experience in ongoing operation of your Horizon Cloud environment.

Horizon Cloud - Collect Agent Logs Using the Horizon Universal Console

If this feature is enabled in your Horizon Cloud tenant, and when the Horizon Cloud pod in Microsoft Azure meets specific prerequisites, the Generate Log action will be available to use in the Horizon Universal Console on the imported VMs, farm host VMs, and VDI desktop VMs from that pod.

This feature is typically only used after you have filed a technical support request (SR), and in the course of responding to that SR, the assigned support team has determined that diagnostic log bundles from specific VMs are required to diagnose the issue. The term DCT bundle (Data Collection Tool bundle) is often used by the Horizon Cloud support team in reference to this type of log bundle.

Remember: As described in Tour of the Cloud-Based Horizon Universal Console, the first-gen console is dynamic and reflects features that are appropriate for the up-to-the-minute configuration of your first-gen tenant environment. Access to features described in this documentation can depend on factors including, and not limited to:

• Whether the feature depends on system code available only in the latest first-gen Horizon Cloud pod manifest, Horizon pod version, or Horizon Cloud Connector version.
• Whether access to the feature is in Limited Availability, as stated in the Release Notes at the feature's debut.
• Whether the feature requires specific licensing or SKUs.

When you see mention of a feature in this documentation and you do not see that feature in the first-gen console, first check the Release Notes to see if the feature's access is limited and the way you can request enablement in your tenant. Alternatively, when you believe you are entitled to use a feature that is described in this documentation and you do not see it in the console, you can ask your Horizon Cloud representative or, if you do not have a representative, you can file a service request (SR) to the Horizon Cloud team after logging in to Customer Connect.

Prerequisites and Requirements

• Pod-Related Requirements

  This feature is supported for Horizon Cloud pods in Microsoft Azure that are running pod manifest 2747.0 and later.

  Use of this feature requires the pod to have the staging type of file share that Horizon Cloud configures for use with the App Volumes features for Horizon Cloud pods in Microsoft Azure. When the Generate Log action runs, the system writes the log bundle to a directory within that staging file share for later retrieval using the console's Reports page. To verify the existence of this file share for a given pod, navigate to the pod's details page from the console's Capacity page. On the pod's details page, the File Share field indicates the existence of the pod's file shares, which should be two (2). Click the displayed hyperlink 2 and verify that the informational tooltip includes information about a staging type of file share. If the tooltip does not indicate existence of this staging type of file share, the Generate Log action will generate a message with an instruction to contact Horizon Cloud Support for assistance.

• VM-Related Requirements

  The Generate Log action is provided for the following types of VMs — imported VMs, farm host VMs, and VDI desktop VMs. For an imported VM, the VM must have completed the pairing process before you can run the Generate Log action on that VM. The pairing process is described in the pairing step of Creating Desktop Images for a Horizon Cloud Pod in Microsoft Azure.

  The minimum version of the VM's Horizon agent for which this feature can obtain logs is version 19.1. However, keep in mind that a particular pod manifest only interoperates with a specific set of agent versions. You must always ensure that the agent versions in your VMs are compatible with the pod's manifest version. For conceptual information about pod-agent interoperability, see Horizon Cloud Pod Updates — Steps For Continued Agents Compatibility and Support.

  The VM's agent must be running and reachable when you invoke the Generate Log action on the VM. The console must display Active for the VM's agent status.

About the Generated Log Bundle

The generated log bundle will include logs for all of the agents that are installed by the Horizon Agents Installer and that are currently installed on the VM at the time the Generate Log action is invoked on the VM.

When the Generate Log action is invoked on a VM, a system task begins running in the background to generate and collect the log bundle. This background task will take some time to complete. The console's Activity page displays the progress of the task and indicates when it is 100% completed, and a notification in the console is also created when the bundle is ready for downloading. When the bundle is ready, you use the Reports page's Logs tab to download the file to your local system.

After the log collection task completes in the VM, the background task copies the agent-related log bundles to the staging file share within the pod's Microsoft Azure subscription, the file share that Horizon Cloud configures for use with the App Volumes features. The average size of the log bundle is 900 MB, and can approach 2 GB.

To minimize the space used in that file share, each generated log bundle has a one-hour retention time, beyond which the system will delete the file. The Reports page's Logs tab reports the expiration time for each generated log bundle.

Generating and Downloading the Agent Log Bundle

1. Use the Generate Log action on the intended VM.
2. Check the console's Activity page to see when the activity of generating the log bundle is completed.
3. Download the log bundle file to your local system from Reports > Logs.

To save space in the staging file share, you can use the Delete action to delete the bundle before its expiration time.

Required Administrator Actions When the Disk Size for a Farm or VDI Desktop Assignment is Increased

When you create or edit a farm or a VDI desktop assignment, you have the option of increasing the OS disk size value. When that option is used, the OS disk of each VM in that farm or assignment is created at that size. However, as a result of default behavior of VMs in Microsoft Azure, even though the VM's disk is expanded, the partition containing the C drive is not expanded to encompass the entire disk. That new space on the VM's disk is unused until you take actions in the VM to expand the C drive partition to encompass the new space.

Microsoft provides several ways to expand the partition to cover the full disk. We haven't tested the following Powershell commands and they are given only as an example of one way the expansion might be achieved using a script. You must determine the method that is most appropriate for your organization.

$size = (Get-PartitionSupportedSize -DiskNumber 0 -PartitionNumber 2)
Resize-Partition -DiskNumber 0 -PartitionNumber 2 -Size $size.SizeMax

This example assumes the disk number is 0 and partition number is 2. More information about these Powershell commands is available at https://docs.microsoft.com/en-us/powershell/module/storage/resize-partition?view=win10-ps.

Cannot Successfully Log In at the First Login Screen of the Horizon Universal Console

When Cloud services is under maintenance, you are not able to log in to Horizon Cloud's administrative console.

You try to log in to Horizon Cloud at https://cloud.horizon.omnissa.com, which by design redirects to authenticate with the Cloud Services login at https://connect.omnissa.com. Even though the login screen does not indicate any reason, you find when you enter valid account credentials into the login screen, the attempt fails.

Login authentication relies on authenticating account credentials with Cloud Services. If that service is unable to complete the necessary authentication requests, then logging in to the console during that period fails.

Procedure

1. If you encounter issues logging in to the console's main login screen, check the Horizon Cloud First Gen status within the Workspace ONE Status page https://status.workspaceone.com/ to see the latest system status.

   On that page, you can also subscribe to receive updates.

Convert to Image Task Fails with Timeout Error Even After Addressing the Logged Microsoft Windows Sysprep Errors

Even though you have taken steps to prevent Microsoft Sysprep issues from occurring when you convert your image VM to a published image, the conversion task times out in a subsequent attempt.

In the first attempt to publish the image, in the Activity page, you see that the image conversion process fails with a timeout error because of Microsoft Sysprep issues related to appx packages. After you follow the optimization steps described in Customize the Imported VM's Windows Operating System and address any issues described in the Microsoft Sysprep error logs, you try to convert the image. In this second attempt, you see messages in the Activity page as "Waited 20 minutes for virtual machine to power off: Convert the image back to the virtual machine" .

This situation happens because the second attempt to run the Microsoft Sysprep process is hung or not responsive. Use the following steps to work around the issue.

Procedure

1. Ensure that you address the Microsoft Sysprep issues according to the error messages in the Microsoft Sysprep error logs and Microsoft KB 2769827.

2. In the image VM, examine the Horizon Agent service and ensure it has its startup type set to Automatic.

   If the image is located in a pod with a manifest earlier than 1600, the VM will also have the DaaS Agent service. Verify that the DaaS Agent service has its startup type set to Automatic.

3. Reboot the image VM.

4. Try the conversion process again on the rebooted VM.

For a Windows Server 2012 Image, Convert to Image Task Fails with Timeout Error

Sometimes after you have installed applications into a Windows Server 2012 image VM to customize it before running the publishing workflow, the publishing process fails with the error message about timing out after 20 minutes.

After installing applications into the Windows Server 2012 image VM, logging off the VM, and then starting the publishing workflow, sometimes the workflow fails with the VM powering off while the Microsoft System Preparation (Sysprep) process is running.

Procedure

1. Ensure that you address the Sysprep issues according to the error messages in the Sysprep error logs and Microsoft KB 2769827.

2. In the image VM, examine the Horizon Agent service and ensure it has its startup type set to Automatic.

   If the image is located in a pod with a manifest earlier than 1600, the VM will also have the DaaS Agent service. Verify that the DaaS Agent service has its startup type set to Automatic.

3. Reboot the VM.

4. Try the conversion process again on the rebooted VM.

Notifications When the Primary Domain-Bind Account is Locked Out

When Horizon Cloud detects an authentication failure due to a locked primary domain-bind account, a notification is displayed in the administrative console to alert you to remedy the state of the account. The system uses the primary domain-bind account as a service account to connect to the Active Directory (AD) server and query Active Directory.

Each time an administrator successfully logs in to the console, the system checks whether the primary domain-bind account is in a failed or inactive state. If the system determines the account is in a failed or inactive state, a notification is created. When the notification is created, it is added to the Notifications page and is reflected in the count on the bell icon located in the upper right corner of the console (). You can read the notification details by clicking the bell icon or by navigating to the Notifications page.

Note: The connection state for the connection between the system and the AD server is cached for 15 minutes. As a result, it might take up to 15 minutes from the time the primary domain-bind account goes into a locked-out state until the notification is reflected in the console. For example, if you log in to the console, and then manually locked out your primary domain-bind account in your AD server, it might take up to 15 minutes for the notification to display in the console. Similarly, if you see the lockout notification in the console and then fix the account in your AD server, the console might continue to show the account lockout notification for up to 15 minutes after the fix.

If the primary domain-bind account becomes locked out, the system falls back to use an active configured auxiliary domain-bind account to authenticate the connection to the Active Directory server. When you see a notification that the primary domain-bind account is locked out, you should take action to remedy the state of the primary domain-bind account to ensure successful system connection continues over time.

New Farm Remains In Progress

You initiate creation of a new farm from the Farms page and the system begins creating the farm and its RDSH virtual machines (VMs). However, even after thirty minutes have passed, the page shows the farm's status is still in progress. When you drill into the farm details page, you see that one of its VMs is in offline status.

Even though the other VMs in the farm show online status, the farm creation process cannot complete because one VM continues to show offline status.

A temporary network connection loss causes the VM's state to show as offline in Horizon Cloud, preventing completion of the farm creation workflow.

Procedure

1. Navigate to the farm's Session Hosts tab.

2. Select the check box next to the offline VM and click Delete.

   The system deletes the VM. Then after a few minutes, the system automatically recreates the VM, it completes coming online, and the farm changes to online status.

Windows Error Message Appears When Trying to Connect to a Desktop from a Floating VDI Desktop Assignment

When an end user tries to connect to a desktop from a floating VDI desktop assignment, a Windows message appears that states Windows couldn't connect to the System Event Notification Service service. Please consult your system administrator.

After the user sees this message and clicks the displayed OK button, the session might disconnect. Sometimes after clicking OK, the user can log in to the desktop. Usually after clicking OK, the user can try to log into the desktop again and the second attempt is successful.

This issue is a known Microsoft Windows issue that is described at this page at answers.microsoft.com.

When True SSO is Configured and User Sees Message About Revocation Status of Certificate

When True SSO is configured, an error message displays during log in when the CRL is incorrect.

End user's screen at desktop launch displays a message along the lines of "The attempted logon is invalid. This is either due to a bad username or authentication information. The revocation status of the certificate used for authentication could not be determined."

When True SSO is configured, this problem can result from a problem with the CRL URL endpoint.

Results

Validate the configured CRL is correct by directly accessing the CRL URL using a browser. You can see the configured CRL in the certificates created when authenticating with True SSO. If that access fails, verify that the URL is correct and that the server serving that revocation list is operating and functioning correctly.

When Your Pod is Not Yet Updated to Manifest 1230 or Later, How to Configure the Ability for Domain Accounts to Remote Connect to the Imported Image

Starting with pod manifest version 1230 and later for pods in Microsoft Azure, domain accounts can direct connect to image virtual machines that have the agent software installed. Prior to pod manifest 1230, the agent software installed in a domain-joined VM prevents domain accounts from directly connecting to that VM. Starting with pod manifest 1230, you can use a domain account to log in and customize the image VM. However, if your pod is at a manifest earlier than 1230, you can use these steps to configure the ability for domain accounts to remote connect to the imported image.

So that you can customize the image for your organization's needs, you must be able to remotely connect to and log in to that image's virtual machine located in Microsoft Azure. If the image VM is joined to an Active Directory domain and your organization has a policy that prevents use of local administrator accounts on domain-joined VMs, you will not be able to log in to the image VM until you configure the DaaS Direct Connect Users local group with those domain accounts you want used for customizing the image.

You connect to the image VMs in Microsoft Azure using your Remote Desktop Protocol (RDP) software. As part of the overall process of creating the image VM, these items are put in place:

• The VM is always joined to the domain when it was created either using the Import Virtual Machine wizard prior the December 2019 service release. The VM is also joined to the domain when manually created and you explicitly joined it to the domain, or it was created using the Import Virtual Machine wizard after the December 2019 service release and you selected the wizard option to join the domain. Prior to the December 2019 service release, the Import Virtual Machine wizard always automatically joined the VM to the domain.
• The Horizon agent software is installed in the VM's Microsoft Windows operating system.

By default, the agent software prevents using any account to RDP to the VM's guest Microsoft Windows system other than the VM's local administrator account with which the agent software was installed. For example, when you try to RDP to the image VM using a domain administrator account that is a member of the local Administrators group, even though the connection is made initially, as the Microsoft Windows session starts, a message is displayed. The message states that direct connection to your virtual desktop is not allowed.

However, some organizations typically have policies that prevent use of the local administrator account on domain-joined VMs. To enable providing domain accounts with the ability to RDP and log in to customize the image VM, installing the agent software also creates a local group named DaaS Direct Connect Users. This group does not have local administration rights. The agent allows domain accounts in this group to connect to the desktop using a direct RDP connection. The DaaS Direct Connect Users group is empty when created. To give the RDP capability to those domain accounts you want used to customize the image, you add those domain users to the DaaS Direct Connect Users local group.

The following screenshot is an example showing the DaaS Direct Connect Users group in the Local Users and Groups window on a image VM that was created using the Import Virtual Machine from Marketplace wizard.

When you cannot direct connect to the VM using the local administrator account, you use a Group Policy Object (GPO) policy in your Active Directory environment to add domain accounts to the DaaS Direct Connect Users group. The following steps describe using the GPO policy's Restricted Groups - Members Of method for adding members to the DaaS Direct Connect Users group on the domain-joined VM.

1. In your Active Directory environment, create a new GPO.
2. Right-click on the GPO and select Edit.
3. In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups.
4. Right-click Restricted Groups and select Add Group.
5. In the Add Group box, type DaaS Direct Connect Users and click OK.
6. In the properties dialog, use the Members of this group area and its Add button to add those domain accounts that you want able to connect to the image VM.
7. When you are finished adding accounts into the Members of this group area, click OK to close the properties dialog.
8. Close the Group Policy Management Editor and the Group Policy Management Console.
9. Link the newly created GPO to the same domain that is used for the image VM.

After the new GPO is linked to the domain, you can use one of those specified domain accounts to RDP to the image VM and customize it. Follow the steps as described in Customize the Imported VM's Windows Operating System and its subtopics.