Slow network performance occurs if you copy files to a domain controller that is running Windows 2000 or Windows Server 2003

If you copy files from a Microsoft Windows 2000-based client computer, a Microsoft Windows XP-based client computer, or Microsoft Windows Server 2003-based client computer to a network share on a domain controller that is running Windows 2000 or Windows Server 2003, network performance is slower than if you copy the same files to a member server that is running Windows 2000 or Windows Server 2003. You may notice this problem if you copy many small files; however, you may not notice this problem if you copy a few large files. This problem only occurs if you either use Microsoft Windows Explorer to copy the files or if a Windows Explorer window is open and connected to the target server. However, if you use Xcopy.exe to copy the files and all of the Windows Explorer windows are closed, you do not experience this problem.

This problem occurs because server message block (SMB) write operations to a domain controller that is running Windows 2000 or Windows Server 2003 may experience a delay of up to 200 milliseconds between file copies.

If you review a trace of the problem, you notice that the delay occurs after the client sends the server an SMB Notify Change command with the FID entry that matches the FID entry of the target folder. Windows Explorer posts a Notify Change request on the network share, which asks to be notified if something changes in the folder that appears in the right pane of Windows Explorer. If a domain controller receives the Notify Change request, it does not respond to it immediately; it does not send packets for up to 200 milliseconds. At that point, a simple Transmission Control Protocol (TCP) acknowledgement (ACK) packet is sent and the file operation resumes as usual.

This behavior is a result of the interaction between two core networking components of Windows 2000, TCP delayed ACKs, and thread prioritization on domain controllers. Thread prioritization allows a domain controller to properly prioritize directory services and account management operations before some SMB activities, such as responding to Notify Change requests.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
When you consider this problem, be aware that it only occurs in very specific circumstances; this problem only occurs if a client is using Windows Explorer to copy a large number of files to a Windows 2000-based domain controller. If you change the value of the delayed ACK timer, you can prevent some of the symptoms from occurring; however, if you modify a core TCP/IP value, you may experience unexpected results in the future. Therefore, Microsoft recommends that you consider other alternatives before you modify the timer. Other solutions include moving the file shares to a member server or using another tool (such as Xcopy or Robocopy, which is part of the Windows 2000 Resource Kit) to copy large numbers of files to a domain controller.

On the domain controller, you can edit the TcpDelAckTicks registry value to adjust the TCP delayed ACK timer. If you change the TCP delayed ACK timer to a lower value, the server sends an ACK packet more frequently but at shorter intervals.

Note that on a high latency, highly saturated segment, the net increase in the ACK packets from the domain controller may put additional strain on the network. To make sure that the changed TCP delayed ACK timer value does not cause additional bottlenecks, test the value thoroughly.

If the network can handle the extra ACK packets, apply the following pre-Service Pack 3 (SP3) hotfix to Windows 2000 Service Pack 2 (SP2) so that you can modify the delayed ACK timer value:

After you apply this hotfix, use the following procedure to add the following registry value that specifies the custom parameter for the delayed ACK timer:

1. Start Registry Editor (Regedt32.exe).
2. Locate and click the following key in the registry, where Adapter GUID is the globally unique identifier (GUID) for the network adapter that connects to the clients:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID
3. On the Edit menu, click Add Value, and then add the following registry value:
   Value name: TcpDelAckTicks
   Data type: REG_DWORD
   Value data: You can set this value to a range from 0 to 6. The default setting is 2 (200 milliseconds).
4. Quit Registry Editor.
5. Restart Windows for this change to take effect.

This registry value specifies the number of 100-millisecond intervals to use for the delayed ACK timer on a per-interface basis. By default, the delayed ACK timer value is 200 milliseconds. If you set the TcpDelAckTicks value to 0, delayed acknowledgments are disabled. This setting causes the computer to immediately send an ACK packet for every packet it receives.

Note Adapter-specific values are listed under subkeys for each adapter. Make sure that you add the TcpDelAckTicks value to the following registry key: Do not add this value to the following registry key:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

In network traces you can see that the client sends the "SMB: C NT transact - Notify Change" packet. The Windows 2000-based domain controller sends back an ACK packet to the client 200 milliseconds later. After the client receives the ACK packet, the client begins the next SMB operation and copies the next file.

Note If you are using Network Monitor, you can see the delays better if you use the following filter: Use this filter in combination with the following display options: You can identify the corresponding requests and answers by looking at the following SMB frame attribute: The Delayed Acknowledgments functionality is based on Request for Comments (RFC) 1122. TCP uses delayed ACKs to reduce the number of packets that are sent on the network. The Microsoft TCP/IP stack takes a common approach to implementing delayed ACKs. When the data is received by TCP on a connection, the stack only returns an ACK if one of the following conditions is met:

• Condition 1: No ACK is sent for the previous segment that is received.
• Condition 2: A segment is received, but no other segment arrives within 200 milliseconds (the default value) for that connection.

Typically, an ACK is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires. You can adjust the delayed ACK timer by using the procedure that is described in the "Resolution" section of this article to add the TcpDelAckTicks registry value (this value is new in Windows 2000).

Note Be aware that if you change the TcpDelAckTicks registry value, you may experience unexpected effects in the future. Therefore, Microsoft recommends that you consider other alternatives before you modify the timer.

The delay occurs if the previous packet was acknowledged and the Notify Change request response is queued by a domain controller for a period of time that sometimes exceeds 200 milliseconds. Because the default ACK timer counts to 200 milliseconds, the TCP ACK packet occurs 200 milliseconds after the Notify Change request is received from the client. Because the client waits for a response from the server before it proceeds with the next SMB operation, the delay occurs while the server's delayed ACK timer counts to its threshold. If you perform a network trace, you notice that not every Notify Change request from the client experiences a delay.

The Notify Change request that does not experience the delay is immediately preceded by another packet which is not acknowledged. Therefore, the acknowledgement is not delayed in the domain controller's acknowledgement because the first of the conditions that is described at the beginning of this section is met. The Notify Change requests that do experience the delay have had the previous packets acknowledged; therefore, the domain controller does not respond back until the delayed ACK timer expires (the default value is 200 milliseconds) because the second of the conditions that is described in this section is triggered.

You cannot modify the thread prioritization of a domain controller; therefore, you must change the TCP delayed ACK timer value to a lower value to prevent the symptoms that are described in the "Symptoms" section of this article from occurring. After you do so, the server sends ACK values more frequently but at shorter intervals.

For more information about the TcpDelAckTicks registry value, refer to the white paper that is located on the following Microsoft Web site: For more information about this problem, click the following article number to view the article in the Microsoft Knowledge Base: On a client that is running Windows XP or Windows Server 2003, there is a new registry key named TcpAckFrequency that controls TCP ACKs before the delayed ACK timer is reached. For more information, click the following article number to view the article in the Microsoft Knowledge Base: For more information, click the following article number to view the article in the Microsoft Knowledge Base: