Active Directory Groups

Group Types

• Security groups: Use Security groups to grant permission to gain access to resources. Sending an e-mail message to a group sends the message to all group members. Therefore, security groups share the capabilities of distribution groups.
• Distribution groups: Distribution groups are used for sending e-mail messages to groups of users. Permissions cannot be granted to security groups. Even though security groups have all the capabilities of distribution groups, distribution groups are still required because some applications can only read distribution groups.

Group Scopes

Group scope normally describes the type of users that should be clubbed together in a way that is easy for their administration. Therefore, groups play an important part in domain. One group can be a member of other group(s), which is known as Group nesting. One or more groups can be members of any group in the entire domain(s) within a forest.

• Domain Local Group: Use this scope to grant permissions to domain resources that are located in the same domain in which the domain local group was created. Domain local groups can exist in all mixed, native, and interim functional level of domains and forests. Domain local group memberships are not limited as users can add members as user accounts and universal and global groups from any domain. Nesting cannot be done in a domain local group. A domain local group will not be a member of another Domain Local or any other groups in the same domain.
• Global Group: Users with similar functions can be grouped under global scope and can be given permission to access a resource (like a printer or shared folder and files) available in local or another domain in the same forest. Simply put, global groups can be use to grant permissions to gain access to resources that are located in any domain but in a single forest as their memberships are limited. User accounts and global groups can be added only from the domain in which the global group is created. Nesting is possible in Global groups within other groups as users can add a global group into another global group from any domain.They can be members of a Domain Local group to provide permission to domain specific resources (like printers and published folder). Global groups exist in all mixed, native, and interim functional level of domains and forests.
• Universal Group Scope: these groups are precisely used for email distribution and can be granted access to resources in all trusted domain as these groups can only be used as a security principal (security group type) in a windows 2000 native or windows server 2003 domain functional leveldomain. Universal group memberships are not limited like global groups. All domain user accounts and groups can be a member of a universal group. Universal groups can be nested under a global or Domain Local group in any domain.

Built-in and Predefined Groups

In addition to built-in groups, domain controllers have default pre-defined groups. When a computer becomes a domain controller, Windows Server 2003 automatically creates these groups in Active Directory Users and Computers.

• Built-in Domain Local Groups: These groups provide users with pre-defined rights and permissions to perform tasks on domain controllers and in active directory.
• Special Identities: These groups, also known as special groups, automatically organize users for system use. Administrators do not assign users to them. Rather, users are either members by default or become members during network activity. Special groups are not visible in active directory users and computers.
• Pre-defined Global Groups: These groups give administrators an easy mode of controlling all users in a domain. Pre-defined global groups are on domain controllers only.

Using DSADD.exe to Create Users in Active Directory

Ok in system administration field , we get common scenario to add multiple user in Active Directory 

(Multiple user creation)

so here i tried out using dsadd command line tool..

So, I set up a user, called cc70215. Since I want him in his proper OU, I set him up as cn=cc70215,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com. This was no big deal, I already had the list of users, just copy/paste and some text replacement set up the list of users. With all I wanted to do, I set up the command as such: 

DSADD user cn=cc70215,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com -display cc70215 -pwd mypassword -office "Call Center" -title "Customer Service Associate" -dept Collections -loscr cc_li.vbs -mustchpwd yes -canchpwd yes -disabled yes

A success message will return if successful and navigating to the CallCenter, Users OU will reveal my new account. But this is a pain to create multiple users at a times. So, I got dirty a bit and cheated with the batch script FOR command. First, I got all my users in a comma-separated list. I also had to put quotes around each user. A quick text replacement in my favorite text editor (Notepad2) did the trick. Then I created a batch file, and put in the following:

FOR %%D in ("cn=cc70216,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70217,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70218,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70219,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70220,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com") DO DSADD user %%D -display %%D -pwd mypassword -office "Call Center" -title "Customer Service Associate" -dept Collections -loscr cc_li.vbs -mustchpwd yes -canchpwd yes -disabled yes

For this example I only used 5 users, but you get the point.

Put a pause and exit in there and run it as a domain admin. With all luck, your accounts will show up in no time. Now, I did find one issue with this method. Here I'm telling it to set the -display (Display Name) with the variable %%D. What this does is set the Display Name for the account as "cn=cc70216,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", which is not ideal.

To address this issue we can use batch file.

Command	Description
Dsadd computer	Adds a single computer to the directory.
Dsadd contact	Adds a single contact to the directory.
Dsadd group	Adds a single group to the directory.
Dsadd ou	Adds a single organizational unit to the directory.
Dsadd user	Adds a single user to the directory.
Dsadd quota	Adds a quota specification to a directory partition.

DHCP Server and Clients Communication

1. The DHCP client broadcasts a DHCP discover message to the local subnet.
2. A DHCP server can respond with a DHCP offer message (DHCPOFFER) that contains an offered IP address for lease to the client.
3. If no DHCP servers respond to the client discovery request, the client can proceed in either of two ways:
   • If the client is running under Windows 2000 and IP auto-configuration has not been disabled, the client self-configures an IP address for use with automatic client configuration.
   • If the client is not running under Windows 2000 (or IP auto-configuration has been disabled), the client fails to initialize. Instead, if left running, it continues to resend DHCP discover messages in the background (four times every five minutes) until it receives a DHCP offer message from a server.
4. As soon as a DHCP offer message is received, the client selects the offered address by replying to the server with a DHCP request.
5. Typically, the offering server sends a DHCP acknowledgement message (DHCPACK) , approving the lease.
   Also, other DHCP options information is included in the acknowledgement.
6. Once the client receives acknowledgment, it configures its TCP/IP properties using the information in the reply and joins the network.

Superscopes in DHCP

A superscope is an administrative feature of DHCP servers running Windows Server 2003 that you can create and manage through the DHCP console. Using a superscope, you can group multiple scopes as a single administrative entity. With this feature, a DHCP server can:

• Support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) where multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are often called multinets.
• Support remote DHCP clients located on the far side of DHCP and BOOTP relay agents (where the network on the far side of the relay agent uses multinets).

In multinet configurations, you can use DHCP superscopes to group and activate individual scope ranges of IP addresses used on your network. In this way, the DHCP server computer can activate and provide leases from more than one scope to clients on a single physical network.

Superscopes can resolve certain types of DHCP deployment issues for multinets, including situations in which:

• The available address pool for a currently active scope is nearly depleted, and more computers need to be added to the network. The original scope includes the full addressable range for a single IP network of a specified address class. You need to use another IP network range of addresses to extend the address space for the same physical network segment.
• Clients must be migrated over time to a new scope (such as to renumber the current IP network from an address range used in an existing active scope to a new scope that contains another IP network range of addresses).
• You want to use two DHCP servers on the same physical network segment to manage separate logical IP networks.

Example 1: Non-routed DHCP server (before superscope)

Example 2: Superscope for non-routed DHCP server supporting local multinets

Conditional Forwarding in Windows 2003 DNS

Let us begin by discovering where you configure Conditional Forwarding.  Start at the server icon in the DNS snap-in (not the Forward Lookup Zone).  right-click, properties, Forwarders (Tab).

Take the scenario where shootemup.com is an associate of your organization.  Moreover, your users are for ever querying their server.  If shootemup.com kindly provide the IP address of their server which is authoritative for shootemup.com then you can configure that server as a conditional forwarder.

To summarise, the Condition is that one of your clients query is for shootemup.com.  The Forwarding is to the IP address specified at the Forwarders tab of your DNS server.

So what would happen without Conditional Forwarding?  The answer is that your server would ' walk the root hints '.  The server (Alan in the diagram), contacts the root server ' . ' on the internet.  The root server forwards your request to the .com server who in turn forwards the request to shootemup.com's server.

In a nutshell, Conditional Forwarding is like taking a short cut.

DNS Root Hints

Well at some point your DNS server is going to have to query other DNS servers for domains that it is not authorative for. Your two choices for this are: 1. Using forwarders or 2. Using the root hint servers.

If you choose to use forwarders then you'll need to set them up in the properties of your DNS server. Then when your DNS server gets a DNS query for a domain that it is not authorative for it will forward the query to the forwarder, which will then do the work of resolving the query if it's configured to perform iteration or if it's not it will tell your DNS server where to go next.

If you choose to use the root hint servers, then when your DNS servers gets a DNS query for a domain that it is not authorative for it will query one of the root hint servers (which will not perform iteration) which will tell your DNS server where to go next. IMHO, there's no real workload on a DNS server for it to resolve DNS queries unless you have thousands of queries per second needing to be resolved.

Your server should not be listed in the root hint servers as your server is not one of the root hint servers.

I prefer to use the root hint servers. I don't like to rely on forwarders as then my DNS queries are dependent on the forwarders being available, working properly, performing iteration, etc., etc.

If the root hint servers aren't working (which is highly unlikely) then nobody in the world is going to have a working DNS anyway so it won't matter that my DNS won't be working at that point (for external DNS queries only).

Every Windows server comes pre-configured with a physical file called cache.dns.  Inside cache.dns are the IP addresses of a dozen 'well-known' servers which hold information about the .com, .net, .org and other top level domains (TLD).  You can inspect this file in the %systemroot%\windows32\dns\samples folder.



Point each DNS server at itself for the preferred DNS server and the other server for the alternate DNS server in IP address configuration for DNS servers.

Rogue DHCP

A rogue DHCP server is a DHCP server on a network which is not under the administrative control of the network staff. It is a network device such as a modem or a router connected to the network by a user who may be either unaware of the consequences of their actions or may be knowingly using it for network attacks such as man in the middle. Some kind of computer viruses or malicious software have been found to setup a rogue DHCP, especially for those classified in the "Rootkit" category.

As clients connect to the network, both the rogue and legal DHCP server will offer them IP addresses as well as default gateway, DNS servers, WINS servers, among others. If the information provided by the rogue DHCP differs from the real one, clients accepting IP addresses from it may experience network access problems, including speed issues as well as inability to reach other hosts because of incorrect IP network or gateway. In addition, if a rogue DHCP is set to provide as default gateway an IP address of a machine controlled by a misbehaving user, he can sniff all the traffic sent by the clients to other networks, violating network security policies as well as user privacy (see man in the middle). VMware or virtual machine software can also act as a rogue DHCP server inadvertently when being run on a client machine joined to a network. The VMware will act as a rogue DCHP server handing out random IP addresses to the clients around it on the network. The end result can be that large portions of the network are then cutoff from both the Internet and the rest of the domain without any access at all.

Rogue DHCP servers can be stopped by means of intrusion detection systems with appropriate signatures as well as by some multilayer switches, which can be configured to drop the packets.

What is the difference between a Container and an OU in Active Directory?

An Organizational Unit (OU) is a special purpose container, that differs from a regular container in that administrators can apply group policy to an OU, which the system then pushes down to all the computers that reside in the OU. You cannot apply group policy to a container. 

In general, you design an OU hierarchy which is based on how you want to have Group Policy flow out to the domain-joined machines in your AD.

Implementing Mandatory Roaming Profiles

Setting Up the Base Profile

"The first thing you will want to do is set up a model profile on a workstation (preferably an identical one to the workstations in the lab) that will serve as the profile that everyone sees when they log into a computer. Here you will want to make sure you have configured all desktop settings, shortcut icons, and installed printers correctly as to how they will appear on all other workstations.

Copying the Profile to a Server

"Once you have your profile set up how you want it, the next step is to copy the profile to a server. It is important that you set the permissions on the folder holding the profile so that all users accessing it will have complete read-and-write access to it. Once set up, the workstations will pull each user profile from this location. In order to properly copy this profile to a server, there are a few steps you need to complete. Logging in as a user other than the one used to make your model profile, you will need to right-click "My Computer" and then select "Properties." Navigate to the "Advanced" tab and click "Settings" under User Profiles (Figure 1):

Figure 1: Accessing the User Profiles settings

"In the User Profiles dialog box that opens, select your model profile in the list and click the "Copy to" button. You will then be prompted to select the location where you want to store the profile (Figure 2). After you have done this, you must click the "Change" button and add the Authenticated Users group to the profile's ACL. This ensures that all domain users who are authenticated will have rights to access the profile. Proceed to "OK" out of any remaining dialog boxes.

Figure 2: Copying the base profile to a server

Making the Profile Mandatory

"The next step in creating your profile is the actual process of making it mandatory and therefore unchangeable. This can be done by browsing to the location of your saved profile on the server and locating the NTUSER.dat file (make sure hidden files are set to be visible). Once you have located this file, you can simply rename it toNTUSER.man to make it mandatory.

Configuring the User Accounts

"The last remaining step is to configure your user accounts to utilize the mandatory profile we have set up. In order to accomplish this, we must begin in the Active Directory Users and Computers MMC snap-in. Once you have this open, navigate to one of the user accounts you want to utilize the mandatory profile. Once you have located this user, right-click on their name and select "Properties." Navigate to the "Profile" tab and locate the "Profile Path" box, and type the UNC path to the folder where the mandatory profile is located and click "OK" (Figure 3). You can then proceed to do this to every account that will be accessing this profile.

Figure 3: Setting a user account to point to the mandatory profile

"With those steps completed, you have successfully set up mandatory profiles for your user population. You should now no longer have to worry about users changing their profile settings.

Mandatory Profile Best Practices

"When dealing with mandatory profiles, there is a common misconception that they are often more trouble than they are worth. The problem lies in the fact that so many things can have an effect on your mandatory profile setup. This being said, there are some practices you will want to keep in mind when managing your network to make sure your mandatory profile implementation works without a hitch.

"The problem that most network administrators commonly see is slow performance when loading a user's mandatory profile. The main cause of this is usually a bloated base profile. If you load up your base profile with tons of files and data, this will cause the profile to grow in size, which can cause a large time delay when transferring the profile from server to client. If you must have this much data available to users, it is best to find another method of delivery, such as a mapped network drive to a shared storage location.

"Along with the concerns of performance, sometimes administrators can be thrown for a loop when previously utilized features don't work or cause problems after implementing mandatory profiles. A good example of this is use of the Encrypted File System (EFS). EFS is something that is not supported for use with mandatory or roaming profiles.

"Finally, we need to consider security when implementing mandatory profiles. The main focus of security in this case is the folder storing the mandatory profile. This folder contains the data that will be transferred to every workstation a mandatory profile user logs into. Therefore, it is extremely important that it be secure. The best way to secure this folder, as with any other network resource, is through NTFS permissions. You should make sure that your base profile folder resides on a server that utilizes NTFS, and develop a strong permissions policy for these folders.

How to configure a user account to use a roaming user profile in Windows Server 2003, Windows 2000 Server, or Windows NT 4.0

As One of the my friend requested me to Add some article on Roaming profile configuration Steps ......... so here is the detail about how to configure roaming profile.

This step-by-step article describes how to configure a user account to use a roaming user profile. To do so, you must create a shared folder to store roaming user profiles, and then configure the user account to use a roaming user profile. After you complete this procedure, the user's profile, including the user's unique desktop settings, is stored on a server, and the profile is available to the user when the user logs on to any Windows NT 4.0-based computer in the domain.

Requirements

• A Windows NT Server 4.0-based computer (that meets the requirements listed on the Hardware Compatibility List [HCL]) that is a primary domain controller must be available on the network when you configure the user account.
• If you decide not to store roaming user profiles on the primary domain controller, an additional Windows NT Server 4.0-based computer must be available on the network.

How to Create a Shared Folder to Store Roaming User Profiles

Before you configure a user account to use a roaming user profile, you must create a shared folder on a Windows NT Server 4.0-based computer in the domain to store the roaming user profiles. This shared folder is often located on a domain controller, but it can also be located on any Windows NT Server 4.0-based computer in the domain.

To create a shared folder to store roaming user profiles:

1. Click Start, point to Programs, and then click Windows NT Explorer.
2. Click the drive on which you want to create a shared folder to store roaming user profiles.
3. On the File menu, point to New, and then click Folder.
4. Type a name for the new folder, and then press ENTER. 
   
   NOTE: Typically, the folder that is used to store roaming user profiles is called "Profiles". However, you can assign any name that you want to the folder.
5. Right-click the folder you created in step 3, and then click Sharing.
6. Click Shared As, type the name that you want to assign to the shared folder in the Share Name box, and then clickOK.
   
   NOTE: The Profiles folder is commonly shared as "Profiles."
7. Quit Windows NT Explorer.

How to Configure a User Account to Use a Roaming User Profile in a Windows-Based Domain

To configure user accounts in the domain, you can use any Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003-based computer in the domain or any Windows NT Workstation 4.0, Windows XP Professional, or Windows 2000 Professional-based computer that is running Windows NT Server Administration Tools in the domain. In addition, you must be logged on as either an administrator or as a user that is a member of the Administrators local group or the Account Operators local group in the domain. 

To configure a user account to use a roaming user profile:

1. Click Start, point to Programs, point to Administrative Tools (Common), and then click User Manager for Domains or Active Directory Users and Computers for Windows Server 2000 or for Windows Server 2003.
2. Double-click the user account to which you want to assign a roaming profile, and then click Profile.
3. Type the complete path to the shared folder that contains the user's profile in the User Profile Path box, and then click OK. 
   
   Use the following format for the user profile path:
   \\server_name\shared_folder_name\user_profile_folder_name
   For example, if you want to store the user's roaming profile in a folder that has the same name as the user account in a shared folder that is named "Profiles" on a server that is named "Server1," type the following path:
   \\Server1\Profiles\%username%
   NOTE: Windows NT automatically replaces the %username% variable with the user account name when it creates and accesses the user profile. When you use this variable, you can type the same path for all users.
4. Click OK, and then quit User Manager for Domains or Active Directory Users and Computers.

The next time the user logs on, the user profile folder that you specified in step 3 is created. When the user logs off, the user's profile is copied to the new folder.

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 thefsmo 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
   • 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
   • 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
   • 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.
   • 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.
   • 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.