Transferring FSMO Roles

 

Transferring FSMO Roles

 

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	Domain Admins
PDC Emulator
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

To Transfer the Schema Master Role:

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

regsvr32 schmmgmt.dll

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

3. From the Run command open an MMC Console by typing MMC.

4. On the Console menu, press Add/Remove Snap-in.

5. Press Add. Select Active Directory Schema.

6. Press Add and press Close. Press OK.

7. If you are NOT logged onto the target domain controller, in the snap-in, right-click the Active Directory Schema icon in the Console Root and press Change Domain Controller.

8. Press Specify .... and type the name of the new role holder. Press OK.

9. Right-click right-click the Active Directory Schema icon again and press Operation Masters.

10. Press the Change button.

11. Press OK all the way out.

Transferring the FSMO Roles via Ntdsutil

To transfer the FSMO roles from 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:

2. 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.

3. Type connections, and then press ENTER.

fsmo maintenance: connections server connections:

4. 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:

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

server connections: q fsmo maintenance:

6. Type transfer <role>. where <role> is the role you want to transfer.

For example, to transfer the RID Master role, you would type transfer rid master:

Options are:

Transfer domain naming master Transfer infrastructure master Transfer PDC Transfer RID master Transfer schema master

7. You will receive a warning window asking if you want to perform the transfer. Click on Yes.

8. After you transfer the roles, type q and press ENTER until you quit Ntdsutil.exe.

9. Restart the server and make sure you update your backup.

Seizing FSMO Roles

Seizing FSMO Roles

 

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
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.
Domain Naming	Unless you are going to run DCPROMO, then you will not miss this FSMO role.
RID	Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you're building hundreds of users or computer object per week.
PDC Emulator	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 not be able to change or troubleshoot group policies and password changes will become a problem.
Infrastructure	Group memberships may be incomplete. If you 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	Original must be reinstalled
Domain Naming
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	Domain Admins
PDC Emulator
Infrastructure

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

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:

2. 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.

3. Type connections, and then press ENTER.

fsmo maintenance: connections server connections:

4. 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:

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

server connections: q fsmo maintenance:

6. Type seize <role>, where <role> is the role you want to seize. For example, to seize the RID Master role, you would type seize rid master:

Options are:

Seize domain naming master Seize infrastructure master Seize PDC Seize RID master Seize schema master

7. You will receive a warning window asking if you want to perform the seize. Click on Yes.

   

fsmo maintenance: Seize infrastructure master Attempting safe transfer of infrastructure FSMO before seizure. ldap_modify_sW error 0x34(52 (Unavailable). Ldap extended error message is 000020AF: SvcErr: DSID-03210300, problem 5002 (UNAVAILABLE) , data 1722  Win32 error returned is 0x20af(The requested FSMO operation failed. The current FSMO holde r could not be contacted.) ) Depending on the error code this may indicate a connection, ldap, or role transfer error. Transfer of infrastructure FSMO failed, proceeding with seizure ... Server "server100" knows about 5 roles Schema - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net Domain - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net PDC - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net RID - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net Infrastructure - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net fsmo maintenance:

Note: All five roles need to be in the forest. If the first domain controller is out of the forest then seize all roles. Determine which roles are to be on which remaining domain controllers so that all five roles are not on only one server.

8. Repeat steps 6 and 7 until you've seized all the required FSMO roles.

9. After you seize or transfer the roles, type q, and then press ENTER until you quit the Ntdsutil tool.

Note: Do not put the Infrastructure Master (IM) role on the same domain controller as the Global Catalog server. If the Infrastructure Master runs on a GC server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest.

Transferring FSMO Roles

 

Transferring FSMO Roles

 

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	Domain Admins
PDC Emulator
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

To Transfer the Schema Master Role:

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

regsvr32 schmmgmt.dll

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

3. From the Run command open an MMC Console by typing MMC.

4. On the Console menu, press Add/Remove Snap-in.

5. Press Add. Select Active Directory Schema.

6. Press Add and press Close. Press OK.

7. If you are NOT logged onto the target domain controller, in the snap-in, right-click the Active Directory Schema icon in the Console Root and press Change Domain Controller.

8. Press Specify .... and type the name of the new role holder. Press OK.

9. Right-click right-click the Active Directory Schema icon again and press Operation Masters.

10. Press the Change button.

11. Press OK all the way out.

Transferring the FSMO Roles via Ntdsutil

To transfer the FSMO roles from 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:

2. 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.

3. Type connections, and then press ENTER.

fsmo maintenance: connections server connections:

4. 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:

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

server connections: q fsmo maintenance:

6. Type transfer <role>. where <role> is the role you want to transfer.

For example, to transfer the RID Master role, you would type transfer rid master:

Options are:

Transfer domain naming master Transfer infrastructure master Transfer PDC Transfer RID master Transfer schema master

7. You will receive a warning window asking if you want to perform the transfer. Click on Yes.

8. After you transfer the roles, type q and press ENTER until you quit Ntdsutil.exe.

9. Restart the server and make sure you update your backup.

Seizing FSMO Roles

Seizing FSMO Roles

 

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
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.
Domain Naming	Unless you are going to run DCPROMO, then you will not miss this FSMO role.
RID	Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you're building hundreds of users or computer object per week.
PDC Emulator	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 not be able to change or troubleshoot group policies and password changes will become a problem.
Infrastructure	Group memberships may be incomplete. If you 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	Original must be reinstalled
Domain Naming
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	Domain Admins
PDC Emulator
Infrastructure

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

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:

2. 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.

3. Type connections, and then press ENTER.

fsmo maintenance: connections server connections:

4. 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:

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

server connections: q fsmo maintenance:

6. Type seize <role>, where <role> is the role you want to seize. For example, to seize the RID Master role, you would type seize rid master:

Options are:

Seize domain naming master Seize infrastructure master Seize PDC Seize RID master Seize schema master

7. You will receive a warning window asking if you want to perform the seize. Click on Yes.

   

fsmo maintenance: Seize infrastructure master Attempting safe transfer of infrastructure FSMO before seizure. ldap_modify_sW error 0x34(52 (Unavailable). Ldap extended error message is 000020AF: SvcErr: DSID-03210300, problem 5002 (UNAVAILABLE) , data 1722  Win32 error returned is 0x20af(The requested FSMO operation failed. The current FSMO holde r could not be contacted.) ) Depending on the error code this may indicate a connection, ldap, or role transfer error. Transfer of infrastructure FSMO failed, proceeding with seizure ... Server "server100" knows about 5 roles Schema - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net Domain - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net PDC - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net RID - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net Infrastructure - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net fsmo maintenance:

Note: All five roles need to be in the forest. If the first domain controller is out of the forest then seize all roles. Determine which roles are to be on which remaining domain controllers so that all five roles are not on only one server.

8. Repeat steps 6 and 7 until you've seized all the required FSMO roles.

9. After you seize or transfer the roles, type q, and then press ENTER until you quit the Ntdsutil tool.

Note: Do not put the Infrastructure Master (IM) role on the same domain controller as the Global Catalog server. If the Infrastructure Master runs on a GC server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest.

Planning FSMO Roles in Active Directory

Planning FSMO Roles in Active Directory

 

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.
Domain Naming	Unless you are going to run DCPROMO, then you will not miss this FSMO role.
RID	Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you're building hundreds of users or computer object per week.
PDC Emulator	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 not be able to change or troubleshoot group policies and password changes will become a problem.
Infrastructure	Group memberships may be incomplete. If you 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.

Working with Group Policy

Working with Group Policy

 

Group Policy is a one of the most useful tools found in the Windows 2000/2003 Active Directory infrastructure. Group Policy can help you do the following:

1. Configure user's desktops

2. Configure local security on computers

3. Install applications

4. Run start-up/shut-down or logon/logoff scripts

5. Configure Internet Explorer settings

6. Redirect special folders

In fact, you can configure any aspect of the computer behavior with it. Although it is a cool toy; working with it without proper attention can cause unexpected behavior.

Terms

Here are some basic terms you need to be familiar with before drilling down into Group Policy:

Local policy - Refers to the policy that configures the local computer or server, and is not inherited from the domain. You can set local policy by running gpedit.msc from the Run command, or you can add "Group Policy Object Editor" snap-in to MMC. Local Policies also exist in the Active Directory environment, but have many fewer configuration options that the full-fledged Group Policy in AD.

GPO - Group Policy Object - Refers to the policy that is configured at the Active Directory level and is inherited by the domain member computers. You can configure a GPO – Group Policy Object - at the site level, domain level or OU level.

GPC – Group Policy Container - The GPC is the store of the GPOs; The GPC is where the GPO stores all the AD-related configuration. Any GPO that is created is not effective until it is linked to an OU, Domain or a Site. The GPOs are replicated among the Domain Controllers of the Domain through replication of the Active Directory.

GPT - Group Policy Templates - The GPT is where the GPO stores the actual settings. The GPT is located within the Netlogon share on the DCs.

Netlogon share - A share located only on Domain Controllers and contains GPOs, scripts and .POL files for policy of Windows NT/98. The Netlogon share replicates among all DCs in the Domain, and is accessible for read only for the Everyone group, and Full Control for the Domain Admins group. The Netlogon's real location is:

C:\WINDOWS\SYSVOL\sysvol\domain.com\SCRIPTS

When a domain member computer boots up, it finds the DC and looks for the Netlogon share in it.

To see what DC the computer used when it booted, you can go to the Run command and type %logonserver%\Netlogon. The content of the Netlogon share should be the same on all DCs in the domain.

GPO behavior

Group Policy is processed in the following order:

Local Policy > Site GPO > Domain GPO > OU GPO > Child OU GPO

and so on.

GPOs inherited from the Active Directory are always stronger than local policy. When you configure a Site policy it is being overridden by Domain policy, and Domain policy is being overridden by OU policy. If there is an OU under the previous OU, its GPO is stronger the previous one.

The rule is simple, as more you get closer to the object that is being configured, the GPO is stronger.

What does it mean "stronger"? If you configure a GPO and linke it to "Organization" OU, and in it you configure Printer installation – allowed and then at the "Dallas" OU you configured other GPO but do not allow printer installation, then the Dallas GPO is more powerful and the computers in it will not allow installation of printers.

The example above is true when you have different GPOs that have similar configuration, configured with opposite settings. When you apply couple of GPOs at different levels and every GPO has its own settings, all settings from all GPOs are merged and inherited by the computers or users.

Group Policy sections

Each GPO is built from 2 sections:

• Computer configuration contains the settings that configure the computer prior to the user logon combo-box.

• User configuration contains the settings that configure the user after the logon. You cannot choose to apply the setting on a single user, all users, including administrator, are affected by the settings.

Within these two section you can find more sub-folders:

• Software settings and Windows settings both of computer and user are settings that configure local DLL files on the machine.

• Administrative templates are settings that configure the local registry of the machine. You can add more options to administrative templates by right clicking it and choose .ADM files. Many programs that are installed on the computer add their .ADM files to %systemroot%\inf folder so you can add them to the Administrative Templates.

You can download .ADM files for the Microsoft operating systems

Tools used to configure GPO

You can configure GPOs with these set of tools from Microsoft (other 3rd-party tools exist but we will discuss these in a different article):

1. Group Policy Object Editor snap-in in MMC - or - use gpedit.msc from the Run command.

2. Active Directory Users and Computers snap in - or dsa.msc – to invoke the Group Policy tab on every OU or on the Domain.

3. Active Directory Sites and Services - or dssite.msc – to invoke the Group Policy tab on a site.

4. Group Policy Management Console - or gpmc.msc - this utility is NOT included in Windows 2003 server and needs to be separately installed. You can download it from HERE

Note that if you'd like to use the GPMC tool on Windows XP, you need to install it on computers running Windows XP SP2. Installing it on computers without SP2 will generate errors due to unsupported and newer .ADM files.

GPMC utility - Creating a GPO

When you create a GPO it is stored in the GPO container. After creation you should link the GPO to an OU that you choose.

Linking a GPO

To link a GPO simply right click an OU and choose Link an existing GPO or you can create and link a GPO in the same time. You can also drag and drop a GPO from the Group Policy Objects folder to the appropriate Site, Domain or OU.

When you right-click a link you can:

Edit a GPO - This will open the GPO window so you can configure settings.

Link/Unlink a GPO - This setting allows you to temporarily disable a link if you need to add settings to it or if you will activate it later.

Enabling/disabling computer or user settings

GPO has computer and user settings but if you create a GPO that contains only computer settings, you might want to disable the user settings in that GPO, this will reduce the amount of settings replicated and can also be used for testing.

To disable one of the configurations simply choose the GPO link and go to Details tab:

How do I know what are the settings in a GPO?

Prior to the use of GPMC, an administrator who wanted to find out which one of the hundreds of settings of a GPO were actually configured - had to open each GPO and manually comb through each and every node of the GPO sections. Now, with GPMC, you can simply see what the configurations of any GPO are if you point on that GPO and go to the Settings tab. There you can use the drop-down menus to see computer or user settings.

Block/Enforce inheritance

You can block policy inheritance to an OU if you don't want the settings from upper GPOs to configure your OU.

To block GPO inheritance, simply right click your OU and choose "Block Inheritance". Blocking inheritance will block all upper GPOs.

In case you need one of the upper GPOs to configure all downstream OUs and overcome Block inheritance, use the Enforce option of a link. Enforcing a GPO is a powerful option and rarely should be used.

You can see in this example that when you look at Computers OU, three different GPOs are inherited to it.

In this example you can see that choosing "Block inheritance" will reject all upper GPOs.

Now, if we configure the "Default domain policy" with the Enforce option, it will overcome the inheritance blocking.

Link order

When linking more than one GPO to an OU, there could be a problem when two or more GPOs have the same settings but with opposite configuration, like, GPO1 have Allow printer installation among other settings but GPO2 is configured to prevent printer installation among other settings. Because the two GPOs are at the same level, there is a link order which can be changed.

The GPO with the lowest link order is processed last, and therefore has the highest precedence.

Security Filtering

Filtering let you choose the user, group or computer that the GPO will apply onto. If you configured "Computers" OU with a GPO but you only want to configure Win XP stations with that GPO and exclude Win 2000 stations, you can easily create a group of Win XP computers and apply the GPO only to that group.

This option save you from creating complicated OU tree with each type of computer in it.

A user or a group that you configure in the filtering field have by default the "Read" and "Apply" permission. By default when you create a GPO link, you can see that "Authenticated users" are listed.

In the above example, Office 2K3 will be installed on all computers that are part of the two listed groups.

If we still were using Authenticated users, the installation of the Office suite could have followed the user to any computer that he logs onto, like servers or other machines. Using filtering narrows the installation options.

If you want to configure these permissions with higher resolution, you can go to Delegation tab and see the permissions. Going to the Advanced Tab will let you configure the ACL permission with the highest resolution.

How the GPO is updated on the computers

GPO inherited from AD is refreshed on the computers by several ways:

1. Logon to computer (If the settings are of "user settings" in GPO)

2. Restart of the computer (If the settings are of "computer settings" in GPO)

3. Every 60 to 90 minutes, the computers query their DC for updates.

4. Manually by using gpupdate command. You can add the /force switch to force all settings and not only the delta.

Note: Windows 2000 doesn't support the Gpupdate command so you need run a different command instead:

Secedit /refreshpolicy machine_policy

for computer settings.

Secedit /refreshpolicy user_policy

for user settings.

In both commands you can use the /enforce that is similar to the /force in gpupdate.

If any configuration change requires a logoff or a restart message will appear:

You can force logoff or reboot using gpupdate switches.

How to check that the GPO was deployed

To be sure that GPO was deployed correctly, you can use several ways. The term for the results is called RSoP – Resultant Sets of Policies.

1. Use gpresult command in the command prompt.

The default result is for the logged on user on that machine. You can also choose to check what is the results for other users on to that machine. If you use /v or /z switches you will get very detailed information.

You can see what GPOs were applied and what GPOs were filtered out and the reason for not being deployed.

Microsoft (R) Windows (R) XP Operating System Group Policy Result tool v2.0 Copyright (C) Microsoft Corp. 1981-2001 Created On 04/24/2005 RSOP results for XPPRO\Administrator on XPPRO: Logging Mode ------------------------------------------------------------------------- OS Type: Microsoft Windows XP Professional OS Configuration: Member Workstation OS Version: 5.1.2600 Domain Name: NWTRADERS Domain Type: WindowsNT 4 Site Name: N/A Roaming Profile: Local Profile: C:\Documents and Settings\Administrator Connected over a slow link?	No  COMPUTER SETTINGS ------------------------- Last time Group Policy was applied: 04/24/2005 Group Policy was applied from: london.nwtraders.msft Group Policy slow link threshold: 500 kbps  Applied Group Policy Objects -------------------------------- Default Domain Policy Raanana WSUS Updates Local Group Policy  The following GPOs were not applied because they were filtered out ---------------------------------------------------------------------------- Raanana XP SP2 Behavior Filtering: Not Applied (Empty)  The computer is a part of the following security groups: -------------------------------------------------------------- BUILTIN\Administrators Everyone Debugger Users BUILTIN\Users NT AUTHORITY\NETWORK NT AUTHORITY\Authenticated Users  USER SETTINGS -------------- Last time Group Policy was applied: 04/24/2005 Group Policy was applied from: N/A Group Policy slow link threshold: 500 kbps  Applied Group Policy Objects -------------------------------- Local Group Policy  The user is a part of the following security groups: ---------------------------------------------------- Everyone, BUILTIN\Administrators, Remote Desktop Users, BUILTIN\Users, LOCAL, NT AUTHORITY\INTERACTIVE, NT AUTHORITY\Authenticated Users

2. Resultant Set of Policy snap-in in MMC.

The snap-in has two modes:

Logging mode which tells you what are the real settings that were deployed on the machine

Planning mode which tells you what will be the results if you choose some options.

This option is not so compatible because you need to browse in the RSoP data to find the settings.

3. Group Policy Results in GPMC.

This is the most comfortable option that let you check the RSoP data on every computer or user from a central location. This option also displays the summary of the RSoP and Detailed RSoP data in HTML format.

In the example above example you can see the summary of applied or non applied GPOs both of computer and user settings.

When looking at the Settings tab we can see what settings did applied on the computer and see which is the "Winning GPO" that actually configured the computer with the particular setting.

Planning FSMO Roles in Active Directory

Planning FSMO Roles in Active Directory

 

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.
Domain Naming	Unless you are going to run DCPROMO, then you will not miss this FSMO role.
RID	Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you're building hundreds of users or computer object per week.
PDC Emulator	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 not be able to change or troubleshoot group policies and password changes will become a problem.
Infrastructure	Group memberships may be incomplete. If you 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.