Comments : 8

Finding FSMO Roles in Active Directory using NTDSUtil

Posted by Vishal Vasu | Posted on 04-09-2009

Category : Active Directory

Tags: ,

First things first: FSMO means Flexible Single Master Operation and it is used within Active Directory to control, monitor and manage configuration updates. Without going in to more details about how FSMO works, let’s move on to understanding the Five (5) FSMO roles:

Schema Master: It controls all the updates and modifications that relate to schema of the Active Directory. It is the duty of the Schema Master to ensure that the latest schema has been replicated across all Domain Controllers in the directory. The role is forest-wide and there can be only one Schema Master in a forest.

Domain Naming Master: It controls the addition and deletion of domains in the forest. The role is once again forest-wide and there can be only one Domain Naming Master in a forest.

RID Master: Stands for Relative ID and is responsible for processing RID requests from all Domain Controllers in a particular domain. For example, if we create a user in Active Directory, a unique Security Identifier (SID) is created which identifies it in the domain. Along with this SID a Relative ID (RID) that is unique to the SID is also generated from a pool that is allocated. The main role of RID Master is to ensure that each DC has got enough RID pool and if not then process the request for the pool from the unallocated RID pool. The role is Domain specific and there can be only one Domain Controller handling this role.

Infrastructure Master: 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. The role is Domain specific and there can be only one Domain Controller handling this role.

PDC Emulator: It seems to be a backward compatible role that has been handed over as a legacy from Windows NT 4.0 and is mainly used for syncing time in the Enterprise. The W32Time service that we see in the Services MMC has a very important role to play: synchronize time across the enterprise to that Kerberos Authentication works smoothly. After all, password changes, authentication, account lockout, etc. all depends on this. The role is Domain specific and there can be only one Domain Controller handling this role.

So why does an administrator need to know which Domain Controller is holding which role? Well, normally there is always a single machine that carries all the five FSMO roles, but there can be scenarios where an administrator would have moved one or more FSMO roles. To know why, read this KB article from Microsoft. With a better understanding of which server holds which role, the administrator can plan better for disaster recovery or scheduled maintenance. There are many ways to find out which DC holds which role, but here is one that uses NTDSUtil – a command line tool.

A word of caution before we proceed: If you do not know what you are doing and have no idea about how Active Directory works or even worse – what Active Directory is – please refrain from doing this practically. Doing this incorrectly or messing with this command can cause your Active Directory to crash and lose functionality.

Step #1: On any Domain Controller, click Start. In the Run command type CMD and hit Enter. You will be taken to the good old command prompt window (DOS were the days). Type ntdsutil and hit Enter.

Step #2: You shall see the screen with ntdsutil: prompt. Since we want to find out the roles, type roles and hit Enter. Notice that the prompt now changes to show fsmo maintenance:. Now is a good time to get more HELP on the list of available commands.

Step #3: On the fsmo maintenance: prompt, type ? and hit Enter. Right-click in the Window, mark and copy them. Paste the clipboard in to Notepad for easy reference.

Step #4: Type connection and press Enter. This will show a prompt with server connections:. Type connect to server <servername> (replace <servername with actual name> and press Enter.

Step #5: Once we are connected to the Domain Controller, type q to return back to the fsmo maintenance prompt. Now type, select operation target and then press Enter. Notice that the prompt changes to select operation target:.

Step #6: At the select operation target prompt, type list roles for connected server and press Enter. This would list all the FSMO roles for that Domain Controller. To get out of the ntdsutil, type q until you are back to the good old DOS prompt.

For those who are looking at ready solution rather than going through this process, check out DUMPFSMOS.CMD in the Resource Kit (Windows 2000/2003). This tool is a one-click utility that does the same trick.

Comments : 6

Active Directory Health Monitoring

Posted by Vishal Vasu | Posted on 09-04-2009

Category : Active Directory

Tags: ,

Companies that have implemented Microsoft’s Active Directory need to ensure that the Active Directory is configured and operating properly. If there are issues found and not resolved, it eventually leads the components to fail or stop working and finally causing problems with Windows networking environment. This post highlights some of the FREE tools that can be used by administrators to check and verify their Active Directory health. I normally run these tests every quarter in highly changing environments since lot of updates take place.

The free tools that I mention come with Microsoft’s Support Tool Kit and while writing this post I’ve ran the tools on Windows 2003 R2 Server. Download the Support Tool Kit. Once downloaded, install the Support Tools on the server.

Now before we move on to the health monitoring tools, it is always a good idea to make a list of all the Domain Controllers in your organization along with their IP address and trust relationships if any. Assuming that you have completed this step, let’s move on to using the tools.

Since many of these tests generate logs, let’s start by creating a log folder to store the diagnostic information. I’m going to use C:\AD-Health-Logs on my server.

Let’s start by verifying the health of the Domain. For this we are going to use NSLOOKUP which is a command line tool for testing and troubleshooting DNS. We all know that DNS is the heart of Active Directory and so that’s the first thing that we will check.

For replication to happen seamlessly between multiple Domain Controllers, name resolution should work fine. Each DC should be able to resolve the _msdcs record for other DC. Open the DNS mmc and look for the _msdcs record.

Once you have the _msdcs record for the DC object, we can use NSLOOKUP to check the name resolution. Open Command Prompt and type:

NSLOOKUP <GUID._msdcs.DnsForestName> replace the GUID string in <> brackets with your actual GUID.

If the NSLOOKUP resolves the correct IP address of the replication partner than DNS is working fine. Do check that the DNS server returned in the NSLOOKUP query is returning the correct records for the replication partner.

Since DNS is working fine now, let’s move on to checking the Replication functions and topology. To verify this, we are going to use REPLMON. This tool is included in the Windows Support Tools kit and offers a GUI based interface to check a low-level status of AD replication, force replication or even monitor the status of replication. You should find REPLMON utility from the Support Tools group under Administrative Tools.

Once the GUI is opened, right-click on the Monitored Servers and click on Add Monitored Server.

 

This will invoke the Add Monitored Server wizard. Here either you can search the AD for the server that you want to monitor or you can add it explicitly by name. Since I’ve already documented my list of Domain Controllers and their corresponding IP address before I started this exercise, I’ll add the server explicitly by name. Once the server is added, click on Action, navigate to Server and choose Generate Status Report.

When prompted for the location where we should store the log file, choose the folder that you created earlier. In my case, I’m saving this to C:\AD-Health-Logs. Choose all the reporting options on the next screen and click OK.  Once the report has been written to the Log file, you’ll see a message that the Report is complete. You can now navigate to the folder where you saved the log and open it in Notepad, Word, etc. to read the contents. The report basically gives you lot of in-depth in to the replication status and topology. Play with the other options available in the REPLMON tool like Show Domain Controllers in Domain, Show Global Catalog Servers in Enterprise, etc.

My REPLMON log files did not show any problems with replication and so we will now move forward to perform the DC health check. Open Command Prompt once again and type the following command:

DCDIAG /s: <ServerName> /v /c > C:\AD-Health_logs\<servername-DCDIAG-DD-MM-YY.log>

Replace ServerName with the actual DC name and the log path with the actual values. Using the /v switch will provide us a verbose result with extended information while the /c switch will provide us with a comprehensive report by running all tests. If you get any errors you can also use the DCDIAG /fix option here to perform some soft fixes. Run this for all the DC’s in your organization by replacing the ServerName and the log file prefix. You can run this from the same machine and does not require you to log individually to machines that you are checking.

Moving ahead, we will check the network connectivity health using the NETDIAG tool. The NETDIAG tool helps in isolating network connectivity problems by performing a series of tests. Open the Command Prompt once again and type NETDIAG /v > C:\AD-Health_logs\<servername-NETDIAG-DD-MM-YY.log>.

 

Again replace the appropriate variables with the actual values and wait for the diagnostics to complete. Open the log file once the process has completed and remediate any errors that you get. Note that you may see errors related to WINS in this. If you are not using WINS in your organization these can be safely ignored.

That’s it to the basic checks for monitoring the health of your Active Directory. I’ve not covered NetDom in this series since most of the functionality can be accessed from the Active Directory mmc’s that are available in the Administrative Tools.