Picture this: You’ve stepped into an IT environment at MuraliPalla.com, where a physical Domain Controller (DC) is moonlighting as a Remote Desktop Services (RDS) host. It works fine—until the day it doesn’t. Suddenly, sluggish logins, looming security audits, and the dreaded task of upgrading the DC turn your comfortable IT life into a juggling act of risks and downtime.

 

In this guide, I’ll share a structured approach to safely migrate RDS from a Windows Server 2019 Domain Controller, upgrade legacy DCs, and convert physical infrastructure into virtual machines, ensuring minimal downtime and maximum reliability. I’ll also include real-world scripts and practical tips that have saved me countless hours during migrations.

Why Running RDS on a Domain Controller Is a Bad Idea

• Security Risks: Exposing port 3389 on your DC makes your infrastructure vulnerable.
• Performance Issues: Resource conflicts between DC and RDS roles.
• Maintenance Headaches: Upgrading or demoting a dual-role server risks extended downtime.

The Migration Blueprint

Current Environment at MuraliPalla.com:

• DC1: Server 2019 (Virtual)
• DC2: Server 2016 (Virtual, DNS/DHCP)
• DC3: Server 2019 (Physical, DC + RDS host)

Migration Goals:

1. Migrate RDS from DC3 to a new Server 2022 member server (RDS-NEW).
2. Upgrade DC2 from Server 2016 to Server 2019.
3. Demote DC3 and convert it to a VM, retiring physical hardware.

Phase 1: Preparing for Migration

Inventory and Backup

Get-RDSessionCollection | Select CollectionName, @{Name="Users";Expression={(Get-RDSessionUser -CollectionName $_.CollectionName).User}}

wbadmin start systemstatebackup -backuptarget:E:
Export-RDConfiguration -Path "C:\RDS_Backup.xml"

Deploy a New RDS Server

Set up a clean Windows Server 2022 (RDS-NEW), fully updated and domain-joined, but don’t redirect DNS yet.

Phase 2: Moving RDS Off the DC

Step 1: Update DNS and Connection Broker

Set-RDConnectionBrokerHighAvailability -ConnectionBroker "RDS-NEW.MuraliPalla.com" -ClientAccessName "rds.MuraliPalla.com"

Step 2: Import RDS Collections and Certificates

Import-RDConfiguration -Path "\\DC3.MuraliPalla.com\C$\RDS_Backup.xml" -Force
Set-RDCertificate -Role RDGateway -ImportPath "C:\Certificates\rdgateway.pfx" -Password (Read-Host -AsSecureString)

Step 3: Comprehensive Testing

Test-NetConnection -ComputerName RDS-NEW.MuraliPalla.com -Port 443

Check RD Web functionality at https://rds.MuraliPalla.com/rdweb and inspect Event Viewer logs carefully.

Phase 3: Upgrading the 2016 DC

Prepare Active Directory and Upgrade

adprep /forestprep
adprep /domainprep

Get-Service -Name DNS,DHCPServer | Select-Object Status,Name

Phase 4: Demoting and Virtualizing DC3

Step 1: FSMO Role Transfer

Move-ADDirectoryServerOperationMasterRole -Identity DC1 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Step 2: Demote DC3 Gracefully

Uninstall-ADDSDomainController -DemoteOperationMasterRole -LastDomainControllerInDomain:$false

Step 3: Proper P2V Conversion

Hyper-V Example:

disk2vhd.exe C: D:\Images\DC3_MuraliPalla.vhdx -accepteula

VMware Example: Use VMware vCenter Converter to perform powered-on conversions directly to VMware ESXi.

Post-Migration Checklist

• Reassign RDS CALs: Update via RD Licensing Manager.
• Notify Users: Clearly communicate new RD Web URLs and connection instructions.
• Implement Monitoring:

Get-RDConnectionBrokerHighAvailabilityStatus | Where-Object { $_.LoadBalancingState -ne "Enabled" }

Rollback Plan

• RDS Fallback: Revert DNS and restart services.
• DC Rollback: Restore system state via Windows Server Backup.

Key Takeaways

• Separating roles significantly improves stability and security.
• Sequence matters: First RDS, then DC upgrades.
• Document extensively—future-you will appreciate the detailed records.

Next Steps

Explore Azure Virtual Desktop for scalability or implement RDS grace periods to simplify licensing compliance.