Home / The case of the failing W365 Flex SignIns

The case of the failing W365 Flex SignIns

31-10-2026 1697 words 9 minutes

Contents

Recently, I ran into an interesting issue with Windows 365 Cloud PCs where users experienced connection failures during sign-in.

What made the problem particularly confusing was that the initial connection to the Cloud PC was successful. Authentication worked, the RDP session was established, and then, during Windows sign-in, the connection suddenly disappeared. After looking at several connection logs and comparing failing and successful sessions, we found a strong correlation with the activation of our client-based VPN inside the Cloud PC.

This post describes what we found and how split tunneling appears to have resolved the issue.

The symptoms

During a problematic sign-in, the Windows 365 web client initially connected successfully.

The logs showed:

Successful connection to the Remote Desktop gateway
Successful TLS handshake
Successful Entra ID/RDS authentication
AADJ Authentication result: 0
RDP state changing to Connected

So far, everything looked healthy. Shortly afterwards, however, the connection broke.

A typical sequence looked like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
RDP Connected
    ↓
Windows sign-in starts
    ↓
Logon error
    ↓
8 missed heartbeats
    ↓
RD Gateway closes WebSocket
    ↓
WebsocketNormalDisconnect (63)
    ↓
Automatic reconnect

So, the connection wasn’t failing while initially contacting Windows 365 or authenticating the user. It was failing after the RDP connection had already been established. The actual Windows sign-in starts, and shortly after that the connection would break.

An interesting detail: reconnecting often worked

In several cases, Windows 365 automatically attempted to reconnect.

Sometimes reconnecting to the original SessionHost temporarily failed because the host was reported by the broker as being in drain mode. After several attempts, the broker could assign another SessionHost. That connection would then succeed.

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
SessionHost 1
    │
    ├── WebSocket connected
    ├── AAD authentication successful
    ├── RDP Connected
    │
    ├── Logon error
    │
    ├── 8 missed heartbeats
    │
    └── WebSocket disconnected
             │
             ▼
       Auto reconnect #1
       Host unavailable / drain mode
             │
       Auto reconnect #2
       Host unavailable / drain mode
             │
       Auto reconnect #3
       Host unavailable / drain mode
             │
       Auto reconnect #4
             │
             ▼
       SessionHost 2
             │
             ├── AAD authentication successful
             ├── RDP Connected
             ├── Windows sign-in continues
             └── Logged in

This made the problem look less like a straightforward authentication failure.

Enter the VPN client

The Cloud PCs use a client side VPN client. They run in a Microsoft Hosted Network, and therefore have no direct line-of-sight to our corporate network. We treat Cloud PC’s as laptops, being used remotely. Therefore, this VPN client is necessary to provide access to our corporate resources.

During Windows sign-in, the client becomes active and establishes its tunnel. That potentially changes the network path of traffic originating from the Cloud PC. That timing was interesting because it coincided with the moment at which we were losing the Windows 365 RDP connection.

It turns out, Microsoft actually documents this scenario. We should have RTFM.

According to Microsoft’s Windows 365 RDP optimization guidance, VPN and Secure Web Gateway solutions running on a Cloud PC can affect its RDP connectivity. Microsoft recommends optimizing the path and bypassing VPN/SWG solutions for relevant RDP traffic.

See:

Our hypothesis

This gave us the following working hypothesis:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Cloud PC starts
      ↓
Windows 365 RDP connection established
      ↓
User sign-in starts
      ↓
CATO client becomes active
      ↓
Network routing changes
      ↓
Existing RDP traffic is affected
      ↓
RDP heartbeats are missed
      ↓
RD Gateway closes the connection
      ↓
Windows 365 starts auto reconnect

An important distinction here is that the logs themselves don’t prove that VPN caused the routing interruption. What they do show is a loss of RDP connectivity during sign-in. The timing, combined with the VPN becoming active during that same phase and Microsoft’s recommendations for VPN/SWG configurations on Cloud PCs, made it a strong hypothesis worth testing.

Testing split tunneling

We therefore modified the VPN configuration so that the relevant Windows 365/RDP traffic would no longer be forced through the VPN tunnel.

For Windows 365, Microsoft documents RDP traffic including:

1
2
*.wvd.microsoft.com
TCP 443

For Azure public cloud, Microsoft also documents the following address ranges for the associated RDP connectivity scenarios:

1
2
40.64.144.0/20
TCP 443

and, for RDP Shortpath scenarios:

1
2
51.5.0.0/16
UDP 3478

with UDP also being used for STUN/direct connectivity scenarios.

The important design principle is not merely “allowing” this traffic through a firewall. The goal is to prevent latency-sensitive, long-lived RDP traffic from unnecessarily being sent through a VPN/SWG path where routing changes, inspection, or tunneling could interfere with the session.

What happened after changing the VPN configuration?

This is where things became interesting. After modifying the VPN configuration, sign-in immediately appeared much more stable.

A new connection trace showed:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
WebSocket connected
      ↓
AAD authentication successful
      ↓
TLS handshake successful
      ↓
RDP Connected
      ↓
Windows sign-in
      ↓
Logged in
      ↓
Session remains connected

More importantly, the errors that previously resulted in the actual disconnect had disappeared.

Before:

1
2
3
4
8 missed heartbeats
RD Gateway closes WebSocket
WebsocketNormalDisconnect (63)
Auto reconnect required

After:

1
2
3
4
5
No 8 missed heartbeats
No gateway WebSocket disconnect
No disconnect 63
No auto reconnect
Successful sign-in on the initial connection

So, it looks like smooth sailing from there.

Not every error disappeared

Interestingly, the successful trace wasn’t completely clean. We still encountered messages such as:

1
Logon Error: Failed(3) code 29

and some:

1
HttpChannel has network error

There was also a device activation failure for one redirected resource.

But more importantly: none of these errors caused the RDP session to disconnect.

The user successfully completed sign-in and the session remained connected. That also taught us something about the earlier troubleshooting. Initially, the Logon Error looked suspicious. However, seeing the same error during a successful session strongly suggests that this particular message wasn’t responsible for the actual RDP connection failure.

The much more relevant indicators were:

1
2
3
4
5
6
7
missed heartbeats
        ↓
WebSocket closed by RD Gateway
        ↓
disconnect 63
        ↓
auto reconnect

Those are the messages that disappeared after changing the VPN configuration. So, if you’re running into issues with session being disconnected during or shortly after sign-in, it’s worth checking the logs for missed heartbeats, WebSocket disconnects, and auto reconnect events. Oh, and check your VPN configuration ;)

RDP connectivity isn’t the only consideration

There is one more thing worth keeping in mind.

Windows 365 doesn’t only require an RDP connection. A Cloud PC also needs connectivity to Microsoft cloud services for management and operation. Depending on the configuration, that can include Windows 365, Entra ID and Intune-related service connectivity. Microsoft therefore documents Windows 365 network requirements separately from RDP optimization. If a VPN or Secure Web Gateway is installed inside the Cloud PC, it is worth validating both:

The RDP transport path
Cloud-side Windows 365 and device-management connectivity

This is especially relevant during first sign-in and provisioning scenarios such as Enrollment Status Page (ESP), where the device may simultaneously be communicating with several Microsoft services.

Lessons lea*ned

There were a few useful takea*ays from this investigation.

The Cloud PC can succssfully establish its RDP connectin before the Windows user session was completely initialized. A networking change during that window can therefore break an otherwise perfectly healthy connection.

2. Look at the sequence, not individual errors

A single Logon Error looked important initially. It became far less interesting when we later saw the same type of error in sessions that successfully completed sign-in.

The sequence of events was much more valuable:

1
2
3
4
Connected
→ missed heartbeats
→ gateway disconnect
→ auto reconnect

3. VPN routing inside the Cloud PC matters

Even when the underlying Windows 365 networking is Microsoft-managed, a VPN, proxy or Secure Web Gateway running inside Windows can influence traffic originating from the Cloud PC. That includes traffic supporting the remote desktop session itself.

4. Test before making broad policy changes

A scoped split-tunneling test is a good way to validate the hypothesis. Rather than immediately changing connectivity for the entire Cloud PC population, apply the exceptions to a limited test population and compare connection traces before and after the change.

In our case, the difference in the logs was quite clear.

You can also set up a small amount of ’test’ Cloud PC, with different provisioning policy, on which you don’t install the VPN client. If those Cloud PCs connect successfully without the VPN, it provides further evidence that the VPN routing was contributing to the connectivity issues.

Conclusion

The investigation started with what looked like an intermittent Windows 365 sign-in or authentication problem. The logs told a different story. Authentication succeeds, RDP Connects, and then connectivity can still fail due to network changes during the user sign-in process.

During sign-in, the connection stopped receiving heartbeats and the Remote Desktop gateway eventually closed the WebSocket connection. Because this coincided with the activation of the Client-side VPN client, we tested Microsoft’s recommendation to keep the relevant Windows 365 RDP traffic outside the VPN/SWG path. After making that change, the critical connection failures disappeared from our test trace and the user completed sign-in without requiring an automatic reconnect.

It is still too early to claim that every sign-in problem we encountered had the same root cause, and some non-fatal errors remain in the logs. But the results provide a strong reason to look carefully at VPN and SWG routing whenever a Windows 365 Cloud PC:

connects successfully intially;
disconnects during Windows sign-in;
reports missed RDP heartbeats;
receives a gateway WebSSocket disconnect; and
subsequently succeeds after one or more reconnect attempts.

Lessons learned: Sometimes the interesting part isn’t why the Cloud PC couldn’t connect. It’s what changed after it had already connected.