Security Watch

Troubleshooting Tips: Get to Know FRS

Healthy FRS means healthy Group Policy.

• By Roberta Bragg
• 04/26/2004

If you've made a commitment to centralize security management using Group Policy, you've used the policy decision-making time well. You've got your OU structure designed to support applying security to each type of computer and user based on the role they play within your organization. You've placed the desired computers and users in the appropriate OU. When the security policy is ready, it's quick work to configure the GPOs, making security settings in each GPO meet both best practices and security policy compliance, then linking those GPOs to respective OUs. In a matter of minutes, the hardening of thousands of computers will begin and your job is done. Now you can sit back, assured that you've secured the domain.

Wrong. Creating a security policy for the domain and implementing it is only half the battle. You've got to verify that it's working. What should you do if some desktop security settings are correct while others aren't?

Your first instinct is correct. If the normal time for Active Directory replication has passed, or you've used "gpoupdate" to kick-start it, check the GPO and the OU membership. If you haven't configured things properly, there's no way they're going to work right. If, however, things look right but still don't work right, what should you do? You'll have to troubleshoot Group Policy.

Troubleshooting Group Policy is never fun because so many things can go wrong: DNS, replication, misconfiguration, even simple things like basic network connectivity and the ability to log on to a domain controller can be the problem. Checking basic network issues, DNS and configuration should probably be your first steps; what if they're OK? Replication problems can be much harder to troubleshoot because two types of replication can play a role -- AD replication and the File Replication Service (FRS).

Many have invested significant time in understanding AD. If you're not familiar with using Replmon and Dcdiag (two Windows support tools) to check AD replication, learn how. Another support tool, TopChk, can verify that NTDS connection objects are present and the replication schedule is on. It can also help identify a number of other basic issues such as missing NTDS setting objects (missing setting objects can result in a lack of setting references and, hence, a failure of FRS), missing inbound connections (there has to be at least one), and potential self-reference connection objects (this type of isolationist behavior is never a good sign). All this replication topology troubleshooting is important for two reasons. First, information about which GPO links to which OU gets replicated with AD. Second, FRS uses the same topology and schedule to replicate the SYSVOL folder contents. If you haven't invested some time learning the ins and outs of what can go awry with AD replication, start now. If you're competent in this area, follow up and get busy building your knowledge of FRS.

I know admins who think FRS is primarily for replicating netlogon scripts and keeping Distributed File System (DFS) shares synchronized. FRS also plays a role in the distribution of Group Policy. Its role is to replicate any files in the SYSVOL folder on DCs, and this is precisely where Group Policy files are stored. Changes to GPOs are replicated using the same replication topology as AD but using FRS. If there's a problem with FRS, there's a problem with Group Policy. If you want centralized security management via GPOs, learn how to check FRS health and troubleshoot it.

Fortunately, there are now a number of free tools and documents to help. Some are provided in the Windows Support Tools installation from the product disks, and others are downloadable Resource Kit tools. To get started, browse on over to the Windows Server System Technology Center document "Monitoring and Troubleshooting the File Replication Service," at http://www.microsoft.com/windowsserver2003/technologies/fileandprint/
file/dfs/tshootfrs.mspx.

Here you'll find links to four server tools: Ultrasound, Ntfrsutl, FRSDiag and Sonar. Download the tools, but before you use them, read the FRS Monitoring Help file for its comprehensive overview of what FRS does, best practices guide and troubleshooting guide that details how to use event logs and tools. The troubleshooting guide is an especially comprehensive gem! It starts with instructions to make sure the latest version of FRS is installed, (Service Pack 3 for Windows 2000 Server and the pre-SP 1 release of ntfrs.exe for Windows Server 2003), continues with a list of Knowledge Base articles for verifying FRS dependencies (DNS, AD Replication, and Network Connectivity), then begins to narrow FRS issues, and provides links to more information on using event logs and tools.

Browsing through these documents and examining the tools will make you eager, I hope, for the big picture. Solid backgrounders on how FRS works, and general tool information, can be found in the FRS Technical Reference at http://www.microsoft.com/resources/documentation/WindowsServ/2003/
all/techref/en-us/Default.asp. This technical reference home page leads to Technologies Collections, Storage Collection, File Services Technologies and the FRS Technical Reference. Those of you without immediate Group Policy issues may want to start here. Whatever your approach FRS, add some knowledge and troubleshooting skills for FRS to your bag of security tips and tricks. Someday you'll be glad you did.