FSMOROLES

Determining FSMO Role Holders




How can I determine who are the current FSMO Roles holders in my domain/forest?

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. The transferring method is described in the Transferring FSMO Roles article, while seizing the roles from a non-operational DC to a different DC is described in the Seizing FSMO Roles article.

In order to better understand your AD infrastructure and to know the added value that each DC might possess, an AD administrator must have the exact knowledge of which one of the existing DCs is holding a FSMO role, and what role it holds. With that knowledge in hand, the administrator can make better arrangements in case of a scheduled shut-down of any given DC, and better prepare him or herself in case of a non-scheduled cease of operation from one of the DCs.

How to find out which DC is holding which FSMO role? Well, one can accomplish this task by many means. This article will list a few of the available methods.

Method #1: Know the default settings

The FSMO roles were assigned to one or more DCs during the DCPROMO process. The following table summarizes the FSMO default locations:

FSMO Role Number of DCs holding this role Original DC holding the FSMO role

Schema One per forest The first DC in the first domain in the forest (i.e. the Forest Root Domain)

Domain Naming One per forest

RID One per domain The first DC in a domain (any domain, including the Forest Root Domain, any Tree Root Domain, or any Child Domain)

PDC Emulator One per domain

Infrastructure One per domain

Method #2: Use the GUI

The FSMO role holders can be easily found by use of some of the AD snap-ins. Use this table to see which tool can be used for what FSMO role:

FSMO Role Which snap-in should I use?

Schema Schema snap-in

Domain Naming AD Domains and Trusts snap-in

RID AD Users and Computers snap-in

PDC Emulator

Infrastructure

Finding the RID Master, PDC Emulator, and Infrastructure Masters via GUI

To find out who currently holds 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. Right-click the Active Directory Users and Computers icon again and press Operation Masters.



















1. When you're done click Close.

Finding the Domain Naming Master via GUI

To find out who currently holds the Domain Naming Master Role:

1. Open the Active Directory Domains and Trusts snap-in from the Administrative Tools folder.

2. Right-click the Active Directory Domains and Trusts icon again and press Operation Masters.













1. When you're done click Close.

Finding the Schema Master via GUI

To find out who currently holds the Schema Master Role:

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

regsvr32 schmmgmt.dll

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

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

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

4. Press Add. Select Active Directory Schema.

5. Press Add and press Close. Press OK.

6. Click the Active Directory Schema icon. After it loads right-click it and press Operation Masters.

















1. Press the Close button.

Method #3: Use the Ntdsutil command

The FSMO role holders can be easily found by use of 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.

C:\WINDOWS>ntdsutil

ntdsutil:

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

1. Type connections, and then press ENTER.

fsmo maintenance: connections

server connections:

1. Type connect to server , where 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:

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

server connections: q

fsmo maintenance:

1. At the FSMO maintenance: prompt, type Select operation target, and then press ENTER again.

fsmo maintenance: Select operation target

select operation target:

1. At the select operation target: prompt, type List roles for connected server, and then press ENTER again.

select operation target: List roles for connected server

Server "server100" knows about 5 roles

Schema - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C

onfiguration,DC=dpetri,DC=net

Domain - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C

onfiguration,DC=dpetri,DC=net

PDC - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Conf

iguration,DC=dpetri,DC=net

RID - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Conf

iguration,DC=dpetri,DC=net

Infrastructure - CN=NTDS Settings,CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Si

tes,CN=Configuration,DC=dpetri,DC=net

select operation target:

1. Type q 3 times to exit the Ntdsutil prompt.

Note: You can download THIS nice batch file that will do all this for you (1kb).

Another Note: Microsoft has a nice tool called Dumpfsmos.cmd, found in the Windows 2000 Resource Kit (and can be downloaded here: Download Free Windows 2000 Resource Kit Tools). This tool is basically a one-click Ntdsutil script that performs the same operation described above.

Method #4: Use the Netdom command

The FSMO role holders can be easily found by use of the Netdom command.

Netdom.exe is a part of the Windows 2000/XP/2003 Support Tools. You must either download it separately (from here Download Free Windows 2000 Resource Kit Tools) or by obtaining the correct Support Tools pack for your operating system. The Support Tools pack can be found in the \Support\Tools folder on your installation CD (or you can Download Windows 2000 SP4 Support Tools, Download Windows XP SP1 Deploy Tools).

1. On any domain controller, click Start, click Run, type CMD in the Open box, and then click OK.

2. In the Command Prompt window, type netdom query /domain: fsmo (where is the name of YOUR domain).

C:\WINDOWS>netdom query /domain:dpetri fsmo

Schema owner server100.dpetri.net



Domain role owner server100.dpetri.net



PDC role server100.dpetri.net



RID pool manager server100.dpetri.net



Infrastructure owner server100.dpetri.net



The command completed successfully.

Close the CMD window.

Note: You can download THIS nice batch file that will do all this for you (1kb).

Method #5: Use the Replmon tool

The FSMO role holders can be easily found by use of the Netdom command.

Just like Netdom, Replmon.exe is a part of the Windows 2000/XP/2003 Support Tools. Replmon can be used for a wide verity of tasks, mostly with those that are related with AD replication. But Replmon can also provide valuable information about the AD, about any DC, and also about other objects and settings, such as GPOs and FSMO roles. Install the package before attempting to use the tool.

1. On any domain controller, click Start, click Run, type REPLMON in the Open box, and then click OK.

2. Right-click Monitored servers and select Add Monitored Server









In the Add Server to Monitor window, select the Search the Directory for the server to add. Make sure your AD domain name is listed in the drop-down list.





In the site list select your site, expand it, and click to select the server you want to query. Click Finish.

UNLOCK Users in Windows 2003 AD

Add Unlock User Option to Active Directory Users and Computers


by Daniel Petri - January 7, 2009

How can I add an "unlock user account" option to the Active Directory Users and Computers context menu?

Windows 2008 Active Directory 70-640 Training!

Have you seen the Microsoft Active Directory 70-640 Training video by Train Signal? I highly recommend this course, as you will learn much more than you will from any book. It includes new iPod/MP3 versions of the course (when you are on the go) and Transcender practice tests to help you prepare for certification. The instructors, Ed and Coach, do an amazing job not only preparing you to get Microsoft Certified but also showing you what tasks you need to perform on real Windows 2008 Servers, in the real world!



-Daniel Petri, Petri IT Knowledge Base

Watch Free Demo Video Here

One of the daily tasks of a network administrator is to monitor user accounts, logo activities, password changes and account options, such as disabling and enabling user accounts.

When an administrator wants to disable a user account he or she has quite a few options. One method is do disable or enable the account via a specific script, a DSMOD USER command (in Windows Server 2003) or through the built-in Active Directory Users and Computers snap-in (also known as DSA.MSC). One more task regularly performed by administrators might be to unlock user accounts after they have forgotten their passwords and were locked out by the system. Enabling user accounts is different from unlocking these accounts, because the action needed to disable the account is performed by the administrator, whereas the action needed to lockout the account is done by the users themselves, and unless caused by a security penetration or hack attempt, usually indicates that the user has attempted to logon to the system with a bad password, more times than specified in the Account Lockout Threshold parameter in the GPO of the system.

To disable a user account you can just right-click on the required account and simply select Disable Account.



If the account was already disabled, then an option to enable it appears when you right-click that user account in DSA.MSC.



However, if that administrator wanted to just unlock the user account, not enable it, then he or she would need to select the user account in DSA.MSC, right-click it and choose Properties, then go to the Account tab, and un-check the Account is Locked Out option. This process is considerably longer than the one required when enabling a disabled account.



To make the life of the administrator easier (thus leaving him or her more time to play online games) we can add a small addition to the Active Directory configuration partition, and then have the ability to unlock a user account by simply right-clicking on that account (as you would do when enabling or disabling it).

Writing the script(s)

First we need to write one or two small VBS scripts (I thank Iftach for the insight). The first script will be used as a context menu option on any user account object, and the second script will do a scan on any given OU (Organizational Unit) in the AD and if it finds any locked-out user accounts - it will enable them.

I guess both scripts (especially the second one) could be done in a better way, and if any of you have a good suggestion please send it over .

Script #1:

Const E_ADS_PROPERTY_NOT_FOUND = -2147463155



Set wshArguments = WScript.Arguments

Set objUser = GetObject(wshArguments(0))



If IsLockedOut(objUser) Then

objUser.Put "lockouttime","0"

objUser.SetInfo

MsgBox "The user has been unlocked - " & objUser.sAMAccountName

Else

MsgBox "The user account is not locked - " & objUser.sAMAccountName

End If



Function IsLockedOut(objUser)

on Error resume next

Set objLockout = objUser.get("lockouttime")



if Err.Number = E_ADS_PROPERTY_NOT_FOUND then

IsLockedOut = False

Exit Function

End If

On Error GoTo 0



if objLockout.lowpart = 0 And objLockout.highpart = 0 Then

IsLockedOut = False

Else

IsLockedOut = True

End If

End Function

Save the script as UNLOCK_USER.VBS.

Script #2:

Const E_ADS_PROPERTY_NOT_FOUND = -2147463155



strSummary=""

Set wshArguments = WScript.Arguments

Set objOU = GetObject(wshArguments(0))



For Each objIADs in objOU

If LCase(objIADs.Class) = "user" Then

If IsLockedOut(objIADs) Then

objIADs.Put "lockouttime","0"

objIADs.SetInfo

strSummary=strSummary & objIADs.Get("samaccountname") & vbNewLine

End If

End If

Next



If strSummary="" Then

MsgBox "No locked users found!"

Else

MsgBox "The following users have been unlocked:" & vbNewLine _

& "-------------------------------------------------" & vbNewLine & strSummary

End If



Function IsLockedOut(objUser)

on Error resume next

Set objLockout = objUser.get("lockouttime")



if Err.Number = E_ADS_PROPERTY_NOT_FOUND then

IsLockedOut = False

Exit Function

End If

On Error GoTo 0



if objLockout.lowpart = 0 And objLockout.highpart = 0 Then

IsLockedOut = False

Else

IsLockedOut = True

End If

End Function

Save the script as UNLOCK_USERS_IN_OU.VBS.

Place both scripts in a share on one of your DCs, preferably in the NETLOGON share, thus replicating them to all of your DCs. Note that this change is a forest wide change, so each and every DC in the forest should have access to these scripts.

Adding the unlock option to the context menu

You now need to add the context menu options to the user account and the OU objects in AD. To do so you need the following:

1. ADSIEdit.MSC - found in the Windows 2000/2003 Support Tools (located on the installation CD)

2. Enterprise Admin permissions

User account context menu:

1. After installing the Support Tools, open ADSIEdit.MSC and navigate to the following path:

CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=dpetri,DC=net

Lamer note: Change the path to fit your own domain name...

1. Right-click on the user-Display object and select Properties.

2. The first attribute in the list of attributes for the object should be adminContextMenu. Double-click it or click on the Edit button.



1. In the Sting Editor window of the adminContextMenu attribute, add the following line:

4,&Unlock User,\\zeus\netlogon\unlock_user.vbs

Lamer note: Change the UNC path to fit your own path...





1. When done, click Add to add the line, then click Ok.

OU context menu:

1. In ADSIEdit.MSC navigate to the following path:

CN=organizationalUnit-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=dpetri,DC=net

Lamer note: Change the path to fit your own domain name...

1. Right-click on the organizationalUnit-Display object and select Properties.

2. The first attribute in the list of attributes for the object should be adminContextMenu. Double-click it or click on the Edit button.

3. In the Sting Editor window of the adminContextMenu attribute, add the following line:

3,&Unlock Users in OU,\\zeus\netlogon\unlock_users_in_ou.vbs

Lamer note: Again, change the UNC path to fit your own path...



1. When done, click Add to add the line, then click Ok.

2. Close ADSIEdit.MSC.

Testing

In order to test the context menu additions you'll need to create some test users and cause them to become locked-out. I've created a test OU and in it I've created 4 users.



Next, to cause the users to become locked-out, I wrote a small script that goes like this:

net use \\127.0.0.1 /user:kuku wrongpassword

net use \\127.0.0.1 /user:kuku wrongpassword

net use \\127.0.0.1 /user:kuku wrongpassword

net use \\127.0.0.1 /user:kuku wrongpassword

net use \\127.0.0.1 /user:kuku wrongpassword

net use \\127.0.0.1 /user:kuku wrongpassword



net use \\127.0.0.1 /user:lulu wrongpassword

net use \\127.0.0.1 /user:lulu wrongpassword

net use \\127.0.0.1 /user:lulu wrongpassword

net use \\127.0.0.1 /user:lulu wrongpassword

net use \\127.0.0.1 /user:lulu wrongpassword

net use \\127.0.0.1 /user:lulu wrongpassword

Lamer note: You must first enable the locking out of user accounts in the Default Domain GPO.

Close DSA.MSC if it was open, and re open it. Find the locked out users in the test OU. You can also use the following LDAP search string and create a saved search (also see LDAP Search Samples for Windows Server 2003 and Exchange 2000/2003 and Saved Queries in Windows Server 2003 AD Users & Computers)

(&(&(&(objectCategory=person)(objectClass=user)(lockoutTime:1.2.840.113556.1.4.804:=4294967295))))

Right-click the locked-out user account and select the new context menu - Unlock User.



Notice how the user is now unlocked.

In order to test the OU context menu, right-click the OU in which the locked-out users are located, and select the new context menu - Unlock Users in OU.



Notice how a prompt is displayed telling you which users have been unlocked in the process.