Vitaliy Leschenko’s blog
Виталий Лещенко

Windows Server for beginners. Part 17: What are FSMO roles?

All parts of the series “Windows Server for beginners”

In part 10 the directory was multi-master: any controller accepts any change, and conflicts are resolved by version and time. For users and groups that works. But there are operations where a conflict is unacceptable in principle: two controllers that simultaneously gave two new users the same RID would create two accounts with one SID, and no version with a timestamp would fix that. For such operations the directory has a single owner — the controller that alone has the right to perform them. There are five such operations, they are called FSMO (Flexible Single Master Operations), and their owners are operations masters.

"Flexible" because a role isn't tied to a server: it can be handed to any controller, and that is the second half of this part.

Five roles

Two roles are per forest, three are per domain. A forest with one domain has five of them; a forest with three domains has eleven. The first controller of the forest receives all five during Install-ADDSForest (part 4), and the first controller of each new domain receives the three domain roles.

Role Scope What it does Where the owner is stored
Schema Master forest schema changes fSMORoleOwner of CN=Schema,CN=Configuration,…
Domain Naming Master forest adding and removing domains and application partitions fSMORoleOwner of CN=Partitions,CN=Configuration,…
PDC Emulator domain time, passwords, lockouts, Group Policy fSMORoleOwner of the domain root DC=corp,DC=example,DC=com
RID Master domain issuing pools of relative identifiers, moving objects to another domain fSMORoleOwner of CN=RID Manager$,CN=System,…
Infrastructure Master domain updating references to objects in other domains fSMORoleOwner of CN=Infrastructure,…

The fSMORoleOwner attribute holds the DN of the owner's NTDS Settings object — the very object that makes a server a controller in the eyes of the others (part 4). It replicates like any attribute, and every controller knows the owner of every role.

Schema Master. Only on it can the schema be changed: adding a class or an attribute, making an attribute defunct. The Exchange installer, adprep /forestprep before the first controller of a new version, Update-LapsADSchema from part 15 — all of them find the owner and write to it. While it's unavailable, the schema can't be extended; nothing else in the forest notices. Only a member of Schema Admins can extend the schema; by default the group has one member — the Administrator of the forest root domain.

Domain Naming Master. Adding a domain to the forest, removing a domain, creating and removing an application partition, adding a replica of it to a controller (for example, when a DNS server enlists in DomainDnsZones) — all go through it. Unavailable — you can't add a domain or a partition. Nothing else is affected. In Windows 2000 this controller had to be a global catalog; since Windows Server 2003 it doesn't.

PDC Emulator. The busiest role, and the only one whose absence users will notice. The name comes from the Primary Domain Controller of NT domains: in Windows 2000 this role pretended to be the PDC for old BDCs and clients, the name stuck, and the duties piled up:

  • time source for the domain — the top of the hierarchy from part 12;
  • passwords: a password change on any controller replicates to the PDC preferentially, and a controller where password verification failed asks the PDC before giving a final refusal (part 10);
  • lockouts: failed sign-ins from all controllers are forwarded to the PDC, and account lockout is processed there; the badPwdCount counter isn't replicated, each controller has its own, and the complete one is on the PDC;
  • Group Policy: the GPMC console and the policy editor work with the PDC by default, so that two administrators don't edit one policy on different controllers;
  • SDProp: the process that protects administrative accounts through AdminSDHolder (part 5) runs every 60 minutes precisely on the PDC;
  • legacy applications and some tools that need a "primary" controller to write to go to it.

Unavailable — time in the domain has no top (event 129 on domain members, part 12), a new password doesn't work on every controller until replication, lockouts don't converge in one place, GPMC reports that the PDC is unavailable and offers to pick another controller. The domain lives, but worse, and within a few hours people start noticing.

RID Master. An object's SID is the domain SID plus a RID (part 3), and the RID must be unique across the whole domain, even though objects are created on any controller. The solution: the RID Master gives each controller a pool — 500 identifiers by default — and the controller spends its pool without asking anyone. When less than a threshold remains in the pool, the controller asks for the next one in advance. A new controller without a pool won't start working as a controller: before advertising itself to clients, it obtains its first pool. One more duty of the RID Master is moving an object to another domain of the forest. Unavailable — controllers keep creating objects from their pools, and the first one whose pool runs out stops creating users, computers and groups with the error "The directory service was unable to allocate a relative identifier.". In a domain that creates ten accounts a day this will happen in months; in a domain where a script creates thousands, in hours.

The pools are visible in the directory. The domain's overall remainder is the rIDAvailablePool attribute of the CN=RID Manager$ object:

PS C:\> $pool = (Get-ADObject 'CN=RID Manager$,CN=System,DC=corp,DC=example,DC=com' -Properties rIDAvailablePool).rIDAvailablePool
PS C:\> [PSCustomObject]@{ NextRid = $pool -band 0xFFFFFFFFL; MaxRid = $pool -shr 32 }

NextRid     MaxRid
-------     ------
   8100 1073741823

rIDAvailablePool is a 64-bit number: the low 32 bits are the first RID not yet issued, the high ones the upper limit, 2³⁰ − 1 = 1073741823 (since Windows Server 2012 it can be raised to 2³¹ − 1, more on that below). The mask is written as 0xFFFFFFFFL: without the L suffix PowerShell reads 0xFFFFFFFF as an Int32 with the value −1, and -band returns the whole number. Everything below NextRid has already been handed out in pools; RIDs below 1000 belong to built-in accounts and groups (500 is Administrator, 512 is Domain Admins) and don't go into pools.

Each controller's pool is stored in a CN=RID Set object under its computer account (the rIDSetReferences attribute points to it). The current pool is rIDPreviousAllocationPool, the next free RID in it is rIDNextRID, and neither attribute replicates: each controller holds only its own values, so they have to be read on the controller itself, with -Server:

PS C:\> Get-ADDomainController -Filter * | Sort-Object Name | ForEach-Object {
    $ridSet = Get-ADObject "CN=RID Set,$($_.ComputerObjectDN)" -Server $_.HostName -Properties rIDPreviousAllocationPool, rIDNextRID
    [PSCustomObject]@{ DC = $_.Name; PoolStart = $ridSet.rIDPreviousAllocationPool -band 0xFFFFFFFFL; PoolEnd = $ridSet.rIDPreviousAllocationPool -shr 32; NextRid = $ridSet.rIDNextRID }
}

DC  PoolStart PoolEnd NextRid
--  --------- ------- -------
DC1      6100    6599    6213
DC2      5600    6099    5658
DC3      7100    7599    7150
DC4      7600    8099    7606

Without -Server the module reads all four objects on one controller, and for the three other controllers NextRid comes out empty or zero. The pools are 500 each, and each controller has spent between 6 and 113 identifiers of its own. A controller obtains its next pool in advance and keeps it in rIDAllocationPool — this attribute of the same object does replicate; while there's no standby pool, it equals rIDPreviousAllocationPool. dcdiag /test:ridmanager checks the same and reports when the controller can't reach the RID Master — the output is in "Looking with our own eyes".

Infrastructure Master. A group in the corp domain has a user from the eu.corp domain as a member. The corp controllers keep a reference to it — a phantom, an object with a DN, GUID and SID but no other attributes — and if the user in eu.corp is renamed or moved, the phantom goes stale. The Infrastructure Master periodically compares phantoms with the global catalog and updates them. Hence the well-known rule: the Infrastructure Master must not be a global catalog unless all controllers of the domain are global catalogs. A GC has no phantoms (it holds partial copies of all domains), it has nothing to check, and it does nothing. A single-domain forest has no phantoms at all; in a domain where all controllers are GCs (and that is the norm today) every GC updates the references itself. And in a forest with the Active Directory Recycle Bin enabled (part 20) every controller updates its own references to objects in other domains, and the role has no work left. Microsoft still advises keeping the owner alive, otherwise monitoring tools will report errors.

The role has a twin in every application partition: CN=Infrastructure,DC=DomainDnsZones,… and CN=Infrastructure,DC=ForestDnsZones,… with their own fSMORoleOwner. They are relied on by the demotion of a controller, which hands the contents of the DNS partitions over to the owner, and by adprep /rodcprep, which grants permissions for RODCs. They aren't among the five roles, and neither Move-ADDirectoryServerOperationMasterRole nor ntdsutil moves them: in the example domain all five roles once moved from dc2 to dc1, while the twins stayed on dc2 (output below). If such an owner is removed from the domain forcibly, fSMORoleOwner points to a deleted NTDS Settings object (\0ADEL: shows in the DN), and then the demotion of another controller stops with the error "…unable to determine the ownership of floating single-master operation roles", and adprep /rodcprep reports "Adprep could not contact a replica for partition DC=DomainDnsZones,…". It's fixed by writing the attribute directly — in "Looking with our own eyes".

Who owns the roles

There are several ways, and all of them show the same:

PS C:\> netdom query fsmo
Schema master               dc1.corp.example.com
Domain naming master        dc1.corp.example.com
PDC                         dc1.corp.example.com
RID pool manager            dc1.corp.example.com
Infrastructure master       dc1.corp.example.com
The command completed successfully.

PS C:\> Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

SchemaMaster         DomainNamingMaster
------------         ------------------
dc1.corp.example.com dc1.corp.example.com

PS C:\> Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

PDCEmulator          RIDMaster            InfrastructureMaster
-----------          ---------            --------------------
dc1.corp.example.com dc1.corp.example.com dc1.corp.example.com

PS C:\> Get-ADDomainController -Filter * | Select-Object Name, OperationMasterRoles

Name OperationMasterRoles
---- --------------------
DC2  {}
DC1  {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster…}
DC3  {}
DC4  {}

PowerShell 7 truncates a collection in a table with an ellipsis; the full list is Select-Object -ExpandProperty OperationMasterRoles. The Locator finds the PDC owner too — that's how clients and the controllers themselves look for it:

PS C:\> Get-ADDomainController -Discover -Service PrimaryDC | Select-Object Name, HostName, Site

Name HostName               Site
---- --------               ----
DC1  {dc1.corp.example.com} Office

PS C:\> nltest /dsgetdc:corp.example.com /pdc | Select-String 'DC:|Flags:'

           DC: \\dc1.corp.example.com
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST DS_13

And dcdiag — it shows what a particular controller knows about the owners:

PS C:\> dcdiag /s:dc1 /test:knowsofroleholders /v | Select-String 'Role .* Owner|passed test KnowsOfRoleHolders'

         Role Schema Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Domain Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role PDC Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Rid Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Infrastructure Update Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         ......................... DC1 passed test KnowsOfRoleHolders

The test shows one controller's knowledge and doesn't compare it with the others; with the /e switch it goes through all controllers of the forest, and a disagreement between them about who the owner is signals replication problems. Domain Owner here is the Domain Naming Master, Infrastructure Update Owner is the Infrastructure Master.

Roles are stored in attributes, and they can be read directly — only this way are the Infrastructure twins visible:

PS C:\> 'CN=Schema,CN=Configuration', 'CN=Partitions,CN=Configuration', '', 'CN=RID Manager$,CN=System', 'CN=Infrastructure', 'CN=Infrastructure,DC=DomainDnsZones', 'CN=Infrastructure,DC=ForestDnsZones' | ForEach-Object {
    $dn = if ($_) { "$_,DC=corp,DC=example,DC=com" } else { 'DC=corp,DC=example,DC=com' }
    [PSCustomObject]@{ Object = $_; Owner = (Get-ADObject $dn -Properties fSMORoleOwner).fSMORoleOwner -replace '^CN=NTDS Settings,CN=([^,]+),.*', '$1' }
}

Object                              Owner
------                              -----
CN=Schema,CN=Configuration          DC1
CN=Partitions,CN=Configuration      DC1
                                    DC1
CN=RID Manager$,CN=System           DC1
CN=Infrastructure                   DC1
CN=Infrastructure,DC=DomainDnsZones DC2
CN=Infrastructure,DC=ForestDnsZones DC2

The empty line is the domain root, that is, the PDC. The twins in the DNS partitions belong to dc2 — this is the trace of the old role transfer mentioned above.

Transfer

A transfer is a regular operation with a live owner: the new owner asks the old one for the role, the old one writes the new one into fSMORoleOwner and hands it the role object (for the RID Master, together with the pool state), and the change then spreads by replication. It takes seconds, and users notice nothing.

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

The cmdlet asks for confirmation (-Confirm:$false turns the question off) and outputs nothing by default; the result is checked with the same netdom query fsmo. Roles are given by names or numbers from 0 to 4 (PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster), and -Identity is the controller the roles go to, by name or as an object from Get-ADDomainController: according to the documentation, the cmdlet fails with a fully qualified DNS name in -Identity. The command runs from any machine in the domain: the module contacts the controllers itself. The old way — ntdsutil roles connections "connect to server dc2" q "transfer pdc" q q, where connect to server names the new owner — does the same and still works. The other roles are called rid master, infrastructure master, naming master and schema master in ntdsutil.

The new owner doesn't start performing the role right away, but only after the first successful inbound replication of the partition that holds the role: that way it receives everything the old owner managed to change.

After a PDC transfer come the mandatory steps from part 12: an external time source on the new PDC, and the hierarchy back on the old one. And check that w32tm /query /source on the other controllers shows the new PDC after a few minutes.

What a transfer looks like in the directory — from the attribute's replication metadata:

PS C:\> repadmin /showobjmeta dc1 "DC=corp,DC=example,DC=com" | Select-String fSMORoleOwner

24632420                                Office\DC2  28914334 2025-01-13 00:55:12    9 fSMORoleOwner

The columns are the local USN on dc1, the controller where the change originated, its USN there, the time and the attribute version. The role now belongs to dc1, yet the last change of fSMORoleOwner originated on dc2: in a transfer the old owner writes the new one, and dc1 learned that it is the owner through replication. In a seizure, on the contrary, the change originates on the new owner.

Seizure

The owner is dead — a disk, a fire, a virtual machine that no longer exists — and won't come back. A transfer is impossible: there is no one to take the role from. What remains is a seizure: the new owner writes itself into fSMORoleOwner unilaterally.

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force -Confirm:$false

With -Force the cmdlet first tries to transfer the role and seizes it only if the transfer is impossible. The same ntdsutil with seize instead of transfer: seize pdc, seize rid master, seize naming master and so on.

When the RID Master is seized, the new owner moves the boundary of unissued RIDs forward — Move-ADDirectoryServerOperationMasterRole by 30,000, ntdsutil by 10,000 — so as not to issue a pool the old owner may have handed out but not replicated. Every unnecessary seizure burns these identifiers.

The rules of seizure that decide whether the domain stays whole:

Don't rush. A controller switched off for an hour is no reason to seize: the PDC can do without an owner for an hour, the other roles for weeks. You seize when you know the owner won't come back.

After a seizure the old owner doesn't come back to the network. When it starts, a role-holding controller first waits for inbound replication and, if it learns from it that someone else holds the role, gives the role up. But if there's no replication with it — it's cut off, and the isolated part of the network has its own clients — each of the two keeps considering the role its own. For the PDC and the Infrastructure Master that's not dangerous: they don't create persistent data. For the Schema Master it means two places where the schema can be changed, for the Domain Naming Master two sources of domains and partitions, for the RID Master two sources of pools, and sooner or later two controllers get the same pool and create objects with identical SIDs. So the order is: the seizure, then metadata cleanup of the old controller from the directory (part 19), then — if the hardware is alive — a reinstall from scratch or a forced demotion, not switching the old system back on and not restoring it from a backup.

Seize to a controller that was a direct replication partner of the old owner. It has the freshest copy of the role's partition: for the RID Master that means it knows which pools have already been issued; for the PDC, that it has the latest passwords.

The Directory Service log has two events about roles: 2091 — the role owner according to the directory is deleted or doesn't exist, and 2092 — the controller owns a role but doesn't consider it valid, because since the restart it hasn't yet replicated the role's partition with its partners. 2092 also appears after an ordinary reboot of the owner and goes away with the first successful replication; if the condition doesn't clear, there's no replication, and with it no role.

Placement

For a domain of three controllers the right answer is all roles on one controller, in the main site, with good connectivity, and this is written down somewhere an administrator will find it three years later. Spreading roles across controllers doesn't add fault tolerance: a role doesn't move to another controller by itself when its owner fails, it just becomes unavailable, and the more owners there are, the more places where that can happen.

What is still worth considering (Microsoft's recommendations):

  • The PDC — on the best hardware, in a reliable hub site that has other controllers of the same domain: it's contacted most often.
  • The RID Master — on the same controller as the PDC.
  • The Schema Master and the Domain Naming Master — on the PDC of the forest root domain.
  • The Infrastructure Master off a GC — only in a multi-domain forest without the Active Directory Recycle Bin where not all controllers are GCs. Otherwise anywhere.
  • A read-only controller holds no roles, and Move-ADDirectoryServerOperationMasterRole doesn't work with it.
  • The owner should have a direct replication partner in the same site — the candidate for a transfer or a seizure.
  • When a controller is removed from the domain (part 19), its roles are moved beforehand, by transfer, not by seizure.

Looking with our own eyes

What a controller and the Locator see when they look for the owners. The FsmoCheck test uses the Locator to find a global catalog, the PDC, time sources and a KDC — what a controller needs to work:

PS C:\> dcdiag /s:dc1 /test:fsmocheck /v | Select-String 'Name:|Flags:'

         GC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         PDC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         Time Server Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         Preferred Time Server Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         KDC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd

Preferred Time Server is the controller flagged as a reliable time source, that is, the PDC from part 12. This test doesn't check the roles themselves. The time hierarchy rests on the PDC — the other controllers take time from it:

PS C:\> Invoke-Command dc1, dc2, dc3, dc4 { [PSCustomObject]@{ Source = (w32tm /query /source).Trim() } } | Select-Object PSComputerName, Source

PSComputerName Source
-------------- ------
dc3            dc1.corp.example.com
dc2            dc1.corp.example.com
dc1            3.pool.ntp.org,0x8
dc4            dc1.corp.example.com

If the PDC is switched off, the controllers lose this source (event 129, part 12), the Locator stops finding the PDC, and Get-ADDomainController -Discover -Service PrimaryDC and nltest /pdc answer with an error. Users still sign in — all controllers issue Kerberos tickets — but a password just changed on one controller won't work on another until replication, and that one has no one to ask.

How the owner confirms its role after a reboot — event 2092 on dc1, logged a minute after the service started:

PS C:\> Invoke-Command dc1 { Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2092} -MaxEvents 1 } | Select-Object -ExpandProperty Message

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.

Operations which require contacting a FSMO operation master will fail until this condition is corrected.

FSMO Role: DC=corp,DC=example,DC=com

User Action:

1. Initial synchronization is the first early replications done by a system as it is starting. A failure to initially synchronize may explain why a FSMO role cannot be validated. This process is explained in KB article 305476.
2. This server has one or more replication partners, and replication is failing for all of these partners. Use the command repadmin /showrepl to display the replication errors.  Correct the error in question. For example there maybe problems with IP connectivity, DNS name resolution, or security authentication that are preventing successful replication.
3. In the rare event that all replication partners are expected to be offline (for example, because of maintenance or disaster recovery), you can force the role to be validated. This can be done by using NTDSUTIL.EXE to seize the role to the same server. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.

The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

FSMO Role is the DN of the role object; the domain root is the PDC role (for the Schema Master it would be CN=Schema,CN=Configuration,…). After it, 2092 didn't appear on dc1 again: the role was confirmed by the first successful replication. The third item is a way to confirm the role when there are no partners at all: seize it to the same controller.

What a controller that doesn't own the RID Master sees — dcdiag /test:ridmanager on dc2:

PS C:\> dcdiag /s:dc2 /test:ridmanager /v | Select-String 'rid'

      Starting test: RidManager
         * Available RID Pool for the Domain is 8100 to 1073741823
         * dc1.corp.example.com is the RID Master
         * DsBind with RID Master was successful
         * rIDAllocationPool is 5600 to 6099
         * rIDPreviousAllocationPool is 5600 to 6099
         * rIDNextRID: 5658
         ......................... DC2 passed test RidManager

DsBind with RID Master was successful means the controller reached the owner over RPC; there's no standby pool yet (rIDAllocationPool equals rIDPreviousAllocationPool), and 58 of the 500 identifiers of the current one have been used. If the RID Master is unavailable, dcdiag reports that it couldn't be reached, the controller works on what's left of its current pool, and once that is exhausted, event 16645 ("The maximum account identifier allocated to this domain controller has been assigned…") from the Directory-Services-SAM source goes to the System log, and object creation on that controller stops until it gets a new pool. New pools are requested and delivered with events 16647 and 16648, a failed request is 16651.

Since Windows Server 2012 the RID Master also watches the overall RID space: for every 10 % used it logs warning 16658, at 90 % it turns protection on — event 16657, and new pools stop being issued until an administrator lifts the block with the msDS-RIDPoolAllocationEnabled attribute; the 31st bit that doubles the space to 2³¹ − 1 is unlocked separately (event 16655). This has happened in domains where scripts created and deleted objects by the million and pools were burned by unnecessary seizures and restores.

And finally, the Infrastructure Master twins. If dc2, the owner of the twins in the example above, is removed from the domain forcibly, fSMORoleOwner in the DNS partitions will point to a deleted object. To make a live controller that hosts these partitions and was a direct partner of the old one the owner, write the attribute on that controller itself:

PS C:\> $owner = (Get-ADDomainController dc1).NTDSSettingsObjectDN
PS C:\> Set-ADObject 'CN=Infrastructure,DC=DomainDnsZones,DC=corp,DC=example,DC=com' -Server dc1 -Replace @{ fSMORoleOwner = $owner }
PS C:\> Set-ADObject 'CN=Infrastructure,DC=ForestDnsZones,DC=corp,DC=example,DC=com' -Server dc1 -Replace @{ fSMORoleOwner = $owner }

An NTDS Settings object with \0ADEL in its name is deleted, a tombstone from part 5; the application partition role was left pointing to it, and the five regular roles don't touch these partitions. Writing fSMORoleOwner directly is the method Microsoft describes too (its fixfsmo.vbs script does exactly this), and it also shows that a role is just an attribute.

Sources

We have learned to find the owners, transfer and seize roles, and we know what breaks without each of them. But in most cases when "the domain doesn't work", the problem isn't the roles but replication, DNS or time, and the symptoms look alike. The next part is about telling one from another.

Next — part 18: troubleshooting. The order of checks from dcdiag to repadmin and the logs; nltest and netlogon.log; typical causes and their symptoms: time, DNS, the secure channel; lingering objects and how to clean them up; USN rollback — a controller rolled back to a snapshot and what the directory does when it detects it; the tombstone lifetime and a controller that hasn't replicated for half a year.

Only registered users can leave a comment.

Sign in or register to leave a comment.

© 2006-2026 Vitaliy Leschenko