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

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: 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.