Installing the New App Cannot Migrate the Retired Service
Update, 26 October 2026: The deadlines have passed. An endpoint application cannot move Azure Virtual Desktop (AVD) resources. This review concerns the published retirement position, not a tested tenant outage or recovery.
Separate deadlines
Earlier this year, the Windows MSI client lost support on 28 September for Azure Government, 21Vianet’s Azure China cloud and AVD Classic; public-cloud support had ended on 27 March. Downloads and installation are now unavailable. That support deadline did not itself announce an automatic connection block.
Distinguish this package from the old Store app, the browser client and built-in Remote Desktop Connection. These are different products, not interchangeable entries in an inventory.
The replacement, Windows App, needs separate installation and removal of the old client. Both may coexist during training. Use AVD Insights to identify actual legacy-client users; a deployment count does not establish which software people use.
The two sovereign environments gained native replacement access in December 2025 and January 2026, respectively. The web replacement does not support either environment. Test the intended native feed, authentication policy and required features instead of promising a universal browser fallback.
The retired service
Documentation set 30 September as the retirement deadline, with connections blocked afterwards. The legacy tenant’s application groups, host pools and user assignments needed Resource Manager replacements; a client cannot create these or connect to retired resources.
The automatic tool restricts object creation to the US geography and supports at most 500 application groups. The manual route is not recommended for complicated, heavily stabilised configurations or estates with many users. Neither old guide guarantees recovery after retirement. Escalate unfinished resources and access failures to the service owner for an assessed plan.
Maintain two inventories: endpoint installations and active users; service resources, published applications and assigned users. Validate the resulting feed from the replacement, including sign-in, a desktop or RemoteApp launch and required device redirection. The endpoint and service changes must form one working access path.
Evidence needed before closing the change
- Classify the estate. Separate the three cloud environments and retired service model, checking both software and resources.
- Pilot the replacement. Find active legacy users using the usage evidence above, deploy to a pilot and confirm that the right resources appear and connect. Then manage removal of the old installer.
- Escalate unfinished migration. Confirm the documented route and tool limits, then verify the listed destination objects and their assigned users.
- Test the real session. Retain evidence of authentication, desktop/application launch, redirection and support procedures against the replacement resources. Check current release notes when selecting the pilot build.
Release history lists build 2.0.1485.0, published 23 October, correcting drive redirection when policy selects later-connected drives or specific letters. That change does not perform the separate service migration.
BlackTree’s September session-freeze coverage concerned an operating-system servicing failure. This article concerns a support transition and service retirement. A new application icon does not prove that its destination resources moved.
Sources
- Client support notice: exception dates and discontinued installer.
- Automatic route: retirement and tool constraints.
- Manual migration guidance: suitability caveats.
- Replacement limitations: classic-service and sovereign-browser exclusions.
- Replacement release history: native availability and current redirection correction.
- Endpoint transition guide: deployment and usage inventory.
