Windows Server

Windows Server 2016 Remote Desktop Services and RD Gateway: Upgrade Order and Steps

Windows Server 2016 Remote Desktop Services and RD Gateway: the documented upgrade order, migration limits, cmdlets, rollback points and outage mistakes.

Published 06 November 2026

Remote Desktop Services is a set of cooperating servers, not one machine, and Microsoft's documentation treats it that way: the order in which you touch the pieces matters more than the method. This guide covers a Windows Server 2016 Remote Desktop Services (RDS) deployment, including RD Gateway, with the sequence Microsoft documents, the cmdlets that help, the rollback point at each stage, and the mistakes that lock users out. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Either.

Microsoft documents both an in-place upgrade and a migration, but the order is strict: Connection Broker first, licensing before Session Hosts, and a mixed-version Connection Broker setup is not supported.

Which route you choose depends on the role service. Microsoft's migration article says only RD Web Access, RD Gateway and the licensing server support a direct move to a newer Windows Server. For the Connection Broker, Session Hosts and Virtualization Hosts you upgrade first, then migrate data and licences.

Who this is for and what changes on the end-of-support date

This is for anyone who runs RD Session Hosts, a Connection Broker, RD Web Access, an RD Gateway or an RD Licensing server on Windows Server 2016, from one session host to a farm with a clustered broker.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

Remote Desktop servers are where users, internet traffic and credentials meet, so unpatched RDS is a worse position than most roles. On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Decision table

Option	What Microsoft documents	Fit for RDS and RD Gateway
Stay and buy ESU	Azure Arc ESU: Critical and Important updates for up to three years, through 2030, billed from 13 January 2027; needs Software Assurance or an equivalent subscription	A temporary bridge, not a plan; no price is published on those pages, so get a quote
In-place upgrade	RDS upgrade flow: Connection Broker, then RD Licensing, Session Hosts, Virtualization Hosts, with RD Web Access and RD Gateway at any time	Supported for all role services, but the Connection Broker upgrade takes the deployment offline
Side-by-side migration	Migration guidance: RD Web, RD Gateway and Licensing can move directly; other components are upgraded first, then data and licences are migrated	Best for the edge roles (Web, Gateway, Licensing)
Move to Azure	Azure Migrate can migrate VMs, including Hyper-V VMs, to Azure, with an optional Windows Server upgrade during migration	Moves the servers, not the RDS rules; the same order still applies

On versions: Microsoft's RDS upgrade article says you can upgrade by two versions at a time, for example Windows Server 2019 to 2025. Its general upgrade-path article allows more for non-clustered servers going to 2025. For RDS, follow the RDS article: from 2016, plan 2016 to 2022 and then 2022 to 2025, or build new servers.

Steps, with the rollback point

Inventory the deployment. On the Connection Broker or management server run Get-RDServer to list every role service and server, Get-RDSessionCollection and Get-RDSessionHost for collections and hosts, and Get-RDCertificate for the four deployment certificates. Record the licensing mode and the RD Licensing server with Get-RDLicenseConfiguration. Note the RD Web customisation in IIS, because Microsoft warns an upgrade can reset IIS properties.
Check the Connection Broker design. If you run active/active brokers, Microsoft's flow is to remove all but one from the deployment, upgrade that one in place, then upgrade the others offline and reapply them. The deployment is unavailable while the brokers are being upgraded. Mixed-version brokers are not supported, and the migration article requires the broker to be configured for high availability to be migrated.
Back up, then schedule the outage. Take a backup or checkpoint of every broker (and its database), plus exports of the deployment certificates (Microsoft's certificate step exports to PFX with the private key). Rollback point: this backup, since the broker upgrade is the step you cannot do live.
Upgrade the Connection Broker. Upgrade in place, as in step 2. Microsoft notes that once the brokers run the newer Windows Server version, the deployment keeps working even though the other servers are still on the previous version, and a newer broker can serve session collections with older Session Hosts.
Upgrade the RD Licensing server before the Session Hosts. An older licence server works with newer hosts but can only process CALs from the older Windows Server version, so check your CAL version before the Session Hosts move.
Drain and upgrade the Session Hosts in steps. Stop new connections with Set-RDSessionHost -SessionHost host01.contoso.com -NewConnectionAllowed No, check Get-RDUserSession, let sessions end, upgrade or rebuild the host, and return it with Set-RDSessionHost ... -NewConnectionAllowed Yes. A session collection of hosts with mixed Windows Server versions is not supported, so move a collection as a whole or build a new one.
Migrate the edge roles directly. For RD Web Access and RD Gateway, join the new servers to the deployment, install the role, use the IIS Web Deploy tool to copy the site or endpoint settings, migrate the certificates, then remove the old servers from the deployment. For RD Gateway, remove Network Access Protection policies first: Windows Server 2016 and later does not include them, and the upgrade wizard blocks and writes the policy list to a text file on the desktop until they are deleted in Network Policy Server.
Migrate licensing. Migrate the RDS CALs from the source to the destination, edit Deployment Properties in Server Manager to list only the new licensing servers, deactivate the source in Remote Desktop Licensing Manager (right-click, Advanced, Deactivate Server), then remove it from the deployment.
Update certificates. After migrating certificates, set them for RD Connection Broker single sign-on, RD Connection Broker RDP file publishing, RD Gateway HTTPS and RD Web Access HTTPS with Set-RDCertificate, and confirm with Get-RDCertificate.
Validate and retire. Sign in through RD Web Access and through the gateway from outside, check licensing, and keep the old servers powered off but intact for one business cycle before deleting them. If you upgrade RD Web Access a second time and it fails, Microsoft documents a missing registry key (HKLM\SOFTWARE\Microsoft\Terminal Server Web Access\IsInstalled) as a known cause.

Mistakes that cause outages

Upgrading Session Hosts before the Connection Broker. The documented order exists because the broker decides what the rest can do.
Running brokers on two versions. Microsoft states this is unsupported; plan for an outage window.
Forgetting the licence server. A licence server older than the CALs you hold cannot hand them out.
Leaving NAP policies on the gateway. The upgrade blocks until they are removed.
Losing RD Web customisation. IIS settings may reset; copy them first.
Mixed-version collections. Not supported for Session Hosts or Virtualization Hosts.
Wrong or expired certificates. All four deployment certificates must be updated after a move, or users see warnings or cannot connect.
Forgetting profile storage. If user profile disks moved with a file server, update the collection's User Profile Disks location property, which Microsoft says must keep the same relative path.

Checklist

Deployment documented: brokers, hosts, web, gateway, licensing, certificates, CAL version
Backups and certificate exports taken; broker outage scheduled
Broker upgraded first, then licensing, then Session Hosts, then Virtualization Hosts
Edge roles migrated or upgraded; NAP policies removed from gateways
Certificates updated for all four uses; external sign-in tested
RDS CALs migrated and the old licence server deactivated
Old servers kept offline for one business cycle
Finish before 12 January 2027

Sources

Checked 6 November 2026.

Windows Server 2016 on Microsoft Lifecycle
Extended Security Updates for SQL Server and Windows Server
Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
Product Lifecycle FAQ: Extended Security Updates
Upgrade Remote Desktop Services deployments (order, mixed-version limits, NAP, known issue)
Migrate your Remote Desktop Services deployment (direct migration of Web, Gateway, Licensing; certificates)
Upgrade and migrate roles and features
Plan your Windows Server upgrade path
Migrate Hyper-V VMs to Azure with Azure Migrate

General planning information, not a design for your environment. Test the order in a lab first.