SEIZING FSMO ROLES

By -
How can I forcibly transfer (seize) some or all of the FSMO Roles from one DC to another?




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 RoleLoss implications
SchemaThe 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 NamingUnless you are going to run DCPROMO, then you will not miss this FSMO role.
RIDChances 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 EmulatorWill 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.
InfrastructureGroup 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 RoleRestrictions
SchemaOriginal must be reinstalled
Domain Naming
RID
PDC EmulatorCan transfer back to original
Infrastructure
Another consideration before performing the seize operation is the administrator's group membership, as this table lists:
FSMO RoleAdministrator must be a member of
SchemaSchema Admins
Domain NamingEnterprise Admins
RIDDomain Admins
PDC Emulator
Infrastructure
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.

Comments

Post a Comment

Popular posts from this blog

Boot configuration Data Store --BCDEdit /set

By -
The  BCDEdit /set  command sets a boot entry option value in the Windows boot configuration data store (BCD). Use the  BCDEdit /set  command to configure specific boot entry elements, such as kernel debugger settings, data execution protection (DEP) and processor address extension (PAE) options, and to load alternate hardware abstraction layer (HAL) and kernel files. You can use these boot entry options when you are testing and debugging your driver for Windows Vista, Windows 7, and later versions of Windows. bcdedit /set [{ID}] datatype value Parameters [ { ID }] The  { ID }  is the GUID that is associated with the boot entry. If you do not specify an  { ID } , the command modifies the current operating system boot entry. If a boot entry is specified, the GUID associated with the boot entry must be enclosed in braces  { } . To view the GUID identifiers for all of the active boot entries, use the  bcdedit /enum  command. datatype value The fol
Read more

ADSI Edit

By -
Image
ADSI Edit (adsiedit.msc) Updated: March 19, 2010 Applies To: Windows SBS 2008, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2 Active Directory® Service Interfaces Editor (ADSI Edit) is a Lightweight Directory Access Protocol (LDAP) editor that you can use to manage objects and attributes in Active Directory. ADSI Edit (adsiedit.msc) provides a view of every object and attribute in an Active Directory forest. You can use ADSI Edit to query, view, and edit attributes that are not exposed through other Active Directory Microsoft Management Console (MMC) snap-ins: Active Directory Users and Computers, Active Directory Sites and Services, Active Directory Domains and Trusts, and Active Directory Schema. This topic includes the following sections: Installing ADSI Edit Using ADSI Edit
Read more

Userenv logging (User Environment logging)

By -
When you enable userenv logging, you can perform debug logging of the user profile and the system policy processes. Userenv log files also contain information about the status of each Group Policy extension, such as Application Deployment, Security, and Folder Redirection. Userenv log files reveal what is occurring in the background as a user logs on   Userenv.log file located in the %SystemRoot%\Debug\UserMode folder Userenv log files contains information about the following: Group Policy settings that are not processed or not applied as expected Folder redirection that does not occur Profile or registry hive load, unload, or deletion failures Logon script, or script not applied as expected Default behaviors occurring because a slow link was detected Roaming profile issues Slow logon issues Whether a given GPO is accessible, and if not, why access was denied. The name of the domain controller that is accessing SYSVOL. The Userenv log has a maximum size of 1 megabyt
Read more