Troubleshooting Tips: Get to Know FRS
Healthy FRS means healthy Group Policy.
- By Roberta Bragg
It can take a huge investment of time to get an approved security
policy in place, so you'll want to use the technology controls provided
by Group Policy to distribute and apply them across each domain.
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/
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/
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.
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.