6

Background
When attempting to demote a Windows 2012 Domain controller I encounter the following warning:

No other domain controller could be contacted, but other domain controller objects are in the directory. If you are certain that this is that last domain controller for the domain and want to proceed, confirm that this is that domain controller in the domain.

However, this is not the last domain controller for the domain.

If I check Force the removal of this domain controller I am warned:

Unless this is the last domain controller in the domain, you must perform metadata cleanup manually after removal.

Question
How do I safely demote this domain controller? Why does it claim it can't contact the other domain controller? How safe is forced removal with "manual" metadata cleanup?

Update

Chasing down messages from dcdiag, I have found that the other DC that currently holds the PDCe role does not have any SYSVOL shares, and it's \Windows\SYSVOL\sysvol\domain.example.com is empty. I believe that is what's causing the problem, but I'm not sure how to proceed.

Further Detail
DomainMode : Windows2012Domain
ForestMode : Windows2003Forest

This domain controller was the first domain controller for the domain and as such held the InfrastructureMaster, PDCEmulator and RIDMaster roles. However, these roles were transferred using Move-ADDirectoryServerOperationMasterRole to the other domain controller without apparent incident prior to any attempt at demotion.

The domain controller is a Global Catalog and an AD DNS server, as is the other domain controller, which now holds the FSMO roles, as are the domain controllers for the forest.

The same warnings are not triggered on the other domain controller.

repadmin /replsummary shows no apparent problems.

There has been no customization of the Windows Firewall. The domain controllers are on the same VLAN and no interface specific ACLs are applied along their path.

Improve this question
3
  • While I agree with Greg Askew that ungracefully killing a DC isn't the end of the world and metadata cleanup isn't hard, I'd still like to know why that DC thinks that no other DC can be contacted during a graceful demotion. DNS seems good? How about Dcdiag?
    – Ryan Ries
    Nov 5, 2013 at 0:16
  • 1
    Deleting the Domain controller as Greg suggests will most likely leave problematic meta data which you may need to clean up using Adsiedit. But my preferred approach would be to resolve the problem that is stopping this DC from communicating correctly and then doing a graceful demotion. As Ryan has said, a forced removal is no the end of the world, I've had to do it many times, but it would be cleaner to do it gracefully. You'll learn a lot either way - so it's all good.
    – blacklight
    Nov 5, 2013 at 2:30
  • @84104: Is there anything in the %systemroot%\debug\dcpromo*.log files?
    – Greg Askew
    Nov 5, 2013 at 19:19

2 Answers 2

Reset to default
3

If your other DCs don't have SYSVOL shared out, then find and fix the problem with your NTFRS or DFS-R. Maybe you had a rollover. You should have events related to the problem, unless they've aged out of your event viewer.

REPADMIN won't show this, it's only AD replication and doesn't have anything to do with SYSVOL replication.

Improve this answer
-2

Running AD Users and Computer, right clicking the dc, and selecting delete is fairly safe. Done it a hundred times.

Improve this answer
1
  • 1
    I've seen this done myself, but I'd avoid it except as an absolute last resort. My understanding is it still leaves all the AD metadata floating around the domain for you to clean up, so there are additional steps required to make this a "proper" DC demotion/removal.
    – voretaq7
    Nov 27, 2013 at 19:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .