It's time for another File Replication Service (FRS) performance boost. Microsoft released a standalone FRS update before the release of Windows 2000 Service Pack 3 (SP3) and bundled the update in SP3. Last week, the company issued a post-SP3 FRS tune-up that addresses several inefficiencies in the original replication model. For reference purposes, a full replication is also known as version vector join (vvjoin). Of the eight code fixes in the release, most eliminate processing delays or failures that occur when downstream partners process out-of-sequence change requests that modify the contents of the replication directory. Here's a summary of the key changes:
- The update eliminates a replication failure caused by a delay that a downstream partner experiences when processing asynchronous change orders. In SP3, out-of-sequence change orders that an upstream partner sends to downstream partners can delay or stop a full synchronization. After you install this update, replication partners will process child change orders (i.e., requests to create a file or lower directory) before receiving the request to create the container, or parent, directory. The fix should expedite the process of synchronizing newly promoted domain controllers, and successfully performing nonauthoritative restores.
- The update corrects a replication failure that occurs when a partner incorrectly processes out-of-order delete requests. In SP3, when a downstream partner receives a delete request for a parent container before it receives delete requests for items in the parent directory, the system pauses until it receives change orders to delete the child items. This delay stops replication, and a bug in the deletion algorithm leaves the empty parent directory in the replication folder.
- The update eliminates unnecessary synchronizations caused by timestamp differences on the upstream and downstream partners. In SP3, the upstream partner decides whether a downstream partner needs a vvjoin by comparing the timestamps created during the previous join. When the timestamps don't match, the upstream system initiates a full synchronization. This hotfix eliminates unnecessary replication by forcing FRS to record the same timestamp on each partner.
- The update corrects a bug that ignores local change orders: When a parent folder is marked as delete deferred, it's removed from the folder filter table, causing the system to skip local changes.
- The update adds corrective information to the event ID 13508 warnings in the FRS event log.
- The update introduces a new command-line option in the Ntfrsutl utility that lets you force a replication at any time (Ntfrsutl Forcerepl).
- The update eliminates an FRS-related memory leak in the Windows Management Instrumentation (WMI) utility.
- The update restricts access to the debug log folder to members of the Administrators group.
The update, which applies only to Win2K SP3 systems, contains new versions of four key FRS components: ntfrs.exe, ntfrsutl.exe, ntfrsapi.dll, and ntfrsprf.dll. The first two files have a release date of January 10, and the second two have a file release date of January 22, 2002. The documentation states that you can use two methods to install the update: Install the hotfix and reboot, or stop FRS, install the hotfix, and restart the FRS service. Given the sensitivity of these changes and the serious consequences that can occur because of a bug in the modified files, I encourage you to test it carefully before you deploy it in your production environment. This post-SP3 FRS fix is only available from Microsoft Product Support Services (PSS). For more information about the error messages that occur when FRS encounters any of the above situations, and for more details about other fixes, see the Microsoft articles "Improvements in the Post-Service Pack 3 Release of Ntfrs.exe" and "Issues That Are Fixed in the Post-Service Pack 3 Release of Ntfrs.exe".
First 2003 Security Hotfix
The first security hotfix of 2003 eliminates a buffer overflow condition that a malicious user can exploit to run code of the attacker's choice. The weakness exists in the native remote procedure call (RPC) Locator service (locator.exe) that's present in the server and workstation versions of Win2K and Windows NT 4.0 systems, and in both versions of Windows XP. Unless you change the system default, the Locator service starts automatically on Win2K and NT 4.0 domain controllers (DCs) but is set to manual startup on standalone server and workstation versions, as well as XP systems.
RPC communication is a core technique developers use to implement local and remote interprocess communication. When a system wants to communicate with a remote resource, the RPC service calls its locator service to translate a Universal Naming Convention (UNC) name into a network location. This name-lookup mechanism, also known as named pipes, uses the Server Message Block (SMB) protocol and TCP ports 139 (NetBIOS session port) and 445 (microsoft-ds or directory service port).
An attacker can leverage this exploit only on a system on which the RPC Locator service is running, which means DCs are vulnerable to both internally or externally launched exploits of this buffer overflow. On the workstation side, you can eliminate the problem by disabling the Locator service. However, any user with local Administrator privileges can easily enable the service, so this workaround isn't a permanent fix.
Microsoft Security Bulletin MS 03-001 (Unchecked Buffer in Locator Service Could Lead to Code Execution) documents the vulnerability and provides more information about the risk factors. The reference states that you can mitigate the risk of an external attempt to use this exploit by closing both TCP ports at the firewall. The bulletin gives the download locations for this hotfix, which is rated critical for DCs.