I recently took over a client environment where the Remote Desktop server occasionally stops allowing anyone to log in. Rebooting the server temporarily fixes it. The issue occurs through both remote-management software and standard RDP, so it does not appear to be limited to the RDP client itself. The environment has three Windows Server 2022 global catalog servers, and DNS testing reports missing SRV records. I noticed that the DNS layout differs from another environment I manage. In one, the forward lookup zones contain separate root entries for _msdcs.domain.lan and domain.lan. In the affected environment, there is no separate _msdcs.acme.lan forward lookup zone; instead, _msdcs.123.local appears beneath the 123.local zone. Is either layout incorrect, and could this explain the missing SRV records or intermittent login failures?
3 Answers
The symptoms may be unrelated to the DNS-zone layout. A recent Windows Server update caused intermittent Remote Desktop failures on several server versions, including sessions hanging while connecting and users being unable to log off cleanly. Install the applicable out-of-band or superseding update on the RDS server and test again before changing the Active Directory DNS structure. Still investigate the missing SRV warning separately, but do not assume it is causing the RDS outage.
If the affected domain is supposed to use a delegated _msdcs zone but the delegation exists without the corresponding zone, create or repair the forward lookup zone through the normal Active Directory-integrated DNS configuration, then verify that the delegation and NS records agree. Afterward, restart Netlogon and check whether the domain controllers republish their SRV records. Avoid manually adding individual SRV records because they can become stale or point to the wrong controller.
Both DNS layouts can be valid. In some Active Directory forests, _msdcs is created as its own forest-wide forward lookup zone with a delegation from the domain zone. In others, it remains a normal subdomain beneath the parent zone. The important checks are whether the delegation, name-server records, replication, and SRV records all point to the correct domain controllers. You normally should not create SRV records manually; the Netlogon service registers them automatically. Run the standard SRV-record checks and restart Netlogon and DNS only after confirming the configuration.
The healthy domain is the one with the separate _msdcs zone. I’m trying to determine whether the affected domain’s lack of that separate zone is actually a configuration problem or simply a different but supported layout.
That update issue matches the pattern of working normally after a reboot and failing again later, so it is worth ruling out before rebuilding or manually modifying DNS zones.