Debugging FRS is feared territory for many administrators. It has logs that are unintelligible without tools, and even if you can read them, you still don't really understand the complexities of FRS. A couple of years ago, Microsoft felt our pain and provided some powerful FRS diagnostic tools that I will cover in the next few issues. In this issue, we'll discuss the FRSDiag tool and specifically the Propagation File feature to test inbound/outbound replication on all the DCs for a general health check.
One of my favorite tricks to see who's FRS-replicating with whom is to create a simple text file in %systemroot%\SYSVOL\SYSVOL\mydomain.com. I name the text file after the name of the DC on which it was created, such as DC1.txt. I do this on all DCs -- or at least the suspect ones. Then I wait for replication to take place, and see which files end up on which DCs.
If I have three DCs in the domain (and they are all FRS-healthy), then after replication, every DC should have a copy of DC1.txt, DC2.txt, and DC3.txt. If DC2 doesn't have a copy of DC1.txt, then we have an inbound replication problem from DC1 to DC2. If you don't want to wait for replication, you can go into Sites and Services and force replication. But in a large enterprise, that's a lot of clicking.
Microsoft has given us a very good FRS diagnostic tool called FRSDiag. You can download it from Microsoft's
Once you download it and install on a DC, you can fish the frsdiag.exe out of \Program Files\Windows Resource Kits\tools\FRSDiag, and put it on the desktop or somewhere else handy. Also, doing a Start-Run-FRSDIAG will open the folder with all the FRSDiag stuff in it.
Run the FRSDiag.exe, and you will be presented with a GUI like the one shown in Figure 1. In this example, we have specified DC1 and DC2 using the Browse button at the top and hit the OK button at the bottom. When the dust settles, an FRS health analysis for each of the specified servers will be given in the right side of the GUI. In Figure 1, we see a summary pane showing the two DCs and how many FRS-related errors it found. As you can see, with 159 errors on one DC, we have our work cut out for us! We will discuss options in more detail in future articles. But let's drop back and just see if FRS replication is working at all.
The Propagation File Tracer
Using my trick of creating the text file on all DCs in SYSVOL and watching it replicate is a good first cut at the problem. FRSDiag makes this easy with the "Propagation File Tracer." Go into the Options menu from the toolbar in the GUI and select the Propagation File Tracer. You'll see a dialog like that in Figure 2.
Here's how we use it: First we assume that we have three DCs in the domain (DC1, DC2 and DC3). Sorry, but we still have to create DC1.txt on DC1, DC2.txt on DC2 etc. in the %systemroot%\SYSVOL\SYSVOL\Corp.net directory on each DC. This could be scripted, or you can use the Ultrasound tool, but that's another article. Besides, Ultrasound requires a SQL database, so it's a bit more complicated to set up.
Having the DC*.txt files created, we configure the Propagation File Tracer tool as shown in Figure 2 with the following points:
In the Propagation File Path, replace the default file name of propagation_file.txt with DC*.txt. Note that it is preceded by the domain name, in this case Corp.net\DC*.txt. We do this to tell the tool to propagate any file in the Sysvol\Sysvol\Corp.net directory to the other DCs, thus the use of the wildcard.
Once you enter a file name with a wildcard, the Expected Number of hits becomes active. This number is equal to the number of DCs you have (three in this case). We don't care about the rest because we aren't searching subdirectories, and we have excluded the Pre-install and Pre-existing directories because we don't need them either.
- Click OK. The right pane of the main GUI reports the progress of the action for each DC you selected in the main window.
When the action is complete, you will again see the summary tab on the right along with a tab for each DC as shown in Figure 3. In the summary tab here, we see no errors on the two DCs.
Clicking on the Corp-DC1 tab as shown in Figure 4, we can see that it sees DC1.txt and DC2.txt. The bottom section of that tab confirms no errors. We see the same on the DC1 tab. Note that this saved us not only from having to force replication on all the connections but also from having to log on to each machine and look in the SYSVOL directory for the DC*.txt files.
So now we know that DC1 and DC2 are replicating with each other, inbound and outbound. Now at least we know FRS replication is successful, and we can look at the initial FRSDiag results for more details on those 159 errors.
One disadvantage about the Propagation File Tracer is that you have to create new files for the next test. That is, if I want to run this test again a week from now, I'll have to create new files to test. Again, this can be done with the Ultrasound tool or a simple script. All DCs have a SYSVOL share -- take advantage of that to create the files (and delete them when finished to prevent a bunch of junk in SYSVOL).
FRSDiag has some other features we will explore next month. Stay tuned!
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions
Engineering. He authored Windows
2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant
This was first published in December 2005