My session hosts have been randomly indicating "Need Assistance" since the last MS update.

Question

My session hosts have been randomly indicating "Need Assistance" since the last MS update.

Bob Minteer 0

I have 9 multisession Windows 10 Hosts in my host pool. Ever since the updates pushed by Microsoft on Oct 15th, I have experienced increasingly horrible connectivity for my users attempting to log in as well as notable AVD delays once connected.

My session hosts seem to be randomly changing status from "Available" to "Needs Assistance". When they are in an Available status, all is well. But when they go to "Needs Assistance", that is when trouble begins.

I have run through some connectivity diagnostics and noted that when things are not "green", I see an error with "UrlsAccessibleCheck". Otherwise everything else "looks" healthy.

I uninstalled and reinstalled the AVD-Bootloader and AVD-Agent from:

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWrmXv

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWrxrH

...and I thought that took care of the issue. Until people started logging in this morning and were met with resistance from AVD or the orchestration or whatever the problem is.

I am running out of things to try (that make sense to me). Ideas ? Help ?

Ankit Yadav 4,555 Reputation points Microsoft External Staff Moderator

2025-10-21T20:16:08.4433333+00:00
If it doesn't help, kindly answer our below queries so that we can narrow down the issue better.

Can you confirm whether your session hosts have unrestricted outbound access to the internet over TCP 443?

Are you using a firewall, proxy, or network security group (NSG) that filters outbound traffic by domain or IP?

Have you validated that all required AVD service URLs (e.g. [rdbroker.wvd.microsoft.com], [rddiagnostics.wvd.microsoft.com]) are reachable from the host? (especially under the SYSTEM account) [see: Required FQDNs and endpoints for Azure Virtual Desktop - Azure Virtual Desktop | Microsoft Learn]

Are the failing hosts domain-joined and showing healthy status in Active Directory?

Have you checked the Windows Event Logs (Application and System) for errors from WVD-Agent, RDAgent, or AVD-Bootloader?

Are all session hosts running the same version of the AVD agent and bootloader?

Have you run the avdnettest.exe tool or similar diagnostics to identify which specific URL is failing? (see: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-desktop/troubleshoot-rdp-shortpath)

Also, please confirm while reinstalling AVD agent stack, you had removed it fully then installed it.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Himanshu Shekhar 1,350 Reputation points Microsoft External Staff Moderator

2025-10-22T07:56:53.35+00:00
@Bob Minteer

When session hosts are in Needs Assistance state, can you still successfully run: Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent\HealthCheckReport" and verify which specific URLs are failing?

Are the RDAgentBootLoader and Remote Desktop Services Infrastructure services running consistently on affected hosts during "Needs Assistance" periods?

Please Check Event Viewer > Application log for Event IDs from source "WVD-Agent" and during transition periods please share with us error codes that appears?

What is the current AVD agent version on all hosts? Please check Programs and Features or Get-WmiObject -Class Win32_Product
Bob Minteer 0 Reputation points

2025-10-22T14:41:17.86+00:00
I was actually able to log into one of the session hosts while it was in "Needs Assistance" this morning. This is what I get from the HealthCheckReport registry key:

This is the only error in the HealthCheckReport (everything else has error code = 0):

"UrlsAccessibleCheck": { "HealthCheckName": 4, "HealthCheckResult": 2, "AdditionalFailureDetails": { "Message": "{\"AccessibleUrls\":null,\"NotAccessibleUrls\":null,\"Context\":\"No information URLs accessibility: Operation cancelled.\"}", "ErrorCode": 1223, "LastHealthCheckInUTC": "2025-10-22T13:52:33.0993751Z" }, "AdditionalDetails": null, "IsProvisioningHealthCheck": false },

The RDAgentBootLoader and Remote Desktop Services Infrastructure services appear to be running consistently, but it is hit or miss to actually catch the VM's in the act of "Needs Assistance".

And... when I do, the session seems sluggish and less responsive (which I am investigating as well) which is likely due to it being unable to resolve the URL's at that moment. Then, when it recovers, all is well (like it's telling me "I'm not dead... I'm getting better... ugh).

The versions of the RDInfra are:

Remote Desktop Agent Bootloader: version 1.0.9023.1100

Remote Desktop Services Infrastructure Agent: version 1.0.12183.900

Remote Desktop Services Infrastructure Geneva Agent: version 46.24.3

Remote Desktop Services SxS Network Stack: version 1.0.2507.25400

As far as the Application Event Log, WVD-Agent entries go, I am seeing this (looks like once a day):

InitializeAndConnectWebSocketAsync clientWebSocket.ConnectAsync - returned successfully

Connected to broker. WebSocket State: Open

Accessible URLs:

d8de91b4-a729-4f04-a720-cb890d09c7f8.rdbroker-g-us-r1.wvd.microsoft.com

d8de91b4-a729-4f04-a720-cb890d09c7f8.rdbroker.wvd.microsoft.com

d8de91b4-a729-4f04-a720-cb890d09c7f8.rddiagnostics-g-us-r1.wvd.microsoft.com

mrsglobalsteus2prod.blob.core.windows.net

gcs.prod.monitoring.core.windows.net

southcentralus-shared.prod.warm.ingest.monitor.core.windows.net

southcentralus-qos.prod.warm.ingest.monitor.core.windows.net

Domain Status: NOT Domain Joined (Workgroup: WORKGROUP) Azure AD Status: Azure AD Joined Service Status: Name Status StartType ---- ------ --------- - RDAgentBootLoader Running Automatic - TermService Running Manual - Health Check Summary: - DomainJoinedCheck: Healthy - DomainTrustCheck: Healthy - FSLogixHealthCheck: Healthy - SxSStackListenerCheck: Healthy - **UrlsAccessibleCheck: Unhealthy** - MonitoringAgentCheck: Healthy - DomainReachable: Healthy - SupportedEncryptionCheck: Healthy - MetaDataServiceCheck: Healthy - AppAttachHealthCheck: Healthy - TURNRelayAccessHealthCheck: Healthy - RemoteInteractiveLogonRightCheck: Healthy - AADJoinedHealthCheck: Healthy` - CloudDeviceMonitoringAgentHealthCheck: Unknown
Ankit Yadav 4,555 Reputation points Microsoft External Staff Moderator

2025-10-22T18:47:48.03+00:00
Hello @Bob Minteer

Good job on finding the right time and checking up as per Himanshu's suggestions earlier.

Could you please confirm if you had run avdnettest.exe during the "Need assistance" state? If not, if possible, to find the next time kindly run that as well. (this can be help us confirm if the actual connectivity fails or it's just the agent health check logic that is failing)

Additionally, did you see high CPU or memory usage on the VM? (this could starve the VM to get the resources and cause these timeouts)

3.Also, check if there are any logs over C:\ProgramData\Microsoft\RDInfraAgent\Logs) if yes they can help us to find why the URL check failed.

Additionally, provide the details asked in the Private Message to assist you better.

1 answer

Your answer

Ankit Yadav 4,555 Reputation points Microsoft External Staff Moderator

2025-10-21T20:16:08.4433333+00:00

If it doesn't help, kindly answer our below queries so that we can narrow down the issue better.

Can you confirm whether your session hosts have unrestricted outbound access to the internet over TCP 443?

Are you using a firewall, proxy, or network security group (NSG) that filters outbound traffic by domain or IP?

Have you validated that all required AVD service URLs (e.g. [rdbroker.wvd.microsoft.com], [rddiagnostics.wvd.microsoft.com]) are reachable from the host? (especially under the SYSTEM account) [see: Required FQDNs and endpoints for Azure Virtual Desktop - Azure Virtual Desktop | Microsoft Learn]

Are the failing hosts domain-joined and showing healthy status in Active Directory?

Have you checked the Windows Event Logs (Application and System) for errors from WVD-Agent, RDAgent, or AVD-Bootloader?

Are all session hosts running the same version of the AVD agent and bootloader?

Have you run the avdnettest.exe tool or similar diagnostics to identify which specific URL is failing? (see: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-desktop/troubleshoot-rdp-shortpath)

Also, please confirm while reinstalling AVD agent stack, you had removed it fully then installed it.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Himanshu Shekhar 1,350 Reputation points Microsoft External Staff Moderator

2025-10-22T07:56:53.35+00:00

@Bob Minteer

When session hosts are in Needs Assistance state, can you still successfully run: Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent\HealthCheckReport" and verify which specific URLs are failing?

Are the RDAgentBootLoader and Remote Desktop Services Infrastructure services running consistently on affected hosts during "Needs Assistance" periods?

Please Check Event Viewer > Application log for Event IDs from source "WVD-Agent" and during transition periods please share with us error codes that appears?

What is the current AVD agent version on all hosts? Please check Programs and Features or Get-WmiObject -Class Win32_Product
Ankit Yadav 4,555 Reputation points Microsoft External Staff Moderator

2025-10-22T18:47:48.03+00:00

Hello @Bob Minteer

Good job on finding the right time and checking up as per Himanshu's suggestions earlier.

Could you please confirm if you had run avdnettest.exe during the "Need assistance" state? If not, if possible, to find the next time kindly run that as well. (this can be help us confirm if the actual connectivity fails or it's just the agent health check logic that is failing)

Additionally, did you see high CPU or memory usage on the VM? (this could starve the VM to get the resources and cause these timeouts)

3.Also, check if there are any logs over C:\ProgramData\Microsoft\RDInfraAgent\Logs) if yes they can help us to find why the URL check failed.

Additionally, provide the details asked in the Private Message to assist you better.

Answer 1

Hello @Bob Minteer

Verify the failing check and endpoint: You’ve identified the failing health check is UrlsAccessibleCheck, which means an essential URL for AVD connectivity or monitoring isn’t reachable. To pinpoint which URL, review the session host’s Event Log (Application log for sources like WVD-Agent or RDAgent) or use the Microsoft AVD connectivity test tool (avdnettest.exe) to see which endpoint fails.

Additionally, do verify that all the endpoints like below allowed:

Broker : rdbroker.wvd.microsoft.com
Diagnostics/Monitoring: rddiagnostics.wvd.microsoft.com (and region-specific variants), Azure Geneva monitoring endpoints, storage URLs for diagnostics
Azure AD and Token: login.microsoftonline.com, aadcdn.msftauth.net, etc., if applicable

All of these should be accessible over HTTPS (TCP 443). Update your firewall, network security group (NSG), or proxy rules to allow these URLs (no IP filtering, since addresses can change). Even if you believe outbound is “open,” some firewall appliances do deep packet inspection or have implicit denies for unknown domains.

Test connectivity as the SYSTEM account: The AVD agent runs under the Local System context, which might have different network access than an interactive admin user. A community expert found that if you RDP in and manually run tests, they can pass, but the agent could still be blocked due to how the system account connects. Use PsExec (Sysinternals) to open a prompt as System on an affected VM:

psexec -s -i cmd.exe

From that System command prompt, run a simple connectivity check to the known endpoints, for example:

PowerShell -Command "Invoke-WebRequest -Uri 'https://rdbroker.wvd.microsoft.com' -UseBasicParsing"

3. Reinstall the AVD agent components (do validate it was done in this way only): You already attempted this, which was a good step. Microsoft’s guidance for unexplained Needs Assistance states to fully remove and reinstall the AVD agent stack on affected VMs. Make sure the process was thorough:

Uninstall Remote Desktop Agent Boot Loader and Remote Desktop Services SxS Network Stack from Apps & Features (in that order).
Delete C:\Program Files\Microsoft RDInfra if any remnants remain. Reboot the VM.
Download the latest AVD Agent and AVD Boot Loader from Microsoft’s official links (the ones you used are correct for current version). Install the Agent .msi first, then the BootLoader .msi.
After a few minutes, verify in the Azure portal that the session host status goes to Available.

This ensures no corruption from the update. Reinstalling helps in many cases by resetting the health checks.

Let me know if this helps to solve your issue!!

Ankit Yadav 4,555 Reputation points Microsoft External Staff Moderator

2025-11-04T07:10:26.17+00:00

I'm glad to hear that your issue has been resolved. Your shared insights are greatly appreciated and will undoubtedly contribute to helping others in the community address similar challenges more effectively.

Share via

My session hosts have been randomly indicating "Need Assistance" since the last MS update.

1 answer

Your answer