Changing the Remote Desktop App Will Not Save an AVD Classic Deployment
An administrator can replace every old Remote Desktop client on their Windows endpoints and still face an access failure this week. The reason is that Microsoft has set two different deadlines for two different layers of Azure Virtual Desktop (AVD).
Support for the standalone Remote Desktop client for Windows installed from an MSI was extended until 28 September 2026 for Azure Government, Azure operated by 21Vianet and AVD Classic. The Microsoft client notice says public-cloud support ended on 27 March. Separately, Microsoft says AVD Classic retires on 30 September, after which connections to Classic resources will be blocked. These are established deadlines, not a newly announced policy.
A client deadline is not a service migration
The 28 September date is a support boundary for the Windows MSI client in the three remaining exception cases. Microsoft does not say that MSI connections automatically stop on that date. It is also a different product from the old Microsoft Store Remote Desktop app, the Remote Desktop web client and the built-in Windows Remote Desktop Connection client. Applying the MSI deadline to every RDP session would give administrators the wrong inventory.
Microsoft directs users of the MSI client towards Windows App. Its migration guide says the Windows MSI does not automatically upgrade to Windows App. It needs a separate installation and uninstall plan, although the two clients can coexist during user training. The guide also describes using AVD Insights to identify people still connecting with the MSI client. A software deployment count alone does not show which client people actually use.
The replacement is available for the two sovereign-cloud environments. Windows App release notes record general availability for Azure Government connections in December 2025 and for AVD in Azure China operated by 21Vianet in January 2026. Teams should test the native client with their own feed, sign-in policy and required session features. A browser fallback is not universal: Microsoft’s current limitations say Windows App on the web does not support AVD in Azure Government or 21Vianet.
AVD Classic has a second, harder deadline
Windows App for Windows does not support connections to AVD Classic. Installing it cannot convert a Classic tenant, host pool or application group into the current AVD service. Microsoft says Classic resources must move to Azure Resource Manager-based host pools before 30 September. After that service retirement, it says Classic connections will be blocked.
Microsoft provides automatic and manual migration instructions. The automatic route is not suitable for every estate: Microsoft says its tool creates service objects only in the US geography and cannot migrate deployments with more than 500 application groups. Teams outside those limits need to assess the manual route and the time needed to rebuild and test their resource assignments. Simply changing the user’s app is no substitute.
That creates two inventories, not one. Endpoint teams need to find the MSI installations and current users. AVD owners need to find Classic service objects, decide which host pools and published apps must survive, and prove that the new Resource Manager feed works from Windows App. The service migration, user assignment and client transition should be tested as one access path, including authentication, desktop and RemoteApp launch, and any redirection features the business uses.
What to check before the cutover
- Classify the estate. Separate Azure Government, 21Vianet, public-cloud AVD and AVD Classic. Check both the client on the endpoint and the service model behind each published resource.
- Move supported clients. Identify active MSI users with AVD Insights where available. Deploy Windows App to a pilot, confirm the right resources appear and connect, then plan the managed MSI removal.
- Escalate any Classic resources immediately. Confirm whether the automatic migration limits apply, choose the documented route and validate the Resource Manager host pools and user assignments before 30 September. An unfinished Classic migration has a different consequence from an unsupported MSI client.
- Test the real session. Check sign-in, desktop or RemoteApp launch, device redirection and support procedures from the intended native client. Keep the evidence of successful access tied to the new service resources.
BlackTree’s September Remote Desktop update coverage concerned a Windows servicing failure that disrupted sessions. This deadline is a client support transition coupled with a separate AVD service retirement. For an AVD Classic deployment, the decisive question is whether the host pool has moved, not whether the Windows App icon is present.
Sources
- Microsoft Remote Desktop client release notes, MSI support dates and replacement advice.
- Microsoft AVD Classic automatic migration guide, service retirement, connection block and tool limits.
- Microsoft AVD Classic manual migration guide, alternative migration route.
- Microsoft Windows App limitations, Classic and sovereign-cloud web limitations.
- Microsoft Windows App release notes, sovereign-cloud native-client availability.
- Microsoft Remote Desktop to Windows App migration guide, deployment and usage inventory.
