5

We have a domain controller that was virtualized a while back; this caused issues with replication that we're now seeing fallout from. I've moved the PDC Emulator and other fsmo roles to a new DC and we're working on decommissioning the virtualized DC.

In the meantime, I'm trying to resolve an issue with group policy processing. Some workstations, when attempting to process policy, are resolving "domain.local" to the IP address of the virtualized/malfunctioning DC. When they try to download GPOs from this DC, they are not available due to replication issues. What I'd like to do is safely remove this DC from the list of DFS servers that serve this domain (\domain.local\sysvol). Is there a safe way to do so? This will only be a temporary band-aid until we are able to decommission the malfunctioning DC.

I'm open to alternative suggestions as well.

bshacklett
  • 1,378
  • 4
  • 19
  • 39

2 Answers2

11

Strip its A record from the domain.local name in DNS, and then modify the settings on its DNS service so that it doesn't put it back.

If replication is that busted, then there's not a lot of good that can come of leaving it up for any length of time - why not just turn it off, burn all memory of it from the domain (also known as a metadata cleanup) and seize any roles that it has left?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • That was the first thing I thought of as well. I was just concerned that there might be unknown consequences. The reason we're leaving it up at the moment is that it's still got some functioning roles on it that will take time to migrate (DNS, DHCP, IAS). Also, I was successful in transferring all of the FSMO roles to the new DC. – bshacklett Dec 21 '11 at 18:33
  • 5
    If you can, run a `dcpromo` on the faulty DC so that it can be gracefully removed if possible. A metadata cleanup is a *hassle* – Mark Henderson Dec 21 '11 at 19:29
  • Agree with @Mark ... Always go for the graceful dcpromo before doing anything crazy like metadata cleanups. We've had DCs die (dont ask) before and its a PITA. – Ashley Dec 27 '11 at 21:36
  • 1
    While this seemed like a good answer, we have continued to have issues with this DC It appears that stripping the A record does not disqualify it as a DFS node for the Sysvol share. I'm still working to demote the DC, but many of our systems have been pointing to it, specifically, for one reason or another. – bshacklett Apr 11 '12 at 13:40
8

You should either find a way to fix it, or shut it down as soon as possible and remove any reference to it from Active Directory (using NTDSUTIL's metadata cleanup functions); as long as Active Directory thinks it's still there, domain members are going to try logging on to it (and have any sort of problems).

If you want to keep it around instead of decommissioning it, you should try (forcibly) demoting it and then promoting it back; this should fix replication issues:

http://support.microsoft.com/kb/875495

If you can't fix or demote it, at least shut it down (or disconnect it from the network); that's the only safe way to make sure nobody tries logging on to it. If it's reachable on the network, someone or something will sooner or later try to use it.

Massimo
  • 70,200
  • 57
  • 200
  • 323