One DC is pulling FSMO from an AD server that doesn't exist, other DC sees FSMO fine

[abeNdorg]

I have 2 DC, one onpremDC, one hostedDC. There was some previous work where an RDS server was made a DC and FSMO moved to it, then the hostedDC was made the DC & FSMO moved to it, then AD removed from the RDS server. However, the onpremDC still sees the RDSserver as holding all the FSMO (even though it is no longer an AD server). Each DC was only pointing to itself for DNS, so I fixed that, however "netdom query fsmo" from onpremDC still shows the RDSserver (that doesn't exist as an AD server now) as the holder. HostedDC shows itself as fsmo holder (which it should be). Obviously AD/dns/replication issues abound(per dcdiag/replmon). Onprem will be going away soon anyways, so I was wondering should I put more time in trying to fix onpremDC (thought was it wouldn't take long to fix it, then it could be cleanly decommissioned)? I am not 100% sure AD is perfectly healthy with cloudDC (all clients are only pointing to cloudDC currently & "seem" to be working), otherwise, I would be tempted to just decom onpremDC and run through any metadata/cleanup needed to purge any reference to onpremDC & if there are any leftovers of RDS-DC. Eventually, I'll add a second hostedDC for the environment, but that is not currently scheduled. If I should fix onpremDC first, how do I tell it to pull the correct server as the fsmo role holder, assuming that is the big issue that needs to be fixed first? All server 2016.

 

[ChatGPT]

To address the issue of the on-premises DC still considering the old RDS server as the FSMO role holder, you must ensure that all traces of the old RDS server being a DC are completely removed. Here's how you can rectify this: 1. Clear Out Residual Server Data: - If the RDS server was forcefully demoted or removed from the network without properly transferring FSMO roles, it might still be showing as the holder of the roles. Ensure any remnants of the old RDS server, including DNS records, AD metadata, and Group Policies, are cleaned up. 2. Transfer FSMO Roles: - Run the following command on the cloud DC to transfer the FSMO roles:

 ntdsutil roles connections connect to server q transfer schema master transfer naming master transfer PDC transfer RID master transfer infrastructure master

3. Verify FSMO Roles: - Use the command netdom query fsmo on both DCs to confirm that the correct FSMO role holders are being reported. Ensure that each DC correctly shows itself as the FSMO role holder. 4. Check Replication: - Run repadmin /replsummary on both DCs to verify the replication status between the cloud-hosted DC and the on-premises DC. Address any replication errors or warnings. 5. Metadata Cleanup: - Use the Active Directory Sites and Services console and the ntdsutil metadata cleanup command to remove any leftover metadata entries related to the old RDS server. 6. DNS Cleanup: - Also perform a thorough DNS cleanup, ensuring there are no records or references pointing to the old RDS server. 7. Decommission the On-Premises DC: - Once you've confirmed that the cloud DC is healthy and replicating correctly, and FSMO roles are correctly assigned, you can proceed with the decommissioning of the on-premises DC. After following these steps and verifying that all remnants of the old RDS server have been eliminated, you should have a cleaner AD environment with the correct FSMO roles assigned to the appropriate DCs.