C H A P T E R 1

Microsoft® Windows® 2000 Server uses the File Replication service (FRS) to replicate system policies and logon scripts stored in System Volume (SYSVOL). Each domain controller keeps a copy of SYSVOL for network clients to access. FRS can also replicate data for Distributed file system (Dfs), synchronizing the content of each member in a replica set defined by Dfs. FRS can copy and maintain shared files and folders on multiple servers simultaneously. When changes occur, content is synchronized immediately within sites and by schedule between sites.

INTRODUCTION TO FRS 4

Replicating SYSVOL 5

Replicating Dfs Replicas 6

HOW FRS WORKS 7

Detailed Operation 10

FRS Tables 13

FRS Startup 14

UPGRADING LMREPL TO FRS 15

LMRepl Process 15

FRS Process 16

Maintaining a Mixed Environment 17

CUSTOMIZING FRS 18

Setting File and Folder Filters 18

Scheduling Replication 19On SYSVOL 19

File Replication Service

On Dfs Replicas 20

Tuning Recommendations 22Setting up the Dfs Topology 22Distributing Disk Usage 22Disabling Logging 23Maintaining Throughput 23Adjusting the Size of the Staging Directory 23Using FRS with Remote Storage 24

MONITORING PERFORMANCE 24

RESTORING REPLICATED FILES 25

Nonauthoritative Restore Process 26

Authoritative Restore Process 27

Restoring Files on a Domain Controller 27

Restoring Files on a Member Server 28

TROUBLESHOOTING FRS 29

FRS Logs 30Log Settings 31Analyzing Log Files 33

Ntfrsutl Tool 34

Introduction to FRSFile Replication service is a multithreaded replication engine that replaces the LMRepl service that is used in Microsoft® Windows NT®. Multithreaded means that several processes can run at the same time to handle multiple tasks. This allows FRS to replicate different files between different computers simultaneously.FRS does not guarantee the order in which files arrive. Files begin replication in sequential order based on when the files are closed, but file size and link speed determine the order of completion. Because FRS replicates only whole files, the entire file is replicated even if you change only a single byte in the file.FRS expands on the functionality provided by LMRepl with the following enhancements: Multimaster replication of files and folders for allowing updates to occur independently on any

server in the domain. Site-aware clients (Microsoft® Windows® 2000, Microsoft® Windows NT® version 4.0,

Microsoft® Windows® 95, and Microsoft® Windows 98 with the Active Directory add-on) for locating nearby servers hosting SYSVOL and Dfs content.

Configurable schedules for replicating Dfs and SYSVOL content between sites. Automatic replication of folder and file attributes including ACLs.

Like LMRepl, FRS is automatically installed on Windows 2000 domain controllers and configured to start automatically. For member servers, the service start value is initially set to manual.

There is no administrative console for FRS. SYSVOL replication occurs automatically just like directory replication. Replication of Dfs files and folders is controlled by the Dfs administrative snap-in.

Although Active Directory replication and File Replication service are separate mechanisms, they are conceptually similar. Therefore, it can be useful to read about directory replication when you are learning about FRS. For information about directory replication, see “Active Directory Replication” in this book.

Key TermsFRS terms that you need to know before reading further are:

Replication. The process of copying data, from one computer to another, that converges to an identical data set over time. Replication enhances availability and file sharing by duplicating shared files.

Replica. A member of a replica set that contains a copy of a shared folder or file.

Replica set. Two or more copies of a shared folder that participate in replication. Each copy must be located on a different computer.

Initial master. First member in a replica set that is the starting point for automatic replication. This means the files and folders in that replica are replicated to other replicas for the first replication cycle.

Replicating SYSVOLThe Windows 2000 System Volume, or SYSVOL, is built during the creation of a domain controller by Dcpromo.exe. It is a tree of folders containing files that need to be available and synchronized between domain controllers in a domain or forest, including: SYSVOL share. NETLOGON share. Windows 95, Windows 98, and Windows NT 4.0 system policies. Windows 2000 Group Policy settings. User logon and logoff scripts.

For example, the default folder structure contains the following folders for policies or scripts used by network clients:\\Winnt\Sysvol\Sysvol\domain_name\Policies\\Winnt\Sysvol\Sysvol\domain_name\ScriptsWhen you add, remove, or modify the contents of the Sysvol folder on a domain controller, those changes are replicated to the Sysvol folders on all other domain controllers in the domain.FRS uses the same connection objects as the Active Directory™ directory service when it replicates SYSVOL content. Therefore, it uses the same schedule as Active Directory

Note

for intersite replication. However, unlike Active Directory, replicated content between sites is not compressed.

A handy method for checking SYSVOL replication is to create a file named after the originating computer such as \\Winnt\Sysvol\Sysvol\domain_name\file_name_equals_server_name. Then observe which other domain controllers receive the new file. Updates to servers in remote sites are governed by a schedule.

Replicating Dfs ReplicasUnlike SYSVOL replication, which is implicitly enabled, replication for Dfs replicas must be explicitly enabled by using the Dfs administrative console. Only domain-based Dfs can use FRS; stand-alone Dfs does not support automatic file replication. Remember that FRS is installed only on Windows 2000 servers and that the service starts automatically only on domain controllers. To start FRS on a member server, use Control Panel. Double-click Administrative Tools, double-click Services, and then use the menu options in the Services console.

To enable or disable FRS replication1. Open the Dfs administrative console.2. In the left pane, right-click the Dfs link for the replica set, and then click Replication Policy.3. In the Replication Policy dialog box, click Enable and Disable as needed.

If replication is being enabled for the first time, the files and folders on the first server enabled (the initial master) become authoritative. This means those files and folders are duplicated to other replicas for the first replication cycle before multimaster replication takes effect.

Replication is not allowed, that is, the shared folder appears as N/A, under the following conditions: A shared folder on a computer where FRS is not installed. A shared folder that is not on the version of NTFS used in Windows 2000. A shared folder that uses a cluster name in its path name. For more information about using file

replication with Cluster service, see “Distributed File System” in this book. A shared folder on a computer that does not belong to a Windows 2000 domain. A shared folder on a computer whose domain is inaccessible by the user who is currently logged

on.

In addition, the following events do not trigger replication: Changes to a file or folder’s last access time. Changes to a file or folder’s archive bit.

For a complete description of Dfs, see “Distributed File System” in this book.How FRS WorksFRS provides redundancy for the content of designated NTFS shares between Windows 2000 servers. The servers can be interconnected in any topology such as a ring or a star configuration. With an appropriate topology and sufficient network support, hundreds of computers can replicate the same set of files or folders. Conversely, one computer can be a member of multiple replica sets.

Tip

FRS also provides redundancy for SYSVOL and Dfs distribution by way of multiple distribution paths between the replicas in a replica set. If one replica is down, data flows using a different route. Dampening logic prevents a data file from being sent more than once to any particular replica.Multimaster replication allows any domain controller or member server to propagate changes to replicated files and folders on any other domain controller or member server. There are no primary/secondary or master/slave relationships. When a replicated file is changed and closed, FRS submits that change to other members in the replica set. Those members decide whether to accept or reject the change according to certain criteria.For example, suppose a replica set is composed of Computer A and Computer B. If File X on Computer A is updated and then closed, FRS notifies Computer B of the change. If the event time associated with Computer A is more than 30 minutes later than the event time

for Computer B, the change is accepted immediately and Computer B is updated. If the event time associated with File X on Computer A is more than 30 minutes earlier than the event time for File X on Computer B, the change is rejected.An event time is associated with any change to a file. It denotes when the file was closed after being changed or was last replicated. The default event time window is 30 minutes.

If the event time of the change in the file on Computer A is within 30 minutes of the event time for the version of the file on Computer B, FRS checks the version numbers of the file. If the version number of the file on Computer A is greater than that of the file on Computer B, the change is accepted and the file is updated. If the version number of the file on Computer A is less than that of the file on Computer B, the change is rejected.The version number is a numerical value FRS uses to track changes occurring to a replicated file. It is assigned by a counting mechanism similar to the update sequence number (USN) used by Active Directory. When a changed file is closed, its version number increments by one.

If the version numbers for the files are equal, the event time is checked again, this time without the 30-minute window. In other words, if the event time associated with the file on Computer A is later than the event time for the file on Computer B, the change is accepted and Computer B is updated. If the event time associated with the file on Computer A is earlier than the event time for the file on Computer B, the change is rejected.

FRS uses a “last writer wins” algorithm, which means that the last update to a file or folder in a replica set becomes authoritative for replication, regardless of the document version number or file size. It does not merge changes; rather, the most recent version of a particular file overwrites all older versions. This makes FRS well suited to replicate files that are updated infrequently, such as product specifications, software distribution points, and Web content.Files that contain information that is updated more frequently must accommodate two scenarios: concurrent users and replication latency. User A and User B open the same 100-page document on different replicas. User A adds 100

pages and saves the document first; user B deletes 80 pages and then saves the document. The 20-page document that was saved last becomes the authoritative file.FRS cannot deny file sharing or enforce file locking between two users who are writing to the same file on two different replicas.

A user makes a change on a replicated Dfs share. Assume that the replication schedule for Dfs connection objects in Active Directory specifies that replication take place only at night. This means that updates originating on replicas in one site during the day are not available on replicas in other sites until the replication window opens in the evening.

FRS uses Active Directory to manage configuration information so you can administer computers containing replicated data offline. This means you can add or remove replicas, change connections between replicas, or modify replication schedules without needing to communicate with the affected computer.

The Dfs administrative console does not support full remote administration; that is, the affected computer must be online.

To provide secure communications, authenticated remote procedure call (RPC) with Kerberos encryption is used over TCP/IP as the protocol between members for replication. NTFS file permissions are also replicated. Files that are locked by their owners are not replicated until they are unlocked.FRS works only with Windows 2000 because it relies on the NTFS change journal to provide a persistent (that is, logged) record of files that have changed on a member computer. Files are replicated only after they have been modified and closed. As a result, FRS does not lose track of a changed file even if the system shuts down abruptly.

Detailed OperationFRS monitors the NTFS change journal for changes to its shares, applies a filter to exclude changes to nonreplicated files, places changes in a staging directory until they can be processed, and sends change notifications so that replication partners can pick up their changes. When the partners retrieve the staging file, it is considered replicated and deleted from the staging directory.A list of partners is specified for each replica set. For SYSVOL, it is created automatically by the KCC (Knowledge Consistency Checker), which runs periodically on Windows 2000 domain controllers, to optimize and adjust the topology for failed computers or lost connections. When FRS is used to replicate Dfs shares, KCC is not involved. You must define replica sets by using the Dfs snap-in.The fundamental objects in a replica set are computers and replication links. The replication links that connect computers are unidirectional. A change flows in the direction of the link between two partners. To replicate changes in both directions, a pair of links is necessary.Before taking a detailed look at FRS operation, it is necessary to clarify the terms inbound and outbound partners in a replica set. Assume that two computers, A and B, host a replica set and that replication is enabled. As shown in Figure 18.1, if a file has changed on Computer A and needs to replicate to Computer B, then Computer B is Computer A’s outbound partner and Computer A is Computer B’s inbound partner. If a change occurs on Computer B that needs to be replicated to Computer A, then a second link is needed. In this case, Computer B is the inbound partner for Computer A, and Computer A is the outbound partner for Computer B.

Figure 18.1 Inbound and Outbound Relationships

Figure 18.2 shows the detailed sequence of events that occurs when a file change introduced on Computer A replicates to Computer B.

Note

Figure 18.2 Detailed FRS Operation

1. When a file in a replica set changes and the user closes the file, NTFS makes an entry in the NTFS change journal.The NTFS change journal records changes to all files on the NTFS volume such as file creations, deletions, and modifications. The journal is limited in size, but it is persistent across restarts and crashes.

2. FRS monitors the NTFS change journal for changes that apply to the replicated shares. Only closed files are checked. File and folder filters are applied against changes in the folders of interest, notably domain-based Dfs and SYSVOL replica sets.

3. The aging cache, a three-second delay designed to catch additional changes to a file, expires. This prevents file replication when the file is undergoing rapid updates.

4. Computer A records the change as a change order in an inbound log. It also creates an entry in the ID table so that recovery can take place if a crash occurs.The inbound log contains change orders arriving from all inbound partners. The change orders are logged in the order that they arrive along with the file data. Each change order contains information about a change to a file or folder on a replica member, such as the name of the file or the time it was changed, that is used to construct a message about the change.

5. A copy of the changed file is constructed in a local staging directory.The staging directory is an area where modified files are stored temporarily prior to being propagated to other partners. A staging file is used by FRS to encapsulate the data and attributes associated with a replicated file (or directory) object. It ensures that the file data can be supplied to partners regardless of any file activity that might prevent access to the original file.

6. Computer A updates the outbound log.The outbound log contains change orders generated for a specified replica. The changes can originate locally or come from an inbound partner. These change orders are eventually sent to all outbound partners.

7. Computer A sends a change notification to Computer B.8. If it decides to accept the change order, Computer B asks for the modified file. Computer B

writes to its inbound and ID logs.9. Computer B copies the staging file to its staging directory. It then writes to its outbound log so

other outbound partners can pick up the change.The staging directory is an area where propagated files are stored temporarily prior to being installed locally on the partner. This is done so that users do not see a file locked for an extended period of time while FRS is moving the file over a slow or congested link. In addition, if the link fails in the middle of the transfer, users do not see a partial file.

10. The altered file is constructed in a preinstallation area and moved to its final location on Computer B.

FRS TablesFRS transactions are stored in a Microsoft Jet database that defaults to systemroot\\Ntfrs\Jet\Ntfrs.jdb. Each replica set hosted by a computer has a set of tables stored in the Ntfrs.jdb file. These five tables are: Connection table. Contains one record per link or inbound/outbound partner connection. Inbound log. Stores pending change orders to be processed. As entries are processed,

acknowledgments are sent to the inbound partners. Data stored in the inbound log includes change order globally unique identifier (GUID), file name, object ID, parent object ID, version number, and event time.

During a planned shutdown, all new change orders since the last update are written to the inbound log. If an unplanned shutdown or network interruption occurs, the inbound partner resends all the change orders in its outbound log for which acknowledgments have not been received.

Outbound log. Stores pending change orders to be sent to outbound partners. Change orders remain in the outbound log until all outbound partners receive and acknowledge the change. Data stored in the outbound log is the same as that stored in the inbound log. Also in the outbound log is the leading (next change) and trailing (last acknowledged) index for each partner.The outbound log or logs can become quite large, particularly when replicas are down, links between replicas are slow, replication hours are restricted, or a large number of changes occur. For example, suppose one of four replicas is down. Snapshots of the file image and log entries are maintained until this server becomes available. When the changes are finally sent, the inbound partner sends all changes in log file order.If the trailing location for a replica partner is overwritten, a complete synchronization must be completed for the replica. This involves the outbound partner sending its version vector — an array of numbers for each originator — with the changes it has received to the inbound partner. The inbound partner checks its ID table by using this state to determine what changes occurred afterward and sends them.

Version vector. Measures the up-to-dateness of a replica compared to another replica. Each replica member in a replica set is assigned a number. Version vector joins occur the first time an FRS context is replicated or when the outbound log wraps.

ID table. Lists all files in the replica set of which FRS is aware. Data stored in the ID table includes globally unique identifier (GUID), file name ID, parent file ID, file object ID, parent object ID, version number, and event time.

Changes are always logged in the Jet database for recovery purposes before any disk files are moved in case of a system failure.

FRS StartupWhen FRS starts up, either when the host computer or the service starts (by using net start ntfrs, for example), it first polls Active Directory for configuration changes. Then FRS determines the inbound and outbound partners for each replica set.FRS also polls Active Directory at regular intervals for configuration changes that affect its partner relationships. Events that reset the polling interval are: Adding a replica. Deleting a replica. Adding a connection. Deleting a connection. Changing a schedule. Changing a file or folder filter.

Upgrading LMRepl to FRSMicrosoft® Windows NT® Server version 4.0 and earlier provided a single-master file replication facility known as LAN Manager Replication (LMRepl). LMRepl was often used to replicate logon scripts and other database information to all domain controllers in the domain. FRS replaces LMRepl in Windows 2000 Server.

Windows 2000 Server does not support LMRepl in mixed or native mode, so if you have been using LMRepl, you need to develop a strategy for using FRS to provide the same functionality. If you used LMRepl to replicate logon scripts, you need to transition to using SYSVOL. If you used LMRepl for other purposes, investigate using Dfs for replication.

LMRepl ProcessLMRepl uses the concept of import directories and export directories. You configure LMRepl by selecting a server to host an export directory and a number of servers to host import directories. The servers hosting the directories do not need to be domain controllers; they can be ordinary member servers. Figure 18.3 illustrates the LMRepl process.

Figure 18.3 LMRepl Process

FRS ProcessFRS in Windows 2000 Server is automatically configured so that every domain controller has a replicated SYSVOL. Any change you make to a logon script stored in the SYSVOL of any domain controller is replicated in multimaster fashion to other domain controllers. Unlike LMRepl and the hosting of import and export directories, only domain controllers can host SYSVOL. Figure 18.4 illustrates the FRS process.

Figure 18.4 FRS Process

Maintaining a Mixed EnvironmentDuring an upgrade you can have a mixed environment of Windows NT 4.0 backup domain controllers and member servers operating with Windows 2000 domain controllers. However, because Windows 2000 Server does not support LMRepl, maintaining LMRepl services in a mixed environment can be an issue. To provide this support, you need to create a bridge between LMRepl and FRS so that both services can operate autonomously. Do this by selecting one Windows 2000 domain controller to copy the files that you want replicated to the Windows NT 4.0 export directory. The copying can be accomplished by a regularly scheduled script.

The term mixed environment is not to be confused with mixed mode, which refers to Windows NT 4.0 and Windows 2000 domain controllers existing within a domain. A mixed environment is a looser term that describes Windows NT 4.0 backup domain controllers (BDCs) and member servers operating with Windows 2000 domain controllers.

To maintain availability of LMRepl during an upgrade, make sure that the server hosting the export directory is upgraded only after all the other servers hosting import directories have been upgraded. If the server hosting the export directory is the primary domain controller (PDC), you should select a new server to host the export directory and then reconfigure LMRepl.

Note

Customizing FRSYou can customize what FRS replicates and when by specifying a filter that excludes certain types of files or folders and by scheduling replication between sites.

Setting File and Folder FiltersFile and folder filters are maintained for each FRS replica set including: SYSVOL Domain-based Dfs root shares Domain-based Dfs links

By default, the following files and folders are excluded from FRS replication: Encrypting File System (EFS)–encrypted files and folders that are computer specific File names starting with a tilde (~) character Files with .bak or .tmp extensions NTFS mount points All reparse points

Filters act as exclusion filters only for new files and folders added to a replica set. They have no effect on existing files in the replica set. For example, if you change the file filter from “*.tmp, *.bak” to “*.tmp, *.old,” FRS does not go through the replica set and exclude all files that match *.old. Nor does it go through the replica set and begin to replicate all files that match *.bak.After the filter change, new files that enter the replica set matching *.old are not replicated. New files entering the replica set matching *.bak are replicated. In addition, any preexisting file in the replica set that matched the old file filter (such as Test.bak, created when the old filter was in force) is not automatically replicated when the filter changed. You must explicitly modify such files before they begin replicating. Likewise, you must explicitly delete any preexisting files in the replica set that match *.old. Until that happens, changes to those files continue to replicate.These rules apply in the same manner to the directory exclusion filter. In addition, for directories, if a directory is excluded, all subdirectories and files under that directory are also excluded.The rationale for these rules is as follows. If you accidentally change a filter to exclude a file like *.doc, FRS does not go through and delete every Microsoft® Word file in the replica set. Similarly, if you unintentionally omit *.tmp from the filter, FRS does not go through each replica and begin replicating every temporary file it finds.Use the Active Directory Users and Computers console to modify a file or folder filter.

To change the file or folder filter1. Open Active Directory Users and Computers, click View, and then click Advanced Features.2. In the console tree, expand System, expand File Replication Service, and then expand DFS

Volumes.3. Expand the Dfs root and link that has the filter you want to change.4. Right-click the link, and then click Properties.5. On the Replica Set tab, enter your changes in the File Filter box, and then click OK.

Scheduling Replication

Schedules govern intersite replication between servers or domain controllers and also intrasite replication for Dfs replica sets. Intrasite replication for SYSVOL occurs automatically.

On SYSVOLSite-to-site replication for SYSVOL is determined by the schedule for its connection object in Active Directory. It is treated as a trigger schedule, which means that when the connection schedule enables replication at a specified time, all pending file changes that have accumulated on an inbound partner are now replicated to the outbound partner. This can take minutes or hours depending on how much file data needs to be replicated.Because trigger schedules are used with SYSVOL, its replication behavior is similar to that for Active Directory objects. Remember that replication of directory objects is completely separate from replication of SYSVOL files by FRS. As shown in Figure 18.5, the default interval for intersite replication of SYSVOL files is once per hour.

Figure 18.5 Default Replication Schedule for SYSVOL

To check the schedule on the connection object for SYSVOL1. Open the Sites and Services administrative console.2. In the console tree, expand Sites, and then expand the site of interest.3. Expand Servers, expand the server of interest, and then expand NTDS_Settings.3. Right-click the connection of interest, and then click Properties.4. Click Change Schedule to view the schedule for that connection.

On Dfs ReplicasA schedule for a replica set can be assigned to a connection object or to the replica set itself. Normally, a connection object is preferred because a schedule assigned to a connection object overrides a schedule assigned to a replica set. However, assigning a schedule to the replica set might be easier in certain circumstances. For example, if a replica set had a large number of replicas, say 100, it is a tedious process to configure all the connection objects.The schedule for the replication of a replica set is interpreted as on or off. For example, the schedule shown in Figure 18.6 enables replication between 5 A.M. and 8 A.M. FRS starts replicating to the outbound partners at 5 A.M. and stops replicating at 8 A.M. even if not done sending all the files. This allows you to allocate replication when network bandwidth is available. For example, you can schedule replication during nonpeak hours in case a user dumps a 1 gigabyte (GB) file into a replica set.

Figure 18.6 Replication Schedule for Dfs Replicas

To change the schedule on the connection object for a replica set1. Open Active Directory Users and Computers, click View, and then click Advanced Features.

2. In the console tree, expand System, expand File Replication Service, and then expand DFS Volumes.

3. Expand the Dfs root and link of interest.4. Right-click the link, and then click Properties.5. Click Change Schedule to view the schedule for that connection.

To change the schedule on the entire replica set1. Open Active Directory Users and Computers, click View, and then click Advanced Features.2. In the console tree, expand System, expand File Replication Service, and then expand DFS

Volumes.3. Continue expanding until you reach the replica set of interest.4. Click Change Schedule to view the schedule for that replica set.

Remember that if a schedule is assigned to a connection object within this replica set, it overrides the schedule assigned to the replica set for that connection.

Forcing Replication Between SitesThe only way to force replication by FRS is to enable its schedule (assuming that it is off). The Replicate Now button in the Active Directory Sites and Services console pertains to directory replication only.

Tuning RecommendationsUse the following guidelines to help you optimize the performance of FRS.

Setting up the Dfs TopologyThe size and shape of a replica set, that is, the depth and breadth of its tree, can affect performance significantly. For example, if the replica set is fully meshed, with each member connected to every other member, the propagation of change orders for replicating files can impose a heavy burden on the network. To reduce unnecessary traffic, delete connections you do not actually need.By default, Dfs creates a full-mesh topology. When you add a replica, Dfs creates a link between the new replica and every other member in the replica set and vice versa. To remove unwanted connections, use the Users and Computers administrative console. For guidelines on designing a Dfs topology, see “Distributed File System” in this book.

Distributing Disk UsageTo spread out disk traffic, locate the FRS logs on a separate disk from the staging directory, the working directory, and the replicas themselves. (The working directory is the Ntfrs.jdb file.) This is especially important when logging with a high severity level. In fact, putting each of these areas on a separate disk drive gives the best replication performance because it distributes disk input/output (I/O).To change the location where trace log files are stored, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and edit the value of the Debug Log File entry. Before this change becomes effective, you must stop and restart FRS.

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings that might degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Disabling LoggingIf debugging replication problems is not a priority, you can disable logging to reduce disk traffic. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and change the value of the Debug Disable entry to 1.

Maintaining ThroughputA slow outbound partner can cause the staging directory to fill up. To avoid an interruption to FRS replication because the staging directory is full, construct replica connections that have comparable bandwidth for all outbound partners. It is also a good idea to balance the bandwidth for inbound and outbound connections.

Adjusting the Size of the Staging DirectoryMake sure the staging directory for replicated shares is large enough. The staging space limit governs the maximum amount of disk space that FRS can use to hold staging files. When this limit is reached, inbound replication pauses until space can be recovered by replicating one or more staging files to all outbound partners.To adjust the size of the staging space, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and edit the value of the Staging Space Limit in KB entry.

Using FRS with Remote StorageA replica set can include files that are stored offline in a tape library managed by Remote Storage. However, if you decide to deploy FRS and Remote Storage, remember that the overhead from replicating offline files can be substantial. For example, suppose a replica set has two members: Computer A and Computer B. Computer A uses Remote Storage to hold its replicated files whereas Computer B keeps its replicated files online. If Computer A is the initial master of the replica set, all of its files must be extracted from remote storage and replicated to Computer B when the latter is added to the replica set.Frequent replication of data in the replicas can also be a burden for Computer A if the affected files must be retrieved from a tape. This is less of a concern when only a small subset of the replicated files, which are kept in disk storage on Computer A, are changed frequently by users.Monitoring PerformanceThe two performance objects associated with File Replication service are listed in Table 18.1. The counters for these objects are available for each replica set managed by FRS while the service is running.

Caution

Table 18.1 FRS Performance Objects

Object Description

FileReplicaConn Performance statistics for the Replicaconn object that defines replica connections to Dfs roots.

FileReplicaSet Performance statistics for the Replicaset object that defines a replica set.

Important FileReplicaSet counters that you can monitor to verify FRS performance are listed in Table 18.2.Table 18.2 Key FileReplicaSet Counters

Counter Description

Change Orders Received Number of change notifications received from inbound partners.

Change Orders Sent Number of change notifications sent out to outbound partners.

File Installed Number of replicated files installed locally.KB of Staging Space Free Amount of free space in the staging directory used by FRS

to temporarily store files before they are replicated. The default staging space is 660 megabytes (MB).(continued)

Table 18.2 Key FileReplicaSet Counters (continued)

Counter Description

KB of Staging Space In Use Amount of space in the staging directory currently in use. If the staging directory runs out of space, replication stops.

Packets Received Amount of data received locally. These packets can be change notifications, file data, or other command packets.

Packets Sent Similar to packets received.USN Records Accepted Number of records that are accepted for replication.

Replication is triggered by entries written to the NTFS change journal. FRS reads each file close record from the journal and determines whether to replicate the file.An accepted record generates a change order, which is then sent out. A high value on this counter (about one every five seconds) indicates a lot of replication traffic. This can cause replication latency.

You can also observe FRS activity using Event Viewer. Select File Replication service, and then filter events by time and date or by type of event such as information, warnings, or errors. Right-click the individual message, and then click Properties to display details about an event.Restoring Replicated FilesReplicated files and folders can be backed up like any other share as long as you are aware of how replicated data is restored, in case a restore becomes necessary. In fact, a backup copy of SYSVOL or a Dfs replica is a good idea in case disaster recovery must be carried out.

Backup does not distinguish what type of data (replicated or otherwise) is being backed up or restored. If FRS replicates the restored files after a restore, this can be good or bad depending whether the files contain the latest or most valid data.For example, when only one member in a replica set is lost, say, from the failure of a disk drive, restore its contents from a backup tape, and then let FRS restore the files that have changed since the backup tape was made. This minimizes network traffic by not restoring static files. This is called a nonauthoritative restore.On the other hand, if the entire replica set or every copy of SYSVOL has been corrupted, restore one replica from the backup tape, and then replicate the restored files and folders to the other members in the replica set. This is called an authoritative restore.

Backup does not back up the FRS database (that is, the tables in Ntfrs.jdb). If the database becomes corrupted or lost, the server reconstructs it by comparing the files in its replica with the files in another replica on a different computer.

Nonauthoritative Restore ProcessVersion numbers are not retained with a file when it gets backed up. However, if the file was backed up from a replica set, it has a file object ID saved along with the other file attributes. The file object ID guides the nonauthoritative restore process.Use a nonauthoritative restore to create a new replica member, which is the recommended course of action if an individual replica is lost. First, remove the failed member from the replica set. Then, restore the replicated share from the backup tape into what is to become the root directory for the new member. Next, add the member to the replica set, specifying the root path where the replicated share was just restored. Note that FRS has been running all this time, but because this member was removed from the replica set, none of the restored files has been replicated.When FRS notices that the configuration has changed, it begins its initialization sequence to add the member. The first step is to move all the files just restored from the new replica’s root directory to a temporary directory. Next, FRS joins with an inbound partner and requests information about every file in the replica share. The inbound partner supplies information such as the version number, file object ID, and so forth, for each file and folder. By using the file object ID, FRS locates the file or folder that was restored from tape and does a checksum-based comparison (using MD5) of the file contents with the corresponding checksum supplied by the inbound partner. If the checksums match, FRS places the file from tape into the replica share. Otherwise, FRS requests the file from the inbound partner. If the backup data is fairly current, few files are copied from the inbound partner.At the conclusion of the nonauthoritative restore process, the file content and the version information on the new member match the content on the inbound partner. In essence, the files supplied from the backup tape are used only if they have file object IDs and their content matches the content of the corresponding file held by the inbound partner. This is especially valuable if the two members are linked by a low-speed network connection.

Note

Authoritative Restore ProcessWith an authoritative restore process, the restored file and folders are given the newest version number. This means that the replicated share that was just restored is automatically replicated to other members in the replica set. Do an authoritative restore only if, for example, an entire replica set became corrupted.

Restoring Files on a Domain ControllerRestoration on a domain controller is FRS-aware. This means Backup recognizes that it is working with replicated data. Therefore, a nonauthoritative restore is always performed, because it is assumed that there is another replica in the domain with valid data.If you want to force an authoritative restore, in the Advanced Restore dialog box, select When restoring replicated data sets, mark the restored data as the primary data for all replicas. This ensures that the restored data is replicated to your other servers. If you do not choose this option, the data you are restoring cannot be replicated to other servers because in a nonauthoritative restore the version of the file currently residing on the other replica set members always takes precedence. This causes other servers to overwrite the restored data, thereby preventing you from restoring the data. Forcing an authoritative restore assigns the newest version number to the replicated data to guarantee its replication to other servers.Use the When restoring replicated data sets, mark the restored data as the primary data for all replicas switch if and only if this is the last member of the replica set. This switch is intended for disaster recovery cases when the whole replica set is lost. Setting a member as initial master when it has other members from which to synchronize can result in name collision.

To perform an authoritative restore of SYSVOL1. Restore the data from tape to an alternate location.2. Perform a nonauthoritative restore.3. After the SYSVOL share is published, copy the restored data from the alternate location into the

actual location.

Restoring Files on a Member ServerRestoration on a member server is always authoritative because it is not FRS-aware. In other words, it assumes that there are no other copies of the restored files on other servers. As a result, the replica being restored replicates its data to other members of the replica set.Note that an authoritative restore is simply the restoration of a file onto a member that is actively replicating files. It does not produce a mirror image of the backup tape content in the replica share. As an example, any new files that were created in the replica share after the backup tape was created are not deleted from the replica share. To perform a true authoritative restore of a replica share so that it mirrors the content from the backup tape, the user must first delete all files in the replica share and then restore the data from the backup tape.

To perform a nonauthoritative restore of a Dfs replica1. Remove the failed member from the replica set.

2. Disable replication on the host server.3. Repair the faulty member. For example, replace a disk drive that has failed.4. Add the member back as a new replica. Do not specify it as initial master when you enable

replication unless you want to do an authoritative restore.Note that initial master is only relevant when this member is the only member (that is, the first member) in the replica set. In this case, FRS enumerates the replica share and preloads its database with information about each file and folder. In addition, FRS assigns file object IDs to every file and folder in the replica share. If this member is not the only member in the replica share, FRS always treats the addition of a new member as nonauthoritative as described previously.

Troubleshooting FRSWhen FRS stops replicating content, the first thing to do is check the event log to see if the staging directory is full. If it is, replication stops. See step 7 in the following procedure for ways to correct this problem.A general procedure for troubleshooting FRS problems consists of the following steps:1. Verify that both Computer A and Computer B are available on the network. Because FRS uses

the fully qualified domain name (FQDN) of the replica members, a good first check is to use a ping command specifying the fully qualified name of the problem replicas. From Computer A, send a ping command with Computer B’s FQDN. From Computer B, send a ping command to Computer A’s FQDN. Verify that the addresses returned by the ping command are the same as the addresses returned by an ipconfig /all command carried out on the command line of the destination computer.

2. Use the Services administrative console to confirm that FRS is running on the remote computer.3. If the service is not running, review the File Replication service container of Event Viewer

(Eventvwr.msc) on the problem computer. If the service has asserted, troubleshoot the assertion. Otherwise, restart the service.

4. Verify RPC connectivity between Computer A and Computer B. Check FRS event logs on both computers. If Event ID 13508 is present, there might be a problem with the RPC service on either computer or with creating a secure connection between Computer A and Computer B.

5. Use the Active Directory Sites and Services console to verify the replication schedule on the Connection object. Make sure that replication is enabled between Computer A and Computer B and that the connection is enabled. The Connection object is the inbound connection under Computer A’s NTFRS_MEMBER object from Computer B. For SYSVOL, the connection object resides under Sites\site_name\Servers\server_name\NTDS Settings\connection_name.

6. Create a test file on Computer B, and verify its replication to Computer A.7. Check for free disk space on Computer A (source directory, staging directory, and database

partition) and Computer B (destination partition, preinstall partition, and database partition). Look for the following events in Event Viewer: 13511: Database is out of disk space.

For more information about how to move the database to a larger volume, see “FRS Tables” earlier in this chapter.

13522: Staging directory is full.This can be caused by an outbound partner that has not connected for a while. Delete the connection and stop and restart FRS to force deletion of the staging files. You can also follow the procedure described in “Tuning Recommendations” earlier in this chapter to increase the size of the staging directory.

8. Check for files that are larger than the amount of free space on the source or destination server or larger than the size of the staging directory limit in the registry. Resolve the disk space problem or increase the maximum staging file space. See Error 13522 for details.

9. Check whether the file on the originating server is locked on either computer. If the file is locked on Computer B so that FRS cannot read the file, FRS cannot generate the staging file, which delays replication. If the file is locked on Computer A so that FRS cannot update the file, FRS continues to retry the update until it succeeds. The retry interval is 30 to 60 seconds.

10. Check whether the source file was excluded from replication. Confirm that the file is not EFS encrypted, a NTFS junction, or excluded by a file or folder filter on the originating replica member. If any of these are true, FRS does not replicate the file or directory.

11. If all of the previous conditions check out, try to replicate the file again.

FRS LogsFRS creates text-based logs in the systemroot\Debug directory to help you debug problems. The Ntfrsapi.log file contains events that take place during promotion and demotion — namely, creating the subkeys in the NTFRS registry key.To observe a particular event, take a snapshot of the log files as close to the occurrence of the event as possible. Save the log files in a different location so they can be examined afterward.

Log SettingsThe Ntfrs log files store transaction and event detail in sequentially numbered files: Ntfrs_0001 through Ntfrs_0005. Transactions and events are written to the log with the highest version number in existence at that time. The characteristics of the log files are determined by the values of several registry entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters subkey. After the number of logs specified by the value of the Debug Log Files registry entry have been filled, the lowest log version is deleted and the remaining log file names are decremented by n–1 to make room for a new log file.Log detail is controlled by the value of the Debug Log Severity registry entry, ranging from 0 to 5, with 5 providing the most detail. Log size is determined by the value of the Debug Maximum Log Messages registry entry. The default value of 10,000 lines for Debug Maximum Log Messages results in a ~ 1-MB log file for a total of 10 MB of logs (Debug Log Files * (Debug Maximum Log Message * 100)). Setting Debug Log Messages to 50,000 results in a 5-MB log file and 25 MB of log detail with default settings.To change the quantity, size, or level of detail of FRS log files, edit the values of the registry entries. Before you increase either the size or quantity of log files, make sure sufficient disk space is available. In general, budget 1 MB for each 10,000 messages.

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings that might degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

To change the characteristics of Ntfrs log files1. From the Start menu, click Run.

Caution

2. Type cmd, and then type net stop ntfrs.3. Start a registry editor (either Regedit.exe or Regedt32.exe).4. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

Services\NtFrs\Parameters, and edit the values of the following entries: Debug Log Severity: Determines the level of detail in the Ntfrs_000n.log files. Severity

levels are assigned to different debug print statements in the FRS code. If the value of this entry is 0, only the most severe events are recorded in the log. If the value of this entry is 5, almost all events are recorded in the log. Higher values are inclusive.

Debug Log Files: Determines how many FRS service transaction and event log files can be active simultaneously. Logs are written on a first in–first out basis with the highest number containing the most recently logged entries. Logs 1 through 5 are created in sequential order. When the number of messages written to Ntfrs_0005.log reaches the value of Debug Maximum Log Messages, Ntfrs_0001.log is deleted, Ntfrs_0002.log becomes 1, 3 becomes 2, and so on.

Debug Maximum Log Messages: Determines how many entries can be stored in a debug log file. 10,000 entries use approximately 1 MB of space on disk.

These entries are not visible by default. Use the Edit menu to add them, if necessary.5. Close the registry editor and restart FRS. FRS creates the specified log files automatically.

To capture a random or intermittent event, you might want to expand FRS logging capability. For example, you can increase the number of log files to 50 and then archive the files when they become full. This accumulates the history needed to respond to overnight queries from users, for example.Depending on the problem that is being investigated, it might be necessary to review logs on both the inbound and outbound replicas. System clocks must be synchronized so that events can be correlated between replication partners.Finally, the recovery setting for the FRS service in service control manager (SCM) can be critical to locating and keeping important log events on the system. If the service is asserting but SCM is configured to automatically start FRS upon error, enough log traffic might be generated to cause events in Ntfrs_0005.log to decrement and be deleted from the drive. Stop the service on both the inbound and outbound replicas close to the time when an error occurs, and then copy the logs to a safe place.

Analyzing Log FilesThe first step to solving problems with the logs is to make sure the Debug Log Severity entry in the registry is set high enough to capture the events needed to identify the problem. Severity settings range from 0 to 5 and are cumulative, meaning that a setting of 4 includes log events with a severity of 0 to 3.Next, identify errors, warning messages, and milestone events in the log files. A good practice is to start at the bottom of the last log file and work your way up. Focus on keywords such as “install,” “success,” and “fail.” If you do not find the error that you are looking for, start at the bottom of the previous log (Ntfrs_0005, then Ntfrs_0004, and so on). Use the find command to isolate errors in the log files as follows:find /in “error warn fail” ntfrs.* >err.tmp

Depending on the context, some errors (such as, “jet attach db – 1811. Db not found”) can be ignored because the Ntfrs.jdb file does not exist the first time FRS starts. Until the service creates the file, expect to see this immediately after Dcpromo or when you

delete the Ntfrs.jdb file manually. Sharing violations, designated by the SHARING_VIOLATION status code, occur when a user or process has a lock on a file. Because FRS tracks only closed files, locked files and directories do not replicate.If failure errors are encountered, look at the thread number and follow up all events in the log that have matching thread identifiers until you see the associated change order.To determine why a file on Computer A has not replicated to a second or third replica, locate the “:: COG” number in the Ntfrs_00n.log files on the originating server. Search for the same globally unique identifier (GUID) in the logs on the second and third replicas.Ntfrsutl ToolYou can use the Ntfrsutl tool to do the following: Show the ID table, inbound log, or outbound log for a computer hosting FRS. Examine memory usage by FRS. Show the FRS configuration in Active Directory. List the active replica sets in a domain. List the application programming interface (API) and version number for FRS. Poll immediately, quickly, or slowly for changes to the FRS configuration.

The syntax for Ntfrsutl is shown in Figure 18.7.

Figure 18.7 Ntfrsutl Tool