Moving and Seizing FSMO Roles Via PowerShell

In Active directory forest, there are five FSMO roles that are assigned to one or more domain controllers. Two of these FSMO roles are forest wide and it can only be seen at Forest level. Three of the FSMO roles are domain wide.

Schema Master FSMO Role

Responsible for performing updates to the directory schema. Schema Master Role can process updates to the directory schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. There is only one schema master per directory.

Domain Naming Master FSMO Role

The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory. Domain Name Master DC is can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories.

RID Master FSMO Role

The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.

When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.

Each Windows DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. There is one RID master per domain in a directory.

PDC Emulator FSMO Role

The PDC emulator is necessary to synchronize time in an enterprise. Windows includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows domain, the PDC emulator role holder retains the following functions:

Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.

Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.

Account lockout is processed on the PDC emulator. Any lockout notification is sent to PDC immediately

Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package do not perform directory writes (such as password changes) preferentially at the DC that has advertised itself as the PDC; they use any DC for the domain.

Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.

If a logon authentication fails at a given DC in a domain due to a bad password, the DC will forward the authentication request to the PDC emulator to validate the request against the most current password. If the PDC reports an invalid password to the DC, the DC will send back a bad password failure message to the user.

All domain controllers which receives an incorrect authentication request will poll the PDC Emulator as a “second opinion” before rejecting the user. (PDC always knows the most recently modified passwords)

Account lockout is processed on the PDC emulator. Any account lockout is immediately sent as a notification to the PDC Emulator.

Infrastructure FSMO Role

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference.

NOTE: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server(GC). If the Infrastructure Master runs on a Global Catalog 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 Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log.

If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

 

Moving and Seizing FSMO roles:

Before exploring with PowerShell make sure you understand the difference in between moving the FSMO roles compared to Seizing them. Moving, both DC’s involved are alive and willingly to give up and accept the new role. Changes to. DIT database replicated among the domain controllers. Seizing involves the current FSMO role owner is no longer available and its role forcibly moved to another available DC. When you move forcibly FSMO roles (-Force) you cannot bring the DC back online as it would create issues.

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole SchemaMaster

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole DomainNamingMaster

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole PDCEmulator

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole RIDMaster

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole InfrastructureMaster

Moving All FSMO Roles , is much easier

PDC Emulator – 0

RID Master – 1

Infrastructure Master – 2

Schema Master – 3

Domain Naming Master – 4

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRoles 0,1,2,3,4

Seizing FSMO Roles:

Once last time, be very cautious when using –Force (Seizing) option

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole PDCEmulator -Force

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole RIDMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole InfrastructureMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole SchemaMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole DomainNamingMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 0

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 1

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 2

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 3

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 4

Move-ADDirectoryServerOperationMasterRole -Identity DC2 –OperationMasterRole 5

Oz Casey, Dedeal (MVP North America)
MCITP (EMA), MCITP (SA)
Security+, Project +, Server +
http://smtp25.blogspot.com/ (Blog)
http://telnet25.wordpress.com/ (Blog)
https://twitter.com/Message_Talk (Twitter)