Windows 2000/2003 Active Directory domains utilize a Single Operation Master method called

FSMO (Flexible Single Master Operation)

The five FSMO roles are:

• Schema master - Forest-wide and one per forest.

• Domain naming master - Forest-wide and one per forest.
• RID master - Domain-specific and one for each domain.
• PDC - PDC Emulator is domain-specific and one for each domain.
• Infrastructure master - Domain-specific and one for each domain.

In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot
(or actually, on the same DC) as has been configured by the Active Directory installation
process. However, there are scenarios where an administrator would want to move one or more
of the FSMO roles from the default holder DC to a different DC. The transferring method is
described in the Transferring FSMO Roles article, while seizing the roles from a non-operational
DC to a different DC is described in the Seizing FSMO Roles article.

In order to better understand your AD infrastructure and to know the added value that each DC
might possess, an AD administrator must have the exact knowledge of which one of the existing
DCs is holding a FSMO role, and what role it holds. With that knowledge in hand, the
administrator can make better arrangements in case of a scheduled shut-down of any given DC,
and better prepare him or herself in case of a non-scheduled cease of operation from one of the
DCs.

How to find out which DC is holding which FSMO role? Well, one can accomplish this task by
many means. This article will list a few of the available methods.

Method #1: Know the default settings

The FSMO roles were assigned to one or more DCs during the DCPROMO process. The
following table summarizes the FSMO default locations:

Number of DCs holding this

FSMO Role Original DC holding the FSMO role
role
Schema One per forest The first DC in the first domain in the forest
Domain Naming One per forest (i.e. the Forest Root Domain)
RID One per domain The first DC in a domain (any domain,
PDC Emulator One per domain including the Forest Root Domain, any Tree
Infrastructure One per domain Root Domain, or any Child Domain)

Method #2: Use the GUI

The FSMO role holders can be easily found by use of some of the AD snap-ins. Use this table to
see which tool can be used for what FSMO role:

FSMO Role Which snap-in should I use?

Schema Schema snap-in
Domain Naming AD Domains and Trusts snap-in
RID
PDC Emulator AD Users and Computers snap-in
Infrastructure

Finding the RID Master, PDC Emulator, and Infrastructure Masters via GUI

To find out who currently holds the Domain-Specific RID Master, PDC Emulator, and
Infrastructure Master FSMO Roles:

1. Open the Active Directory Users and Computers snap-in from the Administrative Tools
folder.
2. Right-click the Active Directory Users and Computers icon again and press Operation
Masters.

1. Select the appropriate tab for the role you wish to view.

1. When you're done click Close.

Finding the Domain Naming Master via GUI

To find out who currently holds the Domain Naming Master Role:

1. Open the Active Directory Domains and Trusts snap-in from the Administrative Tools
folder.
2. Right-click the Active Directory Domains and Trusts icon again and press Operation
Masters.
 1. When you're done click Close.

Finding the Schema Master via GUI

To find out who currently holds the Schema Master Role:

1. Register the Schmmgmt.dll library by pressing Start > RUN and typing:

regsvr32 schmmgmt.dll

1. Press OK. You should receive a success confirmation.

2. From the Run command open an MMC Console by typing MMC.
3. On the Console menu, press Add/Remove Snap-in.
4. Press Add. Select Active Directory Schema.
5. Press Add and press Close. Press OK.
6. Click the Active Directory Schema icon. After it loads right-click it and press Operation
Masters.

1. Press the Close button.

Method #3: Use the Ntdsutil command

The FSMO role holders can be easily found by use of the Ntdsutil command.

Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active
Directory functionality.

1. On any domain controller, click Start, click Run, type Ntdsutil in the Open box, and then
click OK.

Microsoft Windows [Version 5.2.3790]

(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS>ntdsutil
ntdsutil:

1. Type roles, and then press ENTER.

ntdsutil: roles
fsmo maintenance:

Note: To see a list of available commands at any of the prompts in the Ntdsutil tool, type ?, and
then press ENTER.

1. Type connections, and then press ENTER.

fsmo maintenance: connections

server connections:

1. Type connect to server <servername>, where <servername> is the name of the server you
want to use, and then press ENTER.

server connections: connect to server server100

Binding to server100 ...
Connected to server100 using credentials of locally logged on user.
server connections:

1. At the server connections: prompt, type q, and then press ENTER again.

server connections: q
fsmo maintenance:

1. At the FSMO maintenance: prompt, type Select operation target, and then press ENTER
again.

fsmo maintenance: Select operation target

select operation target:

1. At the select operation target: prompt, type List roles for connected server, and then press
ENTER again.

select operation target: List roles for connected server

Server "server100" knows about 5 roles
Schema - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=C
onfiguration,DC=dpetri,DC=net
Domain - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=C
onfiguration,DC=dpetri,DC=net
PDC - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Conf
iguration,DC=dpetri,DC=net
RID - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Conf
iguration,DC=dpetri,DC=net
Infrastructure - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-
Site-Name,CN=Si
tes,CN=Configuration,DC=dpetri,DC=net
select operation target:

1. Type q 3 times to exit the Ntdsutil prompt.

Note: You can download THIS nice batch file that will do all this for you (1kb).

Another Note: Microsoft has a nice tool called Dumpfsmos.cmd, found in the Windows 2000
Resource Kit (and can be downloaded here: Download Free Windows 2000 Resource Kit Tools).
This tool is basically a one-click Ntdsutil script that performs the same operation described
above.

Method #4: Use the Netdom command

The FSMO role holders can be easily found by use of the Netdom command.

Netdom.exe is a part of the Windows 2000/XP/2003 Support Tools. You must either download it
separately (from here Download Free Windows 2000 Resource Kit Tools) or by obtaining the
correct Support Tools pack for your operating system. The Support Tools pack can be found in
the \Support\Tools folder on your installation CD (or you can Download Windows 2000 SP4
Support Tools, Download Windows XP SP1 Deploy Tools).

1. On any domain controller, click Start, click Run, type CMD in the Open box, and then
click OK.
2. In the Command Prompt window, type netdom query /domain:<domain> fsmo (where
<domain> is the name of YOUR domain).

C:\WINDOWS>netdom query /domain:dpetri fsmo

Schema owner server100.dpetri.net

Domain role owner server100.dpetri.net

PDC role server100.dpetri.net

RID pool manager server100.dpetri.net

Infrastructure owner server100.dpetri.net

The command completed successfully.

Close the CMD window.

Note: You can download THIS nice batch file that will do all this for you (1kb).

Method #5: Use the Replmon tool

The FSMO role holders can be easily found by use of the Netdom command.

Just like Netdom, Replmon.exe is a part of the Windows 2000/XP/2003 Support Tools. Replmon
can be used for a wide verity of tasks, mostly with those that are related with AD replication. But
Replmon can also provide valuable information about the AD, about any DC, and also about
other objects and settings, such as GPOs and FSMO roles. Install the package before attempting
to use the tool.

1. On any domain controller, click Start, click Run, type REPLMON in the Open box, and
then click OK.
2. Right-click Monitored servers and select Add Monitored Server.

1. In the Add Server to Monitor window, select the Search the Directory for the server to
add. Make sure your AD domain name is listed in the drop-down list.

1. In the site list select your site, expand it, and click to select the server you want to query.
Click Finish.

1. Right-click the server that is now listed in the left-pane, and select Properties.

1. Click on the FSMO Roles tab and read the results.

1. Click Ok when you're done.

Windows 2000/2003 Active Directory domains utilize a Single Operation Master method called
FSMO (Flexible Single Master Operation), as described in Understanding FSMO Roles in
Active Directory.

In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot
(or actually, on the same DC) as has been configured by the Active Directory installation
process. However, there are scenarios where an administrator would want to move one or more
of the FSMO roles from the default holder DC to a different DC.

Moving the FSMO roles while both the original FSMO role holder and the future FSMO role
holder are online and operational is called Transferring, and is described in this article.

The transfer of an FSMO role is the suggested form of moving a FSMO role between domain
controllers and can be initiated by the administrator or by demoting a domain controller.
However, the transfer process is not initiated automatically by the operating system, for example
a server in a shut-down state. FSMO roles are not automatically relocated during the shutdown
process - this must be considered when shutting down a domain controller that has an FSMO role
for maintenance, for example.

In a graceful transfer of an FSMO role between two domain controllers, a synchronization of the
data that is maintained by the FSMO role owner to the server receiving the FSMO role is
performed prior to transferring the role to ensure that any changes have been recorded before the
role change.

However, when the original FSMO role holder went offline or became non operational for a long
period of time, the administrator might consider moving the FSMO role from the original, non-
operational holder, to a different DC. The process of moving the FSMO role from a non-
operational role holder to a different DC is called Seizing, and is described in the Seizing FSMO
Roles article.

You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an
MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can use one of
the following three MMC snap-in tools:

• Active Directory Schema snap-in

• Active Directory Domains and Trusts snap-in
• Active Directory Users and Computers snap-in

To transfer the FSMO role the administrator must be a member of the following group:

FSMO Role Administrator must be a member of

Schema Schema Admins
Domain Naming Enterprise Admins
RID
PDC Emulator Domain Admins
Infrastructure

Transferring the RID Master, PDC Emulator, and Infrastructure Masters via GUI

To Transfer the Domain-Specific RID Master, PDC Emulator, and Infrastructure Master FSMO
Roles:

1. Open the Active Directory Users and Computers snap-in from the Administrative Tools
folder.
2. If you are NOT logged onto the target domain controller, in the snap-in, right-click the
icon next to Active Directory Users and Computers and press Connect to Domain
Controller.
3. Select the domain controller that will be the new role holder, the target, and press OK.
4. Right-click the Active Directory Users and Computers icon again and press Operation
Masters.
5. Select the appropriate tab for the role you wish to transfer and press the Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.

Transferring the Domain Naming Master via GUI

To Transfer the Domain Naming Master Role:

1. Open the Active Directory Domains and Trusts snap-in from the Administrative Tools
folder.
2. If you are NOT logged onto the target domain controller, in the snap-in, right-click the
icon next to Active Directory Domains and Trusts and press Connect to Domain
Controller.
3. Select the domain controller that will be the new role holder and press OK.
4. Right-click the Active Directory Domains and Trusts icon again and press Operation
Masters.
5. Press the Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.

Transferring the Schema Master via GUI

Windows 2000/2003 Active Directory domains utilize a Single Operation Master method called
FSMO (Flexible Single Master Operation), as described in Understanding FSMO Roles in
Active Directory.

The five FSMO roles are:

• Schema master - Forest-wide and one per forest.

• Domain naming master - Forest-wide and one per forest.
• RID master - Domain-specific and one for each domain.
• PDC - PDC Emulator is domain-specific and one for each domain.
• Infrastructure master - Domain-specific and one for each domain.

In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot
(or actually, on the same DC) as has been configured by the Active Directory installation
process. However, there are scenarios where an administrator would want to move one or more
of the FSMO roles from the default holder DC to a different DC.

Moving the FSMO roles while both the original FSMO role holder and the future FSMO role
holder are online and operational is called Transferring, and is described in the Transferring
FSMO Roles article.

However, when the original FSMO role holder went offline or became non operational for a long
period of time, the administrator might consider moving the FSMO role from the original, non-
operational holder, to a different DC. The process of moving the FSMO role from a non-
operational role holder to a different DC is called Seizing, and is described in this article.

If a DC holding a FSMO role fails, the best thing to do is to try and get the server online again.
Since none of the FSMO roles are immediately critical (well, almost none, the loss of the PDC
Emulator FSMO role might become a problem unless you fix it in a reasonable amount of time),
so it is not a problem to them to be unavailable for hours or even days.

If a DC becomes unreliable, try to get it back on line, and transfer the FSMO roles to a reliable
computer. Administrators should use extreme caution in seizing FSMO roles. This operation, in
most cases, should be performed only if the original FSMO role owner will not be brought back
into the environment. Only seize a FSMO role if absolutely necessary when the original role
holder is not connected to the network.

What will happen if you do not perform the seize in time? This table has the info:

FSMO Role Loss implications

The schema cannot be extended. However, in the
short term no one will notice a missing Schema
Schema
Master unless you plan a schema upgrade during
that time.
Domain Naming Unless you are going to run DCPROMO, then you
 will not miss this FSMO role.
Chances are good that the existing DCs will have
enough unused RIDs to last some time, unless
RID
you're building hundreds of users or computer
object per week.
Will be missed soon. NT 4.0 BDCs will not be
able to replicate, there will be no time
synchronization in the domain, you will probably
PDC Emulator
not be able to change or troubleshoot group
policies and password changes will become a
problem.
Group memberships may be incomplete. If you
Infrastructure only have one domain, then there will be no
impact.

Important: If the RID, Schema, or Domain Naming FSMOs are seized, then the original domain
controller must not be activated in the forest again. It is necessary to reinstall Windows if these
servers are to be used again.

The following table summarizes the FSMO seizing restrictions:

FSMO Role Restrictions

Schema
Domain Naming Original must be reinstalled
RID
PDC Emulator
Can transfer back to original
Infrastructure

Another consideration before performing the seize operation is the administrator's group
membership, as this table lists:

FSMO Role Administrator must be a member of

Schema Schema Admins
Domain Naming Enterprise Admins
RID
PDC Emulator Domain Admins
Infrastructure

To seize the FSMO roles by using Ntdsutil, follow these steps:

Windows 2000/2003 Active Directory domains utilize a Single Operation Master method called
FSMO (Flexible Single Master Operation), as described in Understanding FSMO Roles in
Active Directory.

In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot
(or actually, on the same DC) as has been configured by the Active Directory installation
process. However, there are scenarios where an administrator would want to move one or more
of the FSMO roles from the default holder DC to a different DC.

Windows Server 2003 Active Directory is a bit different than the Windows 2000 version when
dealing with FSMO placement. In this article I will only deal with Windows Server 2003 Active
Directory, but you should bear in mind that most considerations are also true when planning
Windows 2000 AD FSMO roles.

Single Domain Forest

In a single domain forest, leave all of the FSMO roles on the first domain controller in the forest.

You should also configure all the domain controller as a Global Catalog servers. This will NOT
place additional stress on the DCs, while allowing GC-related applications (such as Exchange
Server) to easily perform GC queries.

Multiple Domain Forest

In a multiple domain forest, use the following guidelines:

• In the forest root domain:

• If all domain controllers are also global catalog servers, leave all of the FSMO
roles on the first DC in the forest.
• If all domain controllers are not also global catalog servers, move all of the
FSMO roles to a DC that is not a global catalog server.
• In each child domain, leave the PDC emulator, RID master, and Infrastructure master
roles on the first DC in the domain, and ensure that this DC is never designated as a
global catalog server (unless the child domain only contains one DC, then you have no
choice but to leave it in place).

Configure a standby operations master - For each server that holds one or more operations
master roles, make another DC in the same domain available as a standby operations master.
Making a DC as a standby operation master involves the following actions:

• The standby operations master should not be a global catalog server except in a single
domain environment, where all domain controllers are also global catalog servers.
• The standby operations master should have a manually created replication connection to
the domain controller that it is the standby operations master for, and it should be in the
same site.
 • Configure the RID master as a direct replication partner with the standby or backup RID
master. This configuration reduces the risk of losing data when you seize the role because
it minimizes replication latency.

To create a connection object on the current operations master:

1. In Active Directory Sites and Services snap-in, in the console tree in the left pane, expand
the Sites folder to see the list of available sites.
2. Expand the site name in which the current role holder is located to display the Servers
folder.
3. Expand the Servers folder to see a list of the servers in that site.
4. Expand the name of the server that is currently hosting the operations master role to
display NTDS Settings.
5. Right-click NTDS Settings, click New, and then click Connection.
6. In the Find Domain Controllers dialog box, select the name of the standby operations
master then click OK.
7. In the New Object-Connection dialog box, enter an appropriate name for the connection
object or accept the default name and click OK.

To create a connection object on the standby operations master perform the same procedure as
above, and point the connection to the current FSMO role holder.

Note regarding Windows 2000 Active Directory domains: If the forest is set to a functional
level of Windows 2000 native, you must locate the domain naming master on a server that hosts
the global catalog. If the forest is set to a functional level of Windows Server 2003, it is not
necessary for the domain naming master to be on a global catalog server.

Server performance and availability

Most FSMO roles require that the domain controller that holds the roles be:

Highly available server - FSMO functions require that the FSMO role holder is highly available
at all times. A highly available DC is one that uses computer hardware that enables it to remain
operational even during a hardware failure. For example, having a RAID1 or RAID5
configuration enables the server to keep running even if one hard disk fails.

Although most FSMO losses can be dealt with within a matter of hours (or even days at some
cases), some FSMO roles, such as the PDC Emulator role, should never be offline for more than
a few minutes at a time.

What will happen if you keep a FSMO role offline for a long period of time? This table has the
info:

FSMO Role Loss implications

Schema The schema cannot be extended. However, in the
 short term no one will notice a missing Schema
Master unless you plan a schema upgrade during
that time.
Unless you are going to run DCPROMO, then you
Domain Naming
will not miss this FSMO role.
Chances are good that the existing DCs will have
enough unused RIDs to last some time, unless
RID
you're building hundreds of users or computer
object per week.
Will be missed soon. NT 4.0 BDCs will not be
able to replicate, there will be no time
synchronization in the domain, you will probably
PDC Emulator
not be able to change or troubleshoot group
policies and password changes will become a
problem.
Group memberships may be incomplete. If you
Infrastructure only have one domain, then there will be no
impact.

Not necessarily high capacity server - A high-capacity domain controller is one that has
comparatively higher processing power than other domain controllers to accommodate the
additional work load of holding the operations master role. It has a faster CPU and possibly
additional memory and network bandwidth. FSMO roles usually do not place stress on the
server's hardware.

One exception is the performance of the PDC Emulator, mainly when used in Windows 2000
Mixed mode along with old NT 4.0 BDCs. That is why you should:

• Increase the size of the DC's processing power.

• Do not make the DC a global catalog server.
• Reduce the priority and the weight of the service (SRV) record in DNS to give preference
for authentication to other domain controllers in the site.
• Do not require that the standby domain controller be a direct replication partner (Seizing
the PDC emulator role does not result in lost data, so there is no need to reduce
replication latency for a seize operation).
• Centrally locate this DC near the majority of the domain users.
Using Ntdsutil.exe to transfer or seize FSMO roles to a domain
controller

Certain domain and enterprise-wide operations that are not good for multi-master updates are performed by

a single domain controller in an Active Directory domain or forest. The domain controllers that are assigned

to perform these unique operations are called operations masters or FSMO role holders.

The following list describes the 5 unique FSMO roles in an Active Directory forest and the dependent

operations that they perform:

• Schema master - The Schema master role is forest-wide and there is one for each forest. This role

is required to extend the schema of an Active Directory forest or to run the adprep /domainprep

command.

• Domain naming master - The Domain naming master role is forest-wide and there is one for each

forest. This role is required to add or remove domains or application partitions to or from a forest.

• RID master - The RID master role is domain-wide and there is one for each domain. This role is

required to allocate the RID pool so that new or existing domain controllers can create user

accounts, computer accounts or security groups.

• PDC emulator - The PDC emulator role is domain-wide and there is one for each domain. This role is

required for the domain controller that sends database updates to Windows NT backup domain

controllers. The domain controller that owns this role is also targeted by certain administration tools

and updates to user account and computer account passwords.

• Infrastructure master - The Infrastructure master role is domain-wide and there is one for each

domain. This role is required for domain controllers to run the adprep /forestprep command

successfully and to update SID attributes and distinguished name attributes for objects that are

referenced across domains.

The Active Directory Installation Wizard (Dcpromo.exe) assigns all 5 FSMO roles to the first domain

controller in the forest root domain. The first domain controller in each new child or tree domain is assigned

the three domain-wide roles. Domain controllers continue to own FSMO roles until they are reassigned by

using one of the following methods:

• An administrator reassigns the role by using a GUI administrative tool.

• An administrator reassigns the role by using the ntdsutil /roles command.

• An administrator gracefully demotes a role-holding domain controller by using the Active Directory

Installation Wizard. This wizard reassigns any locally-held roles to an existing domain controller in
 the forest. Demotions that are performed by using the dcpromo /forceremoval command leave

FSMO roles in an invalid state until they are reassigned by an administrator.

We recommend that you transfer FSMO roles in the following scenarios:

• The current role holder is operational and can be accessed on the network by the new FSMO owner.

• You are gracefully demoting a domain controller that currently owns FSMO roles that you want to

assign to a specific domain controller in your Active Directory forest.

• The domain controller that currently owns FSMO roles is being taken offline for scheduled

maintenance and you need specific FSMO roles to be assigned to a “live” domain controller. This

may be required to perform operations that connect to the FSMO owner. This would be especially

true for the PDC Emulator role but less true for the RID master role, the Domain naming master role

and the Schema master roles.

We recommend that you seize FSMO roles in the following scenarios:

• The current role holder is experiencing an operational error that prevents an FSMO-dependent

operation from completing successfully and that role cannot be transferred.

• A domain controller that owns an FSMO role is force-demoted by using the dcpromo

/forceremoval command.

• The operating system on the computer that originally owned a specific role no longer exists or has

been reinstalled.

As replication occurs, non-FSMO domain controllers in the domain or forest gain full knowledge of changes

that are made by FSMO-holding domain controllers. If you must transfer a role, the best candidate domain

controller is one that is in the appropriate domain that last inbound-replicated, or recently inbound-

replicated a writable copy of the “FSMO partition” from the existing role holder. For example, the Schema

master role-holder has a distinguished name path of CN=schema,CN=configuration,dc=<forest root

domain>, and this mean that roles reside in and are replicated as part of the CN=schema partition. If the

domain controller that holds the Schema master role experiences a hardware or software failure, a good

candidate role-holder would be a domain controller in the root domain and in the same Active Directory site

as the current owner. Domain controllers in the same Active Directory site perform inbound replication every

5 minutes or 15 seconds.

The partition for each FSMO role is in the following list:

FSMO role Partition

Schema CN=Schema,CN=configuration,DC=<forest root domain>

Domain Naming Master CN=configuration,DC=<forest root domain>

PDC DC=<domain>

RID DC=<domain>

Infrastructure DC=<domain>

A domain controller whose FSMO roles have been seized should not be permitted to communicate with

existing domain controllers in the forest. In this scenario, you should either format the hard disk and

reinstall the operating system on such domain controllers or forcibly demote such domain controllers on a

private network and then remove their metadata on a surviving domain controller in the forest by using the

ntdsutil /metadata cleanup command. The risk of introducing a former FSMO role holder whose role has

been seized into the forest is that the original role holder may continue to operate as before until it inbound-

replicates knowledge of the role seizure. Known risks of two domain controllers owning the same FSMO roles

include creating security principals that have overlapping RID pools, and other problems.

Transfer FSMO roles

To transfer the FSMO roles by using the Ntdsutil utility, follow these steps:

1. Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or

domain controller that is located in the forest where FSMO roles are being transferred. We

recommend that you log on to the domain controller that you are assigning FSMO roles to. The

logged-on user should be a member of the Enterprise Administrators group to transfer Schema

master or Domain naming master roles, or a member of the Domain Administrators group of the

domain where the PDC emulator, RID master and the Infrastructure master roles are being

transferred.

2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.

3. Type roles, and then press ENTER.

 Note To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ?,

and then press ENTER.

4. Type connections, and then press ENTER.

5. Type connect to server servername, and then press ENTER, where servername is the name of

the domain controller you want to assign the FSMO role to.

6. At the server connections prompt, type q, and then press ENTER.

7. Type transfer role, where role is the role that you want to transfer. For a list of roles that you can

transfer, type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at

the start of this article. For example, to transfer the RID master role, type transfer rid master.

The one exception is for the PDC emulator role, whose syntax is transfer pdc, not transfer pdc

emulator.

8. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil

prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

Seize FSMO roles

To seize the FSMO roles by using the Ntdsutil utility, follow these steps:

1. Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or

domain controller that is located in the forest where FSMO roles are being seized. We recommend

that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user

should be a member of the Enterprise Administrators group to transfer schema or domain naming

master roles, or a member of the Domain Administrators group of the domain where the PDC

emulator, RID master and the Infrastructure master roles are being transferred.

2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.

3. Type roles, and then press ENTER.

4. Type connections, and then press ENTER.

5. Type connect to server servername, and then press ENTER, where servername is the name of

the domain controller that you want to assign the FSMO role to.

6. At the server connections prompt, type q, and then press ENTER.

7. Type seize role, where role is the role that you want to seize. For a list of roles that you can seize,

type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start

of this article. For example, to seize the RID master role, type seize rid master. The one exception

is for the PDC emulator role, whose syntax is seize pdc, not seize pdc emulator.
8. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil

prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

Notes
o Under typical conditions, all five roles must be assigned to “live” domain controllers in the

forest. If a domain controller that owns a FSMO role is taken out of service before its roles

are transferred, you must seize all roles to an appropriate and healthy domain controller.

We recommend that you only seize all roles when the other domain controller is not

returning to the domain. If it is possible, fix the broken domain controller that is assigned

the FSMO roles. You should determine which roles are to be on which remaining domain

controllers so that all five roles are assigned to a single domain controller. For more

information about FSMO role placement, click the following article number to view the

article in the Microsoft Knowledge Base:

223346 FSMO placement and optimization on Windows 2000 domain controllers

o If the domain controller that formerly held any FSMO role is not present in the domain and

if it has had its roles seized by using the steps in this article, remove it from the Active

Directory by following the procedure that is outlined in the following Microsoft Knowledge

Base article:

216498 How to remove data in active directory after an unsuccessful domain

controller demotion

o Removing domain controller metadata with the Windows 2000 version or the Windows

Server 2003 build 3790 version of the ntdsutil /metadata cleanup command does not

relocate FSMO roles that are assigned to live domain controllers. The Windows Server 2003

Service Pack 1 (SP1) version of the Ntdsutil utility automates this task and removes

additional elements of domain controller metadata.

o Some customers prefer not to restore system state backups of FSMO role-holders in case

the role has been reassigned since the backup was made.
o Do not put the Infrastructure master role on the same domain controller as the global

catalog server. If the Infrastructure master runs on a global catalog server it stops updating

object information because it does not contain any references to objects that it does not

hold. This is because a global catalog server holds a partial replica of every object in the

forest.
To test whether a domain controller is also a global catalog server:

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory

Sites and Services.

2. Double-click Sites in the left pane, and then locate the appropriate site or click Default-first-site-

name if no other sites are available.

3. Open the Servers folder, and then click the domain controller.

4. In the domain controller's folder, double-click NTDS Settings.

5. On the Action menu, click Properties.

6. On the General tab, view the Global Catalog check box to see if it is selected.

How to view and transfer FSMO roles in Windows Server 2003

FSMO Roles

In a forest, there are at least five FSMO roles that are assigned to one or more domain controllers. The

five FSMO roles are:

• Schema Master: The schema master domain controller controls all updates and modifications to the

schema. To update the schema of a forest, you must have access to the schema master. There can

be only one schema master in the whole forest.

• Domain naming master: The domain naming master domain controller controls the addition or

removal of domains in the forest. There can be only one domain naming master in the whole forest.

• Infrastructure Master: The infrastructure is responsible for updating references from objects in its

domain to objects in other domains. At any one time, there can be only one domain controller

acting as the infrastructure master in each domain.

• Relative ID (RID) Master: The RID master is responsible for processing RID pool requests from all

domain controllers in a particular domain. At any one time, there can be only one domain controller

acting as the RID master in the domain.

• PDC Emulator: The PDC emulator is a domain controller that advertises itself as the primary domain

controller (PDC) to workstations, member servers, and domain controllers that are running earlier

versions of Windows. For example, if the domain contains computers that are not running Microsoft

Windows XP Professional or Microsoft Windows 2000 client software, or if it contains Microsoft

Windows NT backup domain controllers, the PDC emulator master acts as a Windows NT PDC. It is

also the Domain Master Browser, and it handles password discrepancies. At any one time, there can

be only one domain controller acting as the PDC emulator master in each domain in the forest.
You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an MMC snap-in tool.

Depending on the FSMO role that you want to transfer, you can use one of the following three MMC snap-in

tools:

Active Directory Schema snap-in

Active Directory Domains and Trusts snap-in

Active Directory Users and Computers snap-in

If a computer no longer exists, the role must be seized. To seize a role, use the Ntdsutil.exe utility.

Transfer the Schema Master Role

Use the Active Directory Schema Master snap-in to transfer the schema master role. Before you can use

this snap-in, you must register the Schmmgmt.dll file.

Register Schmmgmt.dll

1. Click Start, and then click Run.

2. Type regsvr32 schmmgmt.dll in the Open box, and then click OK.

3. Click OK when you receive the message that the operation succeeded.

Transfer the Schema Master Role

1. Click Start, click Run, type mmc in the Open box, and then click OK.

2. On the File, menu click Add/Remove Snap-in.

3. Click Add.

4. Click Active Directory Schema, click Add, click Close, and then click OK.

5. In the console tree, right-click Active Directory Schema, and then click Change Domain

Controller.

6. Click Specify Name, type the name of the domain controller that will be the new role holder, and

then click OK.

7. In the console tree, right-click Active Directory Schema, and then click Operations Master.

8. Click Change.

9. Click OK to confirm that you want to transfer the role, and then click Close.
Transfer the Domain Naming Master Role

1. Click Start, point to Administrative Tools, and then click Active Directory Domains and

Trusts.

2. Right-click Active Directory Domains and Trusts, and then click Connect to Domain

Controller.

NOTE: You must perform this step if you are not on the domain controller to which you want to

transfer the role. You do not have to perform this step if you are already connected to the domain

controller whose role you want to transfer.

3. Do one of the following:

o In the Enter the name of another domain controller box, type the name of the domain

controller that will be the new role holder, and then click OK.

-or-
o In the Or, select an available domain controller list, click the domain controller that will

be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations

Master.

5. Click Change.

6. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles

1. Click Start, point to Administrative Tools, and then click Active Directory Users and

Computers.

2. Right-click Active Directory Users and Computers, and then click Connect to Domain

Controller.

NOTE: You must perform this step if you are not on the domain controller to which you want to

transfer the role. You do not have to perform this step if you are already connected to the domain

controller whose role you want to transfer.

3. Do one of the following:

o In the Enter the name of another domain controller box, type the name of the domain

controller that will be the new role holder, and then click OK.
 -or-
o In the Or, select an available domain controller list, click the domain controller that will

be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and

then click Operations Master.

5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and

then click Change.

6. Click OK to confirm that you want to transfer the role, and then click Close.

Active Directory SRV Records

In order for Active Directory to function properly, DNS servers must provide support for Service
Location (SRV) resource records described in RFC 2052, A DNS RR for specifying the location
of services (DNS SRV). SRV resource records map the name of a service to the name of a server
offering that service. Active Directory clients and domain controllers use SRV records to
determine the IP addresses of domain controllers. Although not a technical requirement of Active
Directory, it is highly recommended that DNS servers provide support for DNS dynamic updates
described in RFC 2136, Observations on the use of Components of the Class A Address Space
within the Internet.

The Windows 2000 DNS service provides support for both SRV records and dynamic updates. If
a non-Windows 2000 DNS server is being used, verify that it at least supports the SRV resource
record. If not, it must be upgraded to a version that does support the use of the SRV resource
record. For example, Windows NT Server 4.0 DNS servers must be upgraded to Service Pack 4
or later to support SRV resource records. A DNS server that supports SRV records but does not
support dynamic update must be updated with the contents of the Netlogon.dns file created by
the Active Directory Installation wizard while promoting a Windows 2000 Server to a domain
controller. The Netlogon.dns file is described in the following section.

So now you understand that Windows 2000 domains rely heavily on DNS entries. If you enable
dynamic update on the relevant DNS zones, W2K creates these entries automatically:

• _ldap._tcp.<DNSDomainName>

Enables a client to locate a W2K domain controller in the domain named by

<DNSDomainName>. A client searching for a domain controller in the domain dpetri.net would
query the DNS server for _ldap._tcp.dpetri.net.

• _ldap._tcp.<SiteName>._sites.<DNSDomainName>
Enables a client to find a W2K domain controller in the domain and site specified (e.g.,
_ldap._tcp.lab._sites.dpetri.net for a domain controller in the Lab site of dpetri.net).

• _ldap._tcp.pdc._ms-dcs.<DNSDomainName>

Enables a client to find the PDC flexible single master object (FSMO) role holder of a mixed-
mode domain. Only the PDC of the domain registers this record.

• _ldap._tcp.gc._msdcs.<DNSTreeName>

Enables a client to find a Global Catalog (GC) server. Only domain controllers serving as GC
servers for the tree will register this name. If a server ceases to be a GC server, the server will
deregister the record.

• _ldap._tcp. ._sites.gc._msdcs.<DNSTreeName>

Enables a client to find a GC server in the specified site (e.g.,

_ldap._tcp.lab._sites.gc._msdcs.dpetri.net).

• _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSTreeName>

Enables a client to find a domain controller in a domain based on the domain controller’s
globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for
referencing Active Directory objects.

• <DNSDomainName>

Enables a client to find a domain controller through a normal Host record.

After running DCPROMO, A text file containing the appropriate DNS resource records for the
domain controller is created. The file called Netlogon.dns is created in the %systemroot
%\System32\config folder and contains all the records needed to register the resource records of
the domain controller. Netlogon.dns is used by the Windows 2000 NetLogon service and to
support Active Directory for non-Windows 2000 DNS servers.

If you are using a DNS server that supports the SRV resource record but does not support
dynamic updates (such as a UNIX-based DNS server or a Windows NT Server 4.0 DNS server),
you can import the records in Netlogon.dns into the appropriate primary zone file to manually
configure the primary zone on that server to support Active Directory.

How to use Active Directory Migration Tool v2.0 to migrate from Windows
2000 to Windows Server 2003?
Warning: If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you can solve
problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

You can use ADMT to migrate users, groups, and computers from one domain to another, and
analyze the migration affect before and after the actual migration process.

Note: This article assumes that the source domain is a Windows 2000-based domain, and that the
target domain is a Windows Server 2003-based domain in Windows 2000 Native mode or later.

How to Set Up ADMT for a Windows 2000 to Windows

Server 2003 Migration
You can install the Active Directory Migration Tool version 2 (ADMTv2) on any computer that
is running Windows 2000 or later, including:

• Microsoft Windows 2000 Professional

• Microsoft Windows 2000 Server
• Microsoft Windows XP Professional
• Microsoft Windows Server 2003

The computer on which you install ADMTv2 must be a member of either the source or the target
domain.

Intraforest Migration
Intraforest migration does not require any special domain configuration. The account you use to
run ADMT must have enough permissions to perform the actions that are requested by ADMT.
For example, the account must have the right to delete accounts in the source domain, and to
create accounts in the target domain.

Intraforest migration is a move operation instead of a copy operation. These migrations are said
to be destructive because after the move, the migrated objects no longer exist in the source
domain. Because the object is moved instead of copied, some actions that are optional in
interforest migrations occur automatically. Specifically, the sIDHistory and password are
automatically migrated during all intraforest migrations.

Interforest Migration
ADMT requires the following permissions to run properly:

• Administrator rights in the source domain.

• Administrator rights on each computer that you migrate.
• Administrator rights on each computer on which you translate security.
Before you migrate a Windows 2000-based domain to a Windows Server 2003-based domain,
you must make some domain and security configurations. Computer migration and security
translation do not require any special domain configuration. However, each computer you want
to migrate must have the administrative shares, C$ and ADMIN$.

The account you use to run ADMT must have enough permissions to complete the required
tasks. The account must have permission to create computer accounts in the target domain and
organizational unit, and must be a member of the local Administrators group on each computer
to be migrated.

User and Group Migration

You must configure the source domain to trust the target domain. Optionally, the target may be
configured to trust the source domain. While this may ease configuration, it is not required to
finish the ADMT migration.

Requirements for Optional Migration Tasks

You can complete the following tasks automatically by running the User Migration Wizard in
Test mode and selecting the migrate sIDHistory option. The user account you use to run ADMT
must be an Administrator in both the source and the target domains for the automatic
configuration to succeed.

1. Create a new local group in the source domain that is named %sourcedomain%$$$.
There must be no members in this group.
2. Turn on auditing for the success and failure of Audit account management on both
domains in the Default Domain Controllers policy.
3. Configure the source domain to allow RPC access to the SAM by configuring the
following registry entry on the PDC Emulator in the source domain with a DWORD
value of 1:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\LSA\TcpipClientSupport

You must restart the PDC Emulator after you make this change.

Note: For Windows 2000 domains, the account you use to run ADMTv2 must have domain
administrator permissions in both the source and target domains. For Windows Server 2003
target domains, the 'Migrate sIDHistory' may be delegated. For more information, see Windows
Server 2003 Help & Support.

You can turn on interforest password migration by installing a DLL that runs in the context of
LSA. By running in this protected context, passwords are shielded from being viewed in
cleartext, even by the operating system. The installation of the DLL is protected by a secret key
that is created by ADMTv2, and must be installed by an administrator.
To install the password migration DLL:

1. Log on as an administrator or equivalent to the computer on which ADMTv2 is installed.

2. At a command prompt, run the ADMT KEY sourcedomainpath [* | password] command
to create the password export key file (.pes). In this example, sourcedomain is the
NetBIOS name of the source domain and path is the file path where the key will be
created. The path must be local, but can point to removable media such as a floppy disk
drive, ZIP drive, or writable CD media. If you type the optional password at the end of
the command, ADMT protects the .pes file with the password. If you type the asterisk
(*), ADMT prompts for a password, and the system will not echo it as it is typed.
3. Move the .pes file you created in step 2 to the designated Password Export Server in the
source domain. This can be any domain controller, but make sure it has a fast, reliable
link to the computer that is running ADMT.
4. Install the Password Migration DLL on the Password Export Server by running the
Pwmig.exe tool. Pwmig.exe is located in the I386\ADMT folder on the Windows Server
2003 installation media, or the folder to which you downloaded ADMTv2 from the
Internet.
5. When you are prompted to do so, specify the path to the .pes file that you created in step
2. This must be a local file path.
6. After the installation completes, you must restart the server.
7. If you are ready to migrate passwords, modify the following registry key to have a
DWORD value of 1. For maximum security, do not complete this step until you are ready
to migrate.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\LSA\AllowPasswordExport

The Active Directory Migration Tool v2 is included in the I386\Admt folder on the Windows
Server 2003 CD.

How to rename the DNS name of a Windows 2000 domain

Although you can rename a Windows 2000 domain in some situations that are described in this article,

Microsoft highly recommends that you decide on the Fully Qualified Domain Name (FQDN) for DNS before

you actually create a new domain or before you upgrade the domain from Windows NT 4.0 to Windows

2000. After you create the domain, you cannot rename a Windows 2000 domain controller. Renaming the

domain involves a considerable amount of work, and it is only possible in a scenario that meets the following

conditions:
 1. You have to keep the Windows 2000 domain in Mixed mode. After you change it to Native mode,

you cannot return the domain to Mixed mode, thereby rendering renaming impossible. To determine

the mode in which the domain is currently running, expand Active Directory Users and Computers,

right-click the domain name, and then click Properties. The mode appears in the Domain

operation mode dialog box. For more information about the different modes, click the following

article number to view the article in the Microsoft Knowledge Base:

186153 Modes supported by Windows 2000 domain controllers

2. Because the domain is in Mixed mode, it must also either have one or more existing Windows NT

4.0 backup domain controllers (BDCs), or computers that are available to use as Windows NT 4.0

BDCs.

Because you must demote all existing Windows 2000 domain controllers to member servers before you

rename the domain controller, review the following information in terms of logistics:

• The renaming can only take place after you revert the domain back to Windows NT 4.0, and then

during the upgrade to Windows 2000, after you have renamed it with the desired DNS (FQDN)

name. The NetBIOS domain name remains the same.

• If you have created one or more child domains, you have to revert the child domains back to

Windows NT 4.0 first, and then revert the parent domain. Next, you rename the parent when you

upgrade it to Windows 2000, and then you bring the child domain up again when you upgrade it to

Windows 2000. The amount of time that this process requires depends on the number of Windows

2000 domain controllers that are in the domain, in addition to their physical location.

Note Renaming a Windows 2000 domain can have implications for any servers in the domain that are based

on Microsoft Exchange 2000 Server or on Microsoft Exchange Server 2003. Because Exchange 2000 Server

and Exchange Server 2003 are closely integrated with the Active Directory directory service, renaming a

domain can stop these servers from working correctly. For more information, click the following article

numbers to view the articles in the Microsoft Knowledge Base:

842116 Supplemental steps for using the Exchange Server Domain Rename Fixup tool together with

the Windows Server 2003 domain rename tools

891370 You receive an error message when Rendom.exe changes the DNS or NetBIOS name of a

domain in Windows Server 2003

MORE INFORMATION

If your scenario meets the conditions listed in the "Summary" section of this article, you can use the

following steps to rename the Windows 2000 domain. These steps involve a single domain situation. If a

child domain exists:

1. Complete the same steps to revert the domain back to Windows NT 4.0 on the child domain first,

and then you stop after you complete step 6.

2. Complete steps 1 through 8 on the parent domain.

3. After you revert the parent domain back to Windows NT 4.0, and then upgrade it back to Windows

2000 with the desired name, you can complete the final upgrade steps to Windows 2000 on the

former child domain, during which you make it a Windows 2000 child domain again.

To rename a Windows 2000 domain

1. Create a backup of any and/or all domain controllers that may be involved in this process.

2. If there are no existing Windows NT 4.0 BDCs in the Windows 2000 domain, then you have to install

one that is preferably running service pack 6 or 6a. If you want, you can install a second BDC and

then physically remove it from the domain to serve as a backup for the domain information as it

contains all of the domain user accounts, and the Security Accounts Manager (SAM) and security

information.

3. Allow sufficient time for this BDC to acquire all domain security and SAM information. To force a full

SAM/security database replication, run the following command on the BDC:

net accounts /sync

A record of the successful full replication events should be logged in the System log.

4. If there is only one Windows 2000 domain controller in the domain, leave the Windows NT 4.0 BDC

connected to the network, and then physically remove the Windows 2000 domain controller from

the network. Make sure that the Windows 2000 domain controller is isolated from the rest of the

network. If it is plugged into a hub, make sure it is not connected to the rest of the domain. If you

have only one Windows 2000 domain controller, you can perform step 6 now before you continue

with the demotion of the Windows 2000 domain controller.

5. You must now demote all the Windows 2000 domain controllers to member servers by running the

dcpromo command on the actual domain controller. To run this command, click Start, click Run,
 type dcpromo, and then click OK. If there are more than one Windows 2000 domain controller, run

dcpromo on each of them to make each one a member server, until there is only one Windows 2000

domain controller remaining.

Now you can disconnect the Windows 2000 domain controller from the network, while leaving the

Windows NT 4.0 BDC connected. Run dcpromo on this last domain controller, and be sure to

choose the last domain controller in the domain option. When this completes, and the computer

restarts, it will be a member server in a work group, which you can then rejoin to the domain if you

want to. If you disconnected one Windows 2000 domain controller in step 4, then you simply run

the dcpromo command on it as described in this step.

Note: To run dcpromo successfully, the network adapter must detect a network connection.

Therefore, the Windows 2000 domain controller must be attached to an active hub or switch, even if

there are no other connections to the hub or switch, and it is isolated from everything else which is

desired.

6. Open Server Manager on the Windows NT 4.0 BDC and promote this computer to a primary domain

controller (PDC). If a message appears stating that it cannot contact the PDC and asks if you want

to continue, click Yes, and then complete the promotion. When this is complete and the server

restarts, verify in Server Manager that the computer it is now described as the PDC.

7. Upgrade this Windows NT 4.0 PDC to Windows 2000. When the Windows 2000 upgrade is complete,

the computer restarts to begin the Active Directory installation. During this process, enter the

desired domain name.

8. If you have demoted other Windows 2000 domain controllers earlier, you can now promote them

back to domain controllers by running dcpromo on them.