Azure Virtual Desktop: Users Experience Random or Intermittent Disconnects — Seeking Assistance

Question

Azure Virtual Desktop: Users Experience Random or Intermittent Disconnects — Seeking Assistance

StuartMatthews-2360 0

Problem description

We are experiencing inconsistent Azure Virtual Desktop session behaviour in our Nerdio-managed environment. Users running long-running processes are experiencing unexpected AVD disconnects well before the intended idle period. Some existing hosts also have unexpected 30-minute session timeout values, while other disconnected sessions can remain on hosts for days without being logged off, consuming session/host capacity.

Environment

Azure Virtual Desktop with personal and shared session hosts managed through Nerdio Manager for Enterprise. Session hosts are Microsoft Entra joined and Intune managed. Legacy Intune 30-minute idle/disconnected-session policies were recently identified and removed due to potential conflicts with the intended Nerdio configuration.

What I've already tried

Compared effective session policies across existing, validation, and newly provisioned hosts; reviewed gpresult, Intune/MDM policy history, Event Viewer, AVD Scaling Plans and Nerdio automation. Controlled testing confirmed that Windows correctly enforces MaxDisconnectionTime when applied, but also reproduced unexpected AVD disconnect/reconnect events even while the physical client remained awake. A newly provisioned Personal Private VM receives the intended configuration, while an affected existing VM retains 30-minute values.

Current status

There appear to be three outstanding issues: determining why some existing hosts retain legacy 30-minute timeout values, identifying the cause of unexpected AVD disconnect/reconnect events, and understanding why some disconnected sessions are not being logged off at all. We also need Microsoft guidance on the correct session-timeout configuration to reliably support unattended processes running for at least two hours while still cleaning up abandoned sessions.

0 comments

1 answer

Your answer

Answer 1

Hi Stuart,

interesting case. From what you described, I’d probably treat these as three separate issues rather than assuming they all have the same root cause.

The first thing that stands out to me is that a newly provisioned host gets the expected settings, while some of the existing hosts still show the old 30-minute values. That makes me suspect the effective policy state on those machines rather than the Nerdio configuration itself.

I’d compare one affected host directly with the newly provisioned one, especially gpresult, the MDM diagnostic report and the values under:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

including MaxDisconnectionTime and MaxIdleTime.

Removing the old Intune policy is one thing, but I’d want to confirm that the setting is actually gone from the affected hosts and isn’t still being applied from another policy source.

For the unexpected disconnect/reconnect events, I’d look at that separately. If the client stays awake and the session suddenly reconnects, I’d correlate the exact timestamp with the AVD connection diagnostics and check which transport was being used. RDP Shortpath / UDP versus the TCP reverse-connect path would be interesting here, as would any Shortpath-related events in WVDCheckpoints.

The sessions that remain disconnected for days are another topic again. These are particularly worth cleaning up because AVD autoscale also considers disconnected sessions when calculating capacity. Microsoft recommends using Set time limit for disconnected sessions if those sessions should eventually be signed out.

For your requirement to keep unattended processes running for at least two hours, I personally wouldn’t simply set every timeout to two hours. I’d first define how long an idle but still connected session should be allowed to run, and separately how long a session should survive once it is actually disconnected.

So my next test would probably be:

affected existing host → newly provisioned host → compare effective policy/registry state → correlate an actual disconnect with AVD connection telemetry

That should at least help narrow down whether you have a policy issue, a transport issue, or a combination of both.

Kind regards
Marcus