Demote PDC manually
If your PDC fails, just promote a BDC and reinstall a new BDC from scratch. If
you have a WAN with BDCs remotely, at some point you will be faced with
situation where one or more remote links fail. If the remote onsite support
promotes the isolated BDC to a PDC, when the links come back up, you are faced with two or more PDCs for the same domain that see
each other. In such a case, one of the PDCs can be demoted using the
Demote To BDC command. Take note that this command only
appears in the Computer menu when two PDCs are present in a domain.
If the command is not available, restart the PDC that needs to be demoted.
When it comes up, it will see the "real" PDC and stop its own netlogon
process. OK. Now we have only one PDC available on the WAN.
Now the actual demotion. Start regedt32 as SYSTEM
using AT scheduler:
at 11:53 /interactive regedt32.exe
Modify for your own time. Interesting security implications
for this tip, particularly if you have denied your users administrative access.
This will not work if the Scheduler service is not started. You now have
access to the registry as SYSTEM. In HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo, double click on
come up as a BDC.
Why go through such a "risky" process? When you install a BDC, as it comes up
the first time, the entire security db is replicated from the PDC. Depending on
the complexity of the domain, this can take a significant amount of time and
consume a LOT of network capacity. Such sites tend to install new BDCs on the
high speed LAN and ship the newly installed BDC to its remote site.
If the above process does not work, I assume you have a backup for the BDC
which you can use as a last resort. If not, you may be in trouble. If there are
enough accounts on the PDC, the WAN connection may be slow enough so that the
update process from the PDC may timeout before it completes and the PDC aborts
the update and starts the cycle over. An infinite cycle. A wonderful catch 22
for your history files.
All is not lost even then. Check out domain