Azure Virtual Desktop Windows App Error 0x204 – RD Gateway TLS Connection Reset for Users in Pakistan

No public Microsoft advisory currently identifies a Windows App 2.0.1485.0 incident matching error 0x204 with RD Gateway TLS resets in Pakistan; continue using the working AVD web client while the tenant administrator opens an Azure support request for Microsoft to correlate the affected gateway, networks, and timestamps.

Current assessment

• Windows App’s published known-issues list does not include this Pakistan-specific TLS-reset scenario.^1^
• Version 2.0.1485.0 is a current public Windows release, so the supplied version alone does not establish a client-version defect.^2^
• The successful web connection shows that authentication, resource assignment, and the session host are operational. It does not prove that the native client’s gateway path is operational because the Windows client establishes a TLS connection to an AVD gateway selected through Azure Front Door. AVD requires TLS 1.2 or later and validates the gateway certificate after establishing the base TCP transport.^3^
• A successful TCP 443 test followed by a reset during the TLS handshake is consistent with an interruption beyond basic TCP reachability. It does not, by itself, establish whether the reset originates from Microsoft, an ISP/transit path, TLS inspection, or certificate-validation traffic.

Supported workaround

Use Windows App in a web browser until the native-client path is restored. Microsoft explicitly recommends the web client as a comparison and fallback when Windows App cannot connect.^4^

Repairing or resetting Windows App is unlikely to be the main resolution here because the same handshake failure affects multiple users and is reproduced outside the app. It can remain a later client-specific test, not the primary action.

One remaining path-specific check

Do not allow only [IP Address]. Microsoft requires AVD access by FQDN, including wildcard service endpoints, and states that there is no fixed AVD IP list that can replace those FQDN rules.^5^

In addition to *.wvd.microsoft.com over TCP 443, verify that TLS inspection, proxy policy, or ISP filtering is not blocking certificate-validation destinations over TCP 80, including those documented for AVD:

$targets = @(
  "oneocsp.microsoft.com",
  "www.microsoft.com",
  "ctldl.windowsupdate.com"
)
$targets | ForEach-Object {
  Test-NetConnection $_ -Port 80 |
    Select-Object ComputerName, RemoteAddress, TcpTestSucceeded
}

The required-endpoints documentation lists certificate endpoints over TCP 80 and notes that restricted networks might also need certificate-authority download and revocation-list destinations.^5^ A similar AVD community case was resolved by permitting OCSP traffic over port 80, but that is only applicable if these tests or a packet capture show certificate-validation traffic being blocked.^6^

If an organization uses TLS/HTTPS inspection, exclude the documented AVD service and certificate FQDNs from interception and retest. AVD’s client-to-infrastructure connections require supported TLS 1.2/1.3 ciphers.^3^

Escalate for gateway and routing investigation

The tenant administrator should:

1. Check Azure Service Health for the affected subscription and region; tenant-scoped incidents might not appear on the public status page.
2. In Azure Portal, open Help + support → Create a support request.
3. Select Azure Virtual Desktop as the service. Use the client/connectivity category; if Microsoft confirms a transit or Azure networking issue, the case can be routed internally to the appropriate networking team. Microsoft documents Azure support requests as the escalation path after client troubleshooting.^7^
4. Attach:
   • First and last failure times in UTC, beginning 4 November 2026.
   • Affected Pakistani ISPs and public source IPs.
   • Windows App version and Windows build.
   • Workspace/host-pool Azure region.
   • Both gateway FQDNs and the resolved IP.
   • Full curl -v or Schannel output.
   • A packet capture showing who sends the TCP reset.
   • Results from a materially different egress path, if available.
   • Confirmation that the web client succeeds for the same user and resource.

Only Microsoft Support can confirm a non-public service incident or correlate gateway telemetry with these timestamps. The supplied multi-user, ISP/path, gateway, and TLS evidence is sufficient to request that investigation without repeating DNS, local firewall, Wi-Fi/Ethernet, or basic TCP 443 checks.

References

1. Known issues and limitations of Windows App - Windows App
2. What's new in Windows App - Windows App | Microsoft Learn
3. Understanding Azure Virtual Desktop network connectivity
4. Basic troubleshooting for Windows App - Windows App | Microsoft Learn
5. Required FQDNs and endpoints for Azure Virtual Desktop
6. Remote Desktop client connection | Microsoft Community Hub
7. Troubleshooting overview, feedback, and support for Azure Virtual Desktop