Home / server / Questions / 345189
In Process
Mei
Asked: 2011-12-30 16:24:20 +0800 CST

Seizing FSMO roles from dead Windows Domain Controller

  • 772

I've seen other questions and documents about doing this, but there are some things that still confuse me. Here are the documents and questions I've seen:

The environment contains two Windows servers and numerous clients. The Domain Controller is Windows 2003 SP2 running with a Windows 2000 Native AD. The other server (not a DC at all) is Windows 2000 SP4 (it's hosting a virus checking utility).

Results from netdom query fsmo:

Schema owner                missing.office.local

Domain role owner           myself.office.local

PDC role                    missing.office.local

RID pool manager            missing.office.local

Infrastructure owner        missing.office.local

The command completed successfully.

Results from dcdiag:

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site\MYSELF
      Starting test: Connectivity
         The host 841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local could not be resolved to an
         IP address.  Check the DNS server, DHCP, server name, etc
         Although the Guid DNS name
         (841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local) couldn't be
         resolved, the server name (MYSELF.office.local) resolved to the IP
         address (192.168.9.101) and was pingable.  Check that the IP address
         is registered correctly with the DNS server. 
         ......................... MYSELF failed test Connectivity

Doing primary tests

   Testing server: Default-First-Site\MYSELF
      Skipping all tests, because server MYSELF is
      not responding to directory service requests

   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom

   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom

   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom

   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom

   Running partition tests on : office
      Starting test: CrossRefValidation
         ......................... office passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... office passed test CheckSDRefDom

   Running enterprise tests on : office.local
      Starting test: Intersite
         ......................... office.local passed test Intersite
      Starting test: FsmoCheck
         Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355
         A Primary Domain Controller could not be located.
         The server holding the PDC role is down.
         ......................... office.local failed test FsmoCheck

Here are my questions (pardon me if they are too much of beginner questions):

  • Are the roles listed from netdom query fsmo the same ones I've seen listed elsewhere? For example, is Domain role owner the same as Domain Naming Master? Is RID Pool Manager the same as the RID role?
  • What are the bad things that could happen if I seize one of these roles?
  • Will users notice?
  • This set up has been going for a long time and people have been functioning more or less normally; is seizing the PDC role going to change this?
  • Some of these documents predict dire consequences to having all roles on one DC. With a client base of no more than 20 - and perhaps less than 10 most days - is having all roles on one DC a real problem?
  • Are there any caveats to performing the cleanup process recommended by Microsoft to remove the old DC from Active Directory?

Also - an almost tangential question - if I were upgrade the domain to a Windows 2003 AD (now or in the future) does this change anything in the seizing of FSMO roles?

PS: I suspect the DNS problems have to do with trying to use a non-Microsoft DNS that didn't support Microsoft's Dynamic DNS; I think there is a Windows DNS running but haven't audited it for proper functioning and set up yet.

windows-server-2003 domain-controller active-directory

3 Answers

  1. Are the roles listed from netdom query fsmo the same ones I've seen listed elsewhere? For example, is Domain role owner the same as Domain Naming Master? Is RID Pool Manager the same as the RID role?

    Yes, exactly. Not sure why they've got the names slightly different in that particular display.

    What are the bad things that could happen if I seize one of these roles?

    The seizure itself? Not a lot. Most of the potential issues that are warned about are about turning the old DC back on after it's had its role seized - and even then, there's a lot of hysteria out there for not a lot of risk; it takes some pretty strange scenarios to break anything with a seizure instead of a transfer of a role. To go on a tangent for a moment, let's go over the roles and the potential risks:

    • Schema Master: This one gets everyone pretty twitchy, but breaking it is not a terribly likely scenario. The documentation says that you should never ever ever turn the old Schema Master back on after seizing the role, which I call alarmist. The old server will be informed of the role change, and as soon as it is, it'll relinquish the role. The potential risk here is if changes are made to the new schema master, then the old schema master is brought online, then before it replicates from the other DCs, different, conflicting, schema changes are made on the old server. This situation is unlikely, but would destroy your domain.

    • Naming Master: Same deal as with the Schema master, you'd need to make changes (in this case, create a new domain in the forest) on the old DC, after seizing its role but before it gets knowledge of the seizure.

    • PDC Emulator: No risk, it's not responsible for anything where you risk divergence.

    • RID Master: You'd need a messed up replication structure to break this one - imagine that you've got 2 DCs; an old RID master that doesn't know its role has been seized, and a new RID master. In this situation, you'd need to create enough objects to exhaust the RID pool on both (they're handed out in 500s), and have them both assign themselves overlapping pools. Create objects with identical RIDs, reconnect the domain controllers, and watch the apocalypse unfold.

    • Infrastructure Master: Honestly, probably 50% of domains in the world don't even have a working Infrastructure Master at all, since it doesn't work when it's on a GC. In any case, you can't break it with seizure.

    Will users notice?

    They should not.

    This set up has been going for a long time and people have been functioning more or less normally; is seizing the PDC role going to change this?

    No. With a single DC, none of the functions of the PDC are missed at all, except maybe your non-PDC DC being unable to sync time with the source that it wants to (the missing PDC).

    Moreso:

    • You'll only miss the Schema Master when you try to update the schema
    • You'll only miss the Naming Master when you try to create a new domain in the forest
    • You'll only miss the RID Master when you create too many objects and exhaust your DC's RID pool (this is probably the most likely for you to run into if you just keep running as is)
    • You'll only miss the Infrastructure Master for global catalog group updates in a multi-domain forest

    Some of these documents predict dire consequences to having all roles on one DC. With a client base of no more than 20 - and perhaps less than 10 most days - is having all roles on one DC a real problem?

    No - but get a second DC. You don't want to have your only DC fail.

    Are there any caveats to performing the cleanup process recommended by Microsoft to remove the old DC from Active Directory?

    Yeah - be careful. But sharpen your ntdsutil knives and tear the old data out - extra junk in there isn't helping the maintainability of the domain.

    • 14

  2. Yes, seize those roles. You are a power fluctuation / system hang / solar flare away from disaster.

    It's unlikely, but Users may notice if account changes cached on their local machines doesn't match AD.

    You should never have only one DC. Two minimum, and one at each remote office. If you want to use VMs, (IMHO) they are only to supplement the physical boxes. And that is only after you've read up on using VMs as DCs.

    I prefer that all DCs be GCs. This is my personal preference, but it means that a complete copy of AD's contents are stored on each DC with this role. If you have two DCs, but only one is a GC, and that one dies, I think you become just about as screwed as if you only had one DC.

    Your PDC Emulator is going to get all traffic from legacy systems ("systems" meaning machines, applications, and services, such as SQL Server 2000); put it on hardware.

    It is not necessarily bad that one DC have all roles, IF you have other DCs and your replication is healthy.

    Unless there's a really good reason, you should definitely use Microsoft DNS for internal name resolution.

    Fix your environment, then upgrade. You don't paint a sinking boat. While you're at it, strongly consider getting to 2008. 2003 is on life support.

    See also: What needs to be done after a Domain Controller crash? and How to bring another DC up with all roles when first DC is no longer available

    • 6

  3. Your current setup (with no functioning operations masters) is a dangerous and unsupported configuration that needs to be remedied as soon as possible. If the missing server is dead and buried, seizing the FSMO roles is a necessary step toward resuming normal operation.

    Answers to your specific question:

    1. Yes, the similarly-named role titles that you mention all mean the same thing.
    2. Bad things are likely to happen if you seize a role and then subsequently try to resurrect the missing server that used to have it. Please make sure that it is dead and buried before seizing roles.
    3. Users are unlikely to notice any new problems as a result of seizing the FSMO roles.
    4. Failure to seize the role will cause problems over the long term. Seizing the role promptly after the failure of its former holder will not cause problems.
    5. As a matter of fact, it is common for small businesses with 10-20 users to have a single server with all of the FSMO roles and Exchange and Sharepoint. This does not create intractable performance issues if the server has been specified correctly, but the site is guaranteed to suffer downtime if the sole server fails. It is best to have at least two domain controllers per domain, even if one of them is a sub-$500 Atom D525 server in a 1U chassis.
    6. Not particularly, but any server maintenance carries at least some risk. As always, make sure that you have full and tested backups and a recovery plan before proceeding.
    7. This should not be a problem as long as you seize the FSMO roles first, then upgrade the domain functional level.
    8. There is no good reason to use a non-Microsoft DNS for domain resolution within an Active Directory environment. You need to prepare and implement a plan to migrate your internal DNS services to your domain controller(s).

    You have indicated that you have a "virus checking utility" running on a Windows 2000 server. Surely you are aware that Windows 2000 itself is a "virus collecting utility" with many known vulnerabilities and no security updates available. Retire this server immediately.

    • 6