Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
The Ultrasound tool is excellent for monitoring your FRS servers, it is however rarely something that we (Microsoft PSS or CTS) use as part of troubleshooting FRS issues that come in.
The reason for that is simple; we usually get involved at the point where a problem already exists and beginning the case by setting up and configuring Ultrasound properly to resolve an existing problem is simply not effective as we have simpler reactive methods of gathering the logs that we need.
I.e. Ultrasound is primarily useful as a proactive monitoring tool and alerting you to when problems arise, it is less useful for telling you why the problem occurred. Our weapon of choice for reactively troubleshooting Sysvol replication problems is usually FRSDiag (or DFSRDiag) as both allow you to gather logs from all your affected servers within a short amount of time.
Documentation for setting up and using Ultrasound for monitoring is sparse but the best resource on setting it up and configuring is probably in the W2k3 Branch Office Guide in Chapter 6, "Using Ultrasound".
If you have MOM available, there's also a special management pack for FRS that builds on the data that Ultrasound gathers.
Further details:Windows Server 2003 Active Directory Branch Office Guide (See chapter 6 - Using Ultrasound)http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=enMicrosoft Windows File Replication Service 2000/2003 Management Pack for Operations Manager 2007http://www.microsoft.com/downloads/details.aspx?FamilyID=6F5F8E56-6A35-4909-BB8F-968EE95A8F17&displaylang=en
Ultrasound FAQhttp://download.microsoft.com/download/5/3/6/5360c938-eaec-4468-814b-855d228c4290/Ultrasound%20FAQ.docUltrasound version 1.0.4080.0 is now availablehttp://blogs.technet.com/filecab/archive/2008/09/10/ultrasound-version-1-0-4080-0-is-now-available.aspxMonitoring your Branch Office environmenthttp://technet.microsoft.com/en-us/library/dd736504(WS.10).aspxMonitoring Active Directory with MOMhttp://technet.microsoft.com/en-us/magazine/2007.02.monitoring.aspxSetting Up Reporting in the Windows File Replication Service Management Pack http://technet.microsoft.com/en-us/library/cc179746.aspxFile Replication Service (FRS) troubleshooting toolshttp://blogs.technet.com/btrst4/archive/2004/06/15/156320.aspxFRS Tools and settingshttp://technet.microsoft.com/en-us/library/cc786122(WS.10).aspx
Microsoft Windows DFS Replication Service Management Pack for Microsoft Operations Manager 2005http://www.microsoft.com/downloads/details.aspx?FamilyId=651E7C4A-484B-4AA2-9FBF-F3538075B9E8&displaylang=enFRSDiag toolhttp://www.microsoft.com/downloads/details.aspx?FamilyID=43cb658e-8553-4de7-811a-562563eb5ebf&DisplayLang=en
Question from Cortez:
I recently began to recive 13567 FRS warnings on my PDC. I can find little about this on the Internet, but the event tells that setting "HKLM\System\CCS\Services\NTFRS\Parameters\Supress Identical Updates" to 0 will force identical updates to replicate.
Is this recomended, or do you have any other ideas?
I can see in the FRS debug log that some logon scripts are marked with the prefix :T:
The 13567 is a whistle-blower event so the focus shouldn't be on making it go away but rather on finding the underlying cause - the real problem is something making multiple updates in a short amount of time to files that are being replicated.
The classic culprits for such things are file-level filter drivers making changes to alternate streams in the files (to indicate they've been scanned or processed).
We're typically look at Antivirus, Security or Management software running on either the clients accessing the login scripts or the DC's.