AVD Session Hosts By Host Pools

The values that this measure reports and their corresponding numeric values are listed in the table below:

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the current status of the host pool. In the graph of this measure however, the same is represented using the numeric equivalents only.

Use the detailed diagnosis of this measure to view the friendly name of the host pool, host pool type, load balancer type, and maximum number of sessions allowed on the host pool.

Use the detailed diagnosis of this measure to know which session hosts are in the host pool, where they are located, and what the current status of each session host is. Unavailable session hosts in the pool can be identified in this process. The detailed diagnostics also help administrators pinpoint the session hosts where upgrade has failed, and those session hosts that are running an outdated OS, agent, or side by side stack.

Compare the value of this measure across host pools to know which host pool is overloaded with user sessions. Host pools that have or are about to reach their maximum session limit can also be quickly identified this way.

Use the detailed diagnosis of this measure, if enabled, to know the names and types of active sessions on the host pool. Who initiated the session, when, and to which session host in the pool, are also revealed.

Use the detailed diagnosis of this measure, if enabled, to know which sessions are in an Unknown state.

Use the detailed diagnosis of this measure, if enabled, to know which sessions are in an Disconnected state.

Use the detailed diagnosis of this measure, if enabled, to know which sessions are pending completion on the host pool.

The detailed diagnosis of this measure , if enabled, reveals the names and types of the logged of sessions.

The detailed diagnosis of this measure, if enabled, reveals the details of sessions where user profiles are dynamically attached to the computing environment. .

To know which hosts in the pool are powered off, use the detailed diagnosis of this measure.

Drain mode isolates a session host when you want to apply patches and do maintenance without disrupting user sessions. When isolated, the session host will not accept new user sessions. Any new connections will be redirected to the next available session host. Existing connections in the session host will keep working until the user signs out or the administrator ends the session. When the session host is in drain mode, admins can also remotely connect to the server without going through the Azure Virtual Desktop service.

To know for which session hosts in the pool the 'drain mode' has been set, use the detailed diagnosis of this measure.

The monitoring agent used by Azure Monitor often sends a heart beat from each session host every minute to indicate the availability of the session. The value of this measure represents the number of session hosts in a pool from which no such heartbeats were received - i.e., the number of hosts that are down.

Ideally therefore, the value of this measure should be 0. If a non-zero value is reported, then use the detailed diagnosis of this measure to identify the session hosts that have not sent any heartbeats during the last measurement period.

Since idle hosts unnecessarily drain a pool's collective resources, its best that the value of this measure is low at all times. If this measure reports an unusually high value, then use the detailed diagnosis of the measure to identify the idle hosts in the pool.

Ideally, the value of this measure should be 0. If a non-zero value is reported, then use the detailed diagnosis of this measure to know which hosts in the pool are disconnected from the broker.

Ideally, the value of this measure should be 0. If a non-zero value is reported, then use the detailed diagnosis of this measure to know which hosts in the pool are unavailable.

Ideally, the value of this measure should be 0. If a non-zero value is reported, then use the detailed diagnosis of this measure to know on which hosts the virtual desktop agent upgrade failed.

To know the hosts on which upgrade is in progress, use the detailed diagnosis of this measure.

To know the available hosts in a host pool, use the detailed diagnosis of this measure.

To know which hosts in the pool are currently not running any user sessions, use the detailed diagnosis of this measure.

If a session host is in the 'Needs assistance' state, it means that the session host didn't pass one or more of the following non-fatal health checks:

• Geneva Monitoring Agent health check:

  If the session host does not pass the MonitoringAgentCheck health check, you need to check the Remote Desktop Services Infrastructure Geneva Agent and validate if it's functioning correctly on the session host.

  • Verify if the Remote Desktop Services Infrastructure Geneva Agent is installed on the session host. You can verify this in the list of installed programs on the session host. If you see multiple versions of this agent installed, uninstall older versions and keep only the latest version installed.

  • If you do not find the Remote Desktop Services Infrastructure Geneva Agent installed on the session host, review logs located under C:\Program Files\Microsoft RDInfra\GenevaInstall.txt and see if installation is failing due to an error.

  • Verify if the scheduled task GenevaTask_<version> is created. This scheduled task must be enabled and running. If it's not, reinstall the agent using the .msi file named Microsoft.RDInfra.Geneva.Installer-x64-<version>.msi, which is available at C:\Program Files\Microsoft RDInfra.

• Azure Instance Metadata Service (IMDS) health check:

  If the session host does not pass the MetaDataServiceCheck health check, the service cannot access the IMDS endpoint. To resolve this issue, you need to do the following things:

  • Reconfigure your networking, firewall, or proxy settings to unblock the IP address 169.254.169.254.

  • Make sure your HTTP clients bypass web proxies within the VM when querying IMDS. We recommend that you allow the required IP address in any firewall policies within the VM that deal with outbound network traffic direction.

  If your issue is caused by a web proxy, add an exception for 169.254.169.254 in the web proxy's configuration. To add this exception, open an elevated Command Prompt or PowerShell session and run the following command:

  netsh winhttp set proxy proxy-server="http=<customerwebproxyhere>" bypass-list="169.254.169.254"

• URL health check:

  If the session host does not pass the UrlsAccessibleCheck health check, you need to identify which required URL your deployment is currently blocking. Once you know which URL is blocked, identify which setting is blocking that URL and remove it.

  There are two reasons why the service is blocking a required URL:

  • You have an active firewall that's blocking most outbound traffic and access to the required URLs.

  • Your local hosts file is blocking the required websites.

  To resolve a firewall-related issue, add a rule that allows outbound connections to the TCP port 80/443 associated with the blocked URLs.

  If your local hosts file is blocking the required URLs, make sure none of the required URLs are in the Hosts file on your device.

To know which session hosts are in the 'Needs assistance' state, use the detailed diagnosis of this measure. You can find which health checks failed in the Azure portal by going to the Session hosts tab and selecting the name of your session host.

When Azure Virtual Desktop (AVD) session hosts with FSLogix show as "not healthy," it usually indicates issues with the host's ability to connect to the FSLogix profile container or with the FSLogix agent itself. This can lead to login failures, slow logins, or profile corruption. Troubleshooting steps include checking FSLogix logs, verifying network connectivity, and ensuring proper configuration of FSLogix and Azure Virtual Desktop.

Here are some of the more common causes for FSLogix issues and their troubleshooting steps:

• FSLogix agent issues:

  • Verify that the FSLogix agent is running on the session host. Look for errors related to the RDAgentBootLoader or Remote Desktop Agent Loader in the event logs.

  • Ensure the FSLogix agent is correctly installed and up-to-date.

  • Confirm that the FSLogix services (e.g., FSLogix Application служба, FSLogix Office Container) are running.

• FSLogix profile container issues:

  • Ensure the VHDLocations setting in FSLogix is correctly configured to point to the Azure Files share or other storage location.

  • Verify that the session host can connect to the storage account and that there are no network issues (e.g., NSG rules, firewall rules) blocking access.

  • Ensure the session host has the necessary permissions (e.g., Storage File Data SMB Share Contributor) to access the file share.

  • Check the available disk space on the file server or storage account where FSLogix profiles are stored.

  • Examine the FSLogix log for errors related to profile attachment or access.

  • If using Azure Files, check the share settings, including access tiers and network settings.

  • Ensure that the correct file types and folders are excluded from antivirus scanning to prevent interference with FSLogix.

• AVD agent issues:

  • Confirm the AVD agent is running and healthy on the session host.

  • Make sure the AVD agent and bootloader are installed and running on the session host VM.

  • Ensure the session host is properly joined to the domain.

• Other potential issues:

  • Outdated or incompatible graphics drivers can cause black screens. Ensure the graphics configuration in the VM matches the remote session's requirements.

  • Microsoft is transitioning to modern authentication, which may cause issues if not properly configured with FSLogix.

  • If using endpoint protection, exclude FSLogix profile container file extensions to avoid issues.

To know which session hosts are in the 'FSLogix not healthy' state, use the detailed diagnosis of this measure.

When session hosts in Azure Virtual Desktop (AVD) fail to join the domain, it can lead to connection issues and prevent users from accessing their resources. This problem often arises during the initial provisioning of session hosts or after they have been created and added to a host pool. Several factors can cause this.

Here's a breakdown of common causes:

• Network Connectivity:

  • Ensure that NSG and firewall rules allow traffic to and from the domain controllers, especially on ports required for domain join (e.g., 88, 389, 445).

  • Confirm that the session host VMs can resolve the domain name by using ping or nslookup from the VM.

  • Investigate any potential network problems or routing issues that might be hindering communication between the session hosts and the domain controllers.

• Domain Join Configuration:

  • If using the built-in domain join extension, verify the domain name, OU path, and credentials specified in the extension settings.

  • If the built-in extension is failing, consider using a custom PowerShell script for domain join and add it as a custom script extension.

  • Confirm that the domain join account has the necessary permissions to join the VMs to the domain.

• Session Host VM Issues:

  • Verify that the Azure Virtual Desktop agent and bootloader are installed correctly and running on the session host VMs.

  • Examine the logs for the RD agent and bootloader for any error messages or warnings related to the domain join process.

  • Ensure that the session host VMs are registered with the AVD service and are able to report their status.

• Other Issues:

  • Ensure that the Key Vault is accessible to the AVD resources and that the necessary permissions are configured.

  • Review any recent changes to policies, configurations, or permissions that might have impacted the domain join process.

  • If using a custom script, consider adding a delay before the domain join script runs to allow the VM to fully initialize.

Troubleshooting Steps

• Check Session Host Status: In the Azure portal, navigate to your host pool and review the status of your session hosts. Look for any specific error messages related to domain join failures.

• Review Logs: Examine the logs for the domain join extension, custom script extension, and the Azure Virtual Desktop agent for detailed error information.

• Use PowerShell: Use the Get-AzVM cmdlet in PowerShell to verify the domain join status of your session hosts.

• Consider Restarting: In some cases, restarting the session host VM might resolve temporary issues.

By systematically addressing these potential issues, you can effectively troubleshoot and resolve domain join problems in your Azure Virtual Desktop environment.

To know which session hosts failed to join the domain, use the detailed diagnosis of this measure.

The SxS stack listener component is part of the Azure Virtual Desktop agent and is responsible for handling connections to the session host. If this component is not ready, it means the listener is not active, is not listening for connections, or is experiencing some other issue preventing it from functioning correctly.

A failed SxS stack listener check is considered fatal, meaning users will not be able to connect to the session host until it's resolved.

The value 0 is hence desired for this measure. If this measure reports a non-zero value instead, follow the troubleshooting steps outlined below:

• Check Session Host Status:

  • Go to the Azure portal and navigate to Azure Virtual Desktop > Host pools.

  • Select the relevant host pool and then the "Session hosts" tab.

  • Examine the status of your session hosts. A "Not responding" or "Unavailable" status often indicates a problem.

  • Also, check the individual session host health checks for more specific information about the SxS stack listener.

• Verify Agent and Listener Status:

  • Ensure the Azure Virtual Desktop Agent service is running on the session host VM.

  • Check the Application event log on the session host for event ID 3277 with "InstallationHealthCheckFailedException" in the description, indicating a problem with the stack listener.

  • Run the qwinsta command in an elevated command prompt on the session host. Look for the "rdp-sxs" listener in the output. If it's not listed, the SxS stack might not be installed or enabled.

• Restart the Session Host:

  A simple restart of the virtual machine can sometimes resolve temporary issues with the agent or listener.

• Reinstall the SxS Stack Component:

  If restarting does not help, you might need to manually uninstall and reinstall the SxS stack component.

• Check for Registry Issues:

  • The SxS stack relies on specific registry entries. Verify their values and ensure they are correct.

  • If registry keys are missing or have incorrect values, you might need to consult the official documentation or contact AVD support for guidance.

• Review AVD Logs:

  • Azure Virtual Desktop provides detailed logs that can help pinpoint the exact cause of the issue.

  • You can analyze these logs for more information.

• Consider Network Connectivity:

  • Ensure the session host has proper internet access and can communicate with Azure services.

  • Check for any firewall rules or network security groups that might be blocking the necessary connections.

• Check for Domain Trust Issues:

  If you are using domain-based authentication, verify that the session host has a valid domain trust.

To know which session hosts encountered the SxS stack listener not ready error, use the detailed diagnosis of this measure.