In Figure 1, we see the initial layout of FRSDiag. Note that I have left the default configuration settings (almost everything is enabled), but selected the radio button for Browse in the Target Servers area at the top of the user interface. It is important to note that the servers shown in this field, next to the Browse button, is the list of servers that any given FRSDiag operation will take place on.
In this case, rather than typing in my DCs (SYSVOL replicas), I hit the Browse button and it has returned the list shown in Figure 1. Here I have moved three DCs to the right column but left the KPARKHURST4 DC in the left column, as I know that DC is no longer in service. After configuring the list of servers you want, hit the OK button.
Back at the main FRSDiag screen, hit the green GO button at the bottom of the UI. This will initiate a scan of all the DCs in the list and report any errors encountered. As you can see in Figure 2, a warning was received while checking for connectivity, indicating that Kparkhurst4 could not be contacted. I selected the "Yes" button to continue. After the connectivity test was complete, a report is generated at the right of the main FRSDiag window.
Note that there are four tabs -- the summary tab and one tab for each server tested. In the summary tab shown in Figure 3, we see that all three servers reported errors.
In Figure 4, I have clicked on the Qamericas-DC39 tab to see what errors were encountered. In the top part of the tab, we see a list of tests that were processed. If you are interested in watching the progress of the tests, you can click on any server tab while the connectivity tests are running and watch the test reporting take place in real time. In the bottom section of the tab, we see a listing of errors encountered. In examining those errors, they are reporting that replication is failing to Kparkhurst4. It turns out that all servers are complaining about Kparkhurst4. This indicates, that although this DC is no longer alive, its FRS objects still exist in the AD, so we should take an action item to go clean that up.
So, this is a quick, easy way to do a dynamic test of FRS replication on all DCs or any subset of DCs in the domain.
Gotcha: In a multiple domain environment, if you log in to say the Americas domain with an account from another domain, FRSDiag will produce a list of DCs from the domain that your account is in. You must log in to the server running FRSDiag with an account from the domain you want to monitor. It follows that you can monitor all domains from one server by logging in with an account for each domain individually.
Besides a general connectivity test, we have some other options. These options are exposed in the Tools menu on the FRSDiag main toolbar, shown in Figure 5. These options will be discussed in the following paragraphs.
BuildGUID2Name for Target Server(s)
This option simply generates a list of the servers in your target server list along with their corresponding GUIDs in a simple text file as shown in Figure 6. This is handy in deciphering events that reference servers by their GUID.
Force Replication on Target Server(s)
This option will force replication between the servers in your target server list. Figure 7 shows the results of our replication test. Note that we have fixed the problem with Kparkhurst4 server so replication to all servers is successful.
Set Debug Logging Settings on Target Server(s)
This option exposes the dialog shown in Figure 8 and permits the administrator to adjust the debug logging for FRSDiag events. Note that you can get detailed information on what these settings mean in KB 221112 as noted in the dialog.
Propagation File Tracer
This tool allows us to create a file in the SYSVOL directory and test replication to all other target servers -- testing inbound and outbound replication. My TechTarget article in December discussed this option in detail, so refer to that article for more information.
All in all, FRSDiag, SONAR, Ultrasound and the Ultrasound Help file are very powerful tools when it comes to diagnosing FRS errors. I highly recommend that you download and get familiar with them -- they will prove valuable not only in debugging your FRS environment but in monitoring it as well.
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 February 2006