A cautionary tale of domain controller migration, RDP lockouts, and the remote access tool that saved the weekend
The migration itself went perfectly. Windows Server 2022 to 2025, all domain services transferred, no errors in the event logs. But then came the moment of truth: testing RDP access for regular users.
The Error Message:
"To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Administrator group have this right. If the group you're in doesn't have this right, or if the right has been removed from the Administrator's group, you need to be granted this right manually."
Opened Local Security Policy, navigated to "Allow log on through Remote Desktop Services," and added a test user. Success! The user could now connect.
Removed the test user to keep things clean. But here's the critical error: I didn't add the proper domain groups first. The policy was no longer "Not Defined" - it was now explicitly empty.
Computer went to sleep, RDP session disconnected. When trying to reconnect: Access Denied. Even administrator accounts were now locked out because the policy was explicitly set but empty.
With RDP completely locked down, the situation seemed hopeless. But there was one tool still running: a third-party remote access application that operates independently of Windows RDP services. This application uses its own authentication mechanism and doesn't rely on the "Allow log on through Remote Desktop Services" policy.
Always have a backup access method.
Once back in via the third-party tool, the fix was straightforward: add the Administrators group back to the "Allow log on through Remote Desktop Services" policy to restore immediate access.
Created a domain security group called "RDS Allow" with global scope, then configured the Default Domain Controllers Policy:
# PowerShell to verify the configuration
Get-GPO -Name "Default Domain Controllers Policy" | Get-GPPermissionsGroup Policy Path:
Sometimes the risk is worth it when you have time to troubleshoot
"Not Defined" ≠ "Defined but Empty" - crucial distinction
Alternative remote access tools can be lifesavers
Domain groups + GPO = scalable, manageable solution
The difference between "Not Defined" and "Defined but Empty" in Group Policy can be the difference between a smooth evening and a stressful weekend. When you modify a policy, always ensure you're setting it to the correct state, not just clearing it.
What started as a routine migration turned into a valuable learning experience. The combination of understanding Windows security policies, having backup access methods, and knowing how to properly configure domain-based solutions turned a potential disaster into a successful project completion.
The Happy Ending: By midnight, all users had proper RDP access through the new domain group, the GPO was correctly configured and documented, and the migration was complete. Sometimes the best lessons come from the problems we create for ourselves.
Remember: Every experienced sysadmin has a story like this. The key is learning from it and sharing the knowledge so others can avoid the same pitfalls.
Migration Successful
Hours of Troubleshooting
Backup Tool Used
Final Solution
Tools That Saved the Day: Third-party remote access application
Lesson Learned: Always test with regular user accounts
Every admin has war stories. The important thing is documenting and sharing them so the community can learn together.