Hardware manufacturers regularly release BIOS, firmware, and driver updates that can improve performance and availability for the associated hardware. Visit the hardware manufacturer’s Web site to download and apply updates for the following hardware components on each computer in the BizTalk Server environment:

1. BIOS updates
   
2. SAN drivers (if using a SAN)
   
3. NIC firmware
   
4. NIC drivers
   

• It is critical hyper-threading be turned off for BizTalk Server computers. This is a BIOS setting, typically found in the Processor settings of the BIOS setup. Hyper-threading makes the server appear to have more processors/processor cores than it actually does; however hyper-threaded processors typically provide between 20 and 30% of the performance of a physical processor/processor core. When BizTalk Server counts the number of processors to adjust its self-tuning algorithms; the hyper-threaded processors cause these adjustments to be skewed which is detrimental to overall performance.
  
• Hyper-threading should be turned off for SQL Server computers because applications can cause high levels of contention (such as BizTalk Server) may cause decreased performance in a hyper-threaded environment on a SQL Server computer.
  

Note
On most computers, hyper-threading is configured via the computer BIOS. Steps will vary by computer type and manufacturer.

In a BizTalk Server environment with multiple MessageBox databases on separate SQL Server computers, additional overhead associated with Microsoft Distributed Transaction Coordinator (MSDTC) is incurred. By default the MSDTC log files are located in the %systemdrive%\windows\system32\msdtc directory of the computers running the DTC service. To mitigate the possibility that DTC logging could become a performance bottleneck, consider moving the MSDTC log file directory to a fast disk drive. To change the MSDTC log file directory follow these steps:

1. Click Start, click Run, and type dcomcnfg to launch the Component Services Management console.
   
2. Expand Component Services, expand Computers, right-click My Computer, and then click Properties.
   
3. In the My Computer Properties dialog box, click the MSDTC tab.
   
4. In the Location edit box under Log Information, type the path where you want the new log to be created (for example, G:\Logs\DTCLog).
   
5. Click Reset log, and you will be prompted for service restart. Click OK to restart the DTC service, and then click OK to confirm the MSDTC service has been restarted.
   

Antivirus software real-time scanning of BizTalk Server executable files and any folders or file shares monitored by BizTalk Server receive locations can negatively impact BizTalk Server performance. If antivirus software is installed on the BizTalk Server computer(s), disable real-time scanning of non-executable file types referenced by any BizTalk Server receive locations (usually .XML, but can also be .csv, .txt, etc.) and configure antivirus software to exclude scanning of BizTalk Server executable Files

Intrusion detection software can slow down or even prevent valid communications over the network. If intrusion detection software is installed, disable network scanning between BizTalk Server computers and external data repositories (SQL Server) computers or messaging services (Message Queuing, WebSphere MQSeries, etc.) computers.

Excessive disk fragmentation in the BizTalk Server environment will negatively impact performance. Follow these steps to defragment disks in the BizTalk Server Environment:

1. Defragment all disks (local and SAN/NAS) on a regular basis by scheduling off-hours disk defragmentation.
   
2. Defragment the Windows PageFile and pre-allocate the Master File Tables of each disk in the BizTalk Server environment to boost overall system performance.
   

   Note
   Use the PageDefrag utility available at http://go.microsoft.com/fwlink/?LinkId=108976 to defragment the Windows PageFile and pre-allocate the Master File Tables.

Real-time scanning of the SQL Server data and transaction files (.mdf, .ndf, .ldf, .mdb) can increase disk I/O contention and reduce SQL Server performance. Note that the names of the SQL Server data and transaction files may vary between BizTalk Server environments. For more information about the data and transaction files created with a default BizTalk Server configuration, see Optimizing Filegroups for the Databases.

Review the following information to configure MSDTC for BizTalk Server:

• "How to Enable MSDTC on the BizTalk Server" at http://go.microsoft.com/fwlink/?LinkId=108445.
  
• "Troubleshooting Problems with MSDTC" at http://go.microsoft.com/fwlink/?LinkId=101609.
  

Note
This step is only required if one or more firewalls are in place in your BizTalk Server environment.

Review the following information to configure firewall(s) for BizTalk Server:

• "Required Ports for BizTalk Server" at http://go.microsoft.com/fwlink/?LinkId=101607.
  
• "How to configure RPC dynamic port allocation to work with firewalls" at http://support.microsoft.com/kb/154596.
  

Review the following information to install the appropriate COM+ and MS DTC hotfix rollup packages:

• The final version of the COM+ rollup is the “Windows Server 2003 Post-Service Pack 2 COM+ 1.5 Hotfix Rollup Package 12”. This hotfix will install on any version of Windows Server 2003, even those without a service pack installed. More information about this hotfix can be found in Microsoft Knowledge Base article 934016, "Availability of Windows Server 2003 Post-Service Pack 2 COM+ 1.5 Hotfix Rollup Package 12" at http://support.microsoft.com/kb/934016.
  
• The latest DTC hotfix rollup package KB article can be found by searching http://support.microsoft.com for the phrase (including the quotes):
  
  "MS DTC Hotfix Rollup Package"

  The following query does this search for you. Choose the latest one:
  http://support.microsoft.com/search/default.aspx?query="MS+DTC+Hotfix+Rollup+Package"
  

For more information about problems that may occur with PAC verification for services, see Microsoft Knowledge Base article 906736, "You experience a delay in the user-authentication process when you run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003" at http://support.microsoft.com/kb/906736.

The Windows Server 2003 Resource Kit includes a tool called the Interrupt Filter Configuration tool (IntFltr). The Intfltr tool allows you to “bind” or change the CPU affinity of the interrupts for a given device (such as a network adapter) to a specific processor or processors on a multiprocessor computer. This binding is also referred to as partitioning. The binding of interrupts from a specific network adapter to specific processors on a multiprocessor computer enforces running deferred procedure calls (DPCs) and interrupt service routines (ISRs) for the network adapter on the designated processors. Note that interrupt affinity cannot be configured on single processor computers.

Note
A DPC is defined as a queued call to a kernel-mode function that will usually be executed at a later time. An ISR is defined as a routine whose purpose is to service a device when it generates an interrupt. For more information about deferred procedure calls and interrupt service routines, see the Windows Driver Kit documentation at http://go.microsoft.com/fwlink/?LinkId=84418.

Interrupt Filter Configuration Tool

On Windows Server 2003 based multiprocessor computers, the default behavior of the interrupt controller is to assign device interrupts to any available processor. When network connections and file server sessions for a given network adapter are filtered/bound/partitioned to run on a specific set of processors, rather than any available processor, the performance and scalability of the associated network processing is improved. Large BizTalk Server solutions often employ the use of multi-processor SQL Server computers with multiple network adapters for which interrupt filtering may be particularly beneficial.
Interrupt filtering using Intfiltr should always be evaluated in a test environment before employing in a production environment. The hardware, operating system and application configuration of the test environment should approximate the production environment as closely as possible. This will allow you to test various permutations of interrupt filtering and determine the extent that interrupt filtering will increase performance.
It is recommended that you disable hyper-threading before configuring Intfiltr on a computer with CPUs that supports hyper-threading. This will ensure that interrupts are assigned to physical processors rather than logical processors. Assigning interrupt affinity to logical processors that refer to the same physical processor will not increase performance and could even degrade system performance.
The Interrupt Filter Configuration tool is available with the Server 2003 Resource Kit Tools at http://go.microsoft.com/fwlink/?LinkId=106079.

Windows Server offers multiple file system types for formatting drives, including NTFS, FAT, and FAT32. NTFS should always be the file system of choice for servers.
NTFS offers considerable performance benefits over the FAT and FAT32 file systems and should be used exclusively on Windows servers. In addition, NTFS offers many security, scalability, stability and recoverability benefits over FAT and FAT32.
Under previous versions of Windows, FAT and FAT32 were often implemented for smaller volumes (say <500 MB) because they were often faster in such situations. With disk storage relatively inexpensive today and operating systems and applications pushing drive capacity to a maximum, it is unlikely that such small volumes will be in use. FAT32 scales better than FAT on larger volumes but is still not an appropriate file system for Windows servers.
FAT and FAT32 have often been implemented in the past as they were seen as more easily recoverable and manageable with native DOS tools in the event of a problem with a volume. Today, with the various NTFS recoverability tools built both natively into the operating system and available as third-party utilities available, there should no longer be a valid argument for not using NTFS for file systems.

Though using NTFS file system compression is an easy way to reduce space on volumes, it is not appropriate for enterprise file servers. Implementing compression places an unnecessary overhead on the CPU for all disk operations and is best avoided. Think about options for adding additional disks, near-line storage or consider archiving data before seriously considering file system compression.

When configuring drive arrays and logical drives within your hardware drive controller, ensure you match the controller stripe size with the allocation unit size that the volumes will be formatted with. This will ensure disk read and write performance is optimal and offer better overall server performance.
Configuring larger allocation unit (or cluster or block) sizes will cause disk space to be used less efficiently, but will also provide higher disk I/O performance as the disk head can read in more data during each read activity.
To determine the optimal setting to configure the controller and format the disks with, you should determine the average disk transfer size on the disk subsystem of a server with similar file system characteristics. Use the Windows Performance Monitor tool to monitor the Logical Disk object counters of Avg. Disk Bytes/Read and Avg. Disk Bytes/Write over a period of normal activity to help determine the best value to use.
Although smaller allocation unit sizes may be warranted if the system will be accessing many small files or records, an allocation unit size of 64 KB delivers sound performance and I/O throughput under most circumstances. Improvements in performance with tuned allocation unit sizes can be particularly noted when disk load increases.

Note

Either the FORMAT command line tool or the Disk Management tool is required to specify an allocation unit size larger than 4096 bytes (4 KB) when formatting volumes. Windows Explorer will only format up to this threshold. The CHKDSK command can be used to confirm the current allocation unit size of a volume however it needs to scan the entire volume before the desired information is displayed (shown as Bytes in each allocation unit).

The less data a disk has on it, the faster it will operate. This is because on a well defragmented drive, data is written as close to the outer edge of the disk as possible, as this is where the disk spins the fastest and yields the best performance.
Disk seek time is normally considerably longer than read or write activities. As noted above, data is initially written to the outside edge of a disk. As demand for disk storage increases and free space reduces, data is written closer to the center of the disk. Disk seek time is increased in locating the data as the head moves away from the edge, and when found, it takes longer to read, hindering disk I/O performance.
This means that monitoring disk space utilization is important not just for capacity reasons but for performance also.
As a rule of thumb, work towards a goal of keeping disk free space between 20% to 25% of total disk space. If free disk space drops below this threshold, then disk I/O performance will be negatively impacted.

Run a defragmenter utility regularly on your disks, including the root drive, to prevent performance degradation. Do this weekly on busy disks. A disk defragmenter is installed with Windows and can be run from a Scheduled Task at specified intervals.

The BizTalk Server process (BTSNTSVC.exe) runs as a background service. By default, Windows Server is configured to adjust for best performance of application programs and not for background services.
Windows Server 2003 uses preemptive multi-tasking to prioritize process threads that will be attended to by the CPU. Preemptive multi-tasking is a methodology whereby the execution of a process is halted and another process is started, at the discretion of the operating system. This scheme prevents a single thread from dominating the CPU.
Switching the CPU from executing one process to the next is known as context-switching. The Windows operating system includes a setting that determines how long individual threads are allowed to run on the CPU before a context-switch occurs and the next thread is serviced. This amount of time is referred to as a quantum. This setting lets you choose how processor quanta are shared between foreground programs and background services. Typically for a server it is not desirable to allow a foreground program to have more CPU time allocated to it than background services. That is, all applications and their processes running on the server should be given equal consideration for CPU time.
To increase performance for background service like BizTalk host instances, follow these steps:

1. Click Start, click Control Panel, and then click System.
   
2. Click the Advanced tab, and then click Settings under Performance.
   
3. Click the Advanced tab, click Background services, and then click OK twice.
   

A default installation of Windows Server 2003 enables several services that may not be required in a BizTalk Server environment. Each running service consumes system resources and so unnecessary services should be disabled to improve overall performance.
Care should be taken when disabling services. Thoroughly research the purpose of a service before disabling the service as Windows Server requires certain services are running. If services required by Windows Server 2003 are disabled, the operating system may become inoperable and possibly even unable to boot.
To disable Windows Server 2003 services that are not required for a dedicated BizTalk Server, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
   
2. Under Computer Management (Local), expand Services and Applications, and then click Services.
   In the Status column, each service that is running is labeled "Started." Stop and disable any service that is started unnecessarily, for example, the following services are not required on a dedicated BizTalk Server:
   
   • Alerter
     
   • ClipBook
     
   • DHCP Client
     
   • DHCP Server
     
   • Fax Service
     
   • File Replication
     
   • Infrared Monitor
     
   • Internet Connection Sharing
     
   • Messenger
     
   • NetMeeting Remote Desktop Sharing
     
   • Network DDE
     
   • Network DDE DSDM
     
   • NWLink NetBIOS
     
   • NWLink IPX/SP
     
   • Print Spooler
     
   • Telephony
     
   • Telnet
     
   • Uninterruptible Power Supply
     
3. Note the services that depend on each service that you want to disable. To do this, follow these steps:
   
   1. Double-click the service you want to disable.
      
   2. Click the Dependencies tab.
      
   3. In the This service depends on the following system components list, note the services this service depends on.
      
   4. In the The following system components depend on this service list, note the services that cannot start without this service, and then click OK.
      
4. One at a time, disable each service you have selected. To do this, follow these steps:
   
   1. Right-click the service you want to disable, and then click Properties.
      
   2. In the Startup type list, click Disabled.
      
   3. If you want to stop the service immediately, click Stop.
      If the Stop Other Services dialog box appears, note the other dependent services that will also stop, and then click Yes, and then click OK.
      
5. Repeat step 4 to disable the other nonessential services.
   

Note

Test the server for correct operation after you disable each service to make sure you did not disable a service you want to continue to use. If the server is a member of a Windows Server 2003 domain, which BizTalk Servers typically are, you must have the TCP/IP helper service on your system to correctly apply Group Policy to the computer. When you disable the DHCP client, the DHCP client stops DNS dynamic update protocol registration and requires manual DNS records to be added for this client in the DNS server.

When starting a .NET application, the .NET Framework will attempt to download the Certificate Revocation list (CRL) for any signed assembly. If your system does not have direct access to the Internet, or is restricted from accessing the Microsoft.com domain, this may delay startup of BizTalk Server. To avoid this delay at application startup, you can use the following steps to manually download and install the code signing Certificate Revocation Lists on your system.

1. Download the latest CRL updates from http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl and http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl.
   
2. Move the CodeSignPCA.crl and CodeSignPCA2.crl files to the isolated system.
   
3. From a command prompt, enter the following command to use the certutil utility to update the local certificate store with the CRL downloaded in step 1:
   certutil –addstore CA c:\CodeSignPCA.crl
   

The CRL files are updated regularly, so you should consider setting a reoccurring task of downloading and installing the CRL updates. To view the next update time, double-click the .crl file and view the value of the Next Update field.

Many operations involving tickets, receipts and logging rely on the local system clock being accurate. This is especially true in a distributed environment, where time discrepancies between systems may cause logs to be out of sync or tickets issued by one system to be rejected by another as expired or not yet valid.

For more information on configuring a server to automatically synchronize time, see http://go.microsoft.com/fwlink/?LinkId=99420.

Follow these guidelines to configure the Windows PAGEFILE (paging file) for optimal performance:

1. Move the paging file to a physical volume separate from the physical drive that operating system is installed on to reduce disk contention and increase disk performance - On BizTalk Server computers, the performance gain associated with moving the paging file will vary depending on the document processing load. On SQL Server computers, moving the paging file to a separate volume is considered a best practice in all scenarios due to the disk intensive nature of SQL Server.
   
2. Isolate the paging file onto one or more dedicated physical drives that are configured as either RAID-0 (striping) or RAID-1 (mirroring) arrays, or on single disks without RAID - By using a dedicated disk or drive array where PAGEFILE.SYS is the only file on the entire volume, the paging file will not become fragmented, which will also improve performance. As with most disk-arrays, performance of the array is improved as the number of physical disks in the array is increased. If the paging file is distributed between multiple volumes on multiple physical drives in a disk array, the paging file size should be the same size on each drive in the array. When configuring a disk array, it is also recommended to use physical drives that have the same capacity and speed. Note that redundancy is not normally required for the paging file.
   
3. Do not configure the paging file on a RAID 5 array - Configuration of the paging file on a RAID 5 array is not recommended because paging file activity is write intensive and RAID 5 arrays are better suited for read performance than write performance.
   
4. If you do not have resources to move the paging file to a physical volume other than the operating system is installed on, configure the paging file to reside on the same logical volume as the operating system - Configuring the paging file to reside on a another logical volume which is on the same physical disk as the operating system will increase disk seek time and reduce system performance as the disk drive platter heads will be continually moving between the volumes, alternately accessing the page file, operating system files, application files, and data files. Also, the operating system is typically installed on the first partition of a physical disk, which is usually the closest to the outside edge of the physical disk and where disk speed is and associated performance are optimal for the disk.
   

   Important
   If you do remove the paging file from the boot partition, Windows cannot create a crash dump file (MEMORY.DMP) in which to write debugging information in the event that a kernel mode STOP error occurs. If you do require a crash dump file, then you will have no option but to leave a paging file of at least the size of physical memory + 1 MB on the boot partition.

5. Manually set the size of the paging file – Manually setting the size of the paging file typically provides better performance than allowing the server to size it automatically or having no paging file at all. Best-practice tuning is to set the initial (minimum) and maximum size settings for the paging file to the same value. This ensures that no processing resources are lost to the dynamic resizing of the paging file, which can be intensive. This is especially true given that this resizing activity typically occurs when the memory resources on the system are already becoming constrained. Setting the same minimum and maximum page file size values also ensures the paging area on a disk is one single, contiguous area, improving disk seek time. Windows Server 2003 automatically recommends a total paging file size equal to 1.5 times the amount of installed RAM. On servers with adequate disk space, the paging file on all disks combined should be configured up to twice the physical memory for optimal performance.
   

3D or OpenGL screen savers are known to be CPU-intensive and use important system resources when they are running. It is best to avoid installing these altogether as an option at server-build time, or to remove them if they have been installed. The basic “Windows Server 2003” or blank screen savers are an excellent alternative to using CPU-intensive screen savers.

At system startup, Windows creates several server threads that operate as part of the System process. These are called system worker threads. They exist with the sole purpose of performing work on the behalf of other threads generated by the kernel, system device drivers, the system executive and other components. When one of these components puts a work item in a queue, a thread is assigned to process it.
The number of system worker threads should ideally be high enough to accept work tasks as soon as they become assigned. The trade off, of course, is that worker threads sitting idle consume system resources unnecessarily. Modify and/or create the following REG_DWORD values in the registry and then set to the recommended values listed below.

The AdditionalDelayedWorkerThreads value increases the number of delayed worker threads created for the specified work queue. Delayed worker threads process work items that are not considered time-critical and can have their memory stack paged out while waiting for work items. An insufficient number of threads will reduce the rate at which work items are serviced; a value that is too high will consume system resources unnecessarily.

AdditionalDelayedWorkerThreads

The AdditionalCriticalWorkerThreads value increases the number of critical worker threads created for a specified work queue. Critical worker threads process time-critical work items and have their stack present in physical memory at all times. An insufficient number of threads will reduce the rate at which time-critical work items are serviced; a value that is too high will consume system resources unnecessarily.

AdditionalCriticalWorkerThreads

Windows Server 2003 Service Pack 1 and Service Pack 2 denial of service checking should be disabled. This is because under certain high-load scenarios, Windows Server 2003 SP1 and SP2 denial of service checking may incorrectly identify valid TCP/IP connections as a denial of service attack.

Important
Only disable this feature in an intranet scenario when you are sure you will not suffer from actual denial of service attacks.

For more information about disabling Windows Server Denial of Service Checking, see Microsoft Knowledge Base article 889599, "A BizTalk Server Host instance fails, and a 'General Network' error is written to the Application log when the BizTalk Server-based server processes a high volume of documents" at http://support.microsoft.com/kb/899599. Follow the instructions in this article to create the SynAttackProtect registry entry on computers running SQL Server that host BizTalk Server databases and on any computers running BizTalk Server running Windows Server 2003 SP1 or later.

Registry settings that govern the level of denial of service attack protection - In certain scenarios you may want to maintain denial of service protection but reduce how aggressively the denial of service functionality is applied. It is possible to tune the default behavior of the denial of service protection feature by following these steps:

1. Ensure the SynAttackProtect registry entry is set to a REG_DWORD value of 1 as described at http://go.microsoft.com/fwlink/?LinkId=111477.
   
2. Configure the TcpMaxHalfOpen registry entry as described at http://go.microsoft.com/fwlink/?LinkId=111478.
   
3. Configure the TcpMaxHalfOpenRetried registry entry as described at http://go.microsoft.com/fwlink/?LinkId=111479.
   

Computers running Windows XP with Service Pack 1 (SP1) and higher, and Computers running Windows Server 2003 SP3 and higher provide the ability to enforce LDAP client signing requirements to mitigate “man in the middle” attacks where an intruder captures packets between a client and a server, modifies them, and then forwards them to the server. When this occurs on an LDAP server, an attacker could cause a server to respond based on false queries from the LDAP client. Such “man-in-the-middle” attacks can be mitigated by requiring digital signatures on all network packets by means of IPSec authentication headers. Computers in a secure intranet environment should disable this option to reduce the overhead associated with LDAP client signing. You can modify this setting on computers running Windows Server 2003 SP3 and higher by changing the following registry entry from a REG_DWORD value of 1 to a REG_DWORD value of 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\ldapclientintegrity = REG_DWORD 0x0

Add the NtfsMftZoneReservation entry to the registry to allow the master file table (MFT) to grow optimally. When you add this entry to the registry, the system reserves space on the volume for the master file table. If your NTFS volumes contain relatively few large files, set the value of this registry entry to 1 (the default). Typically you can set this entry to a value of 2 or 3 for volumes that contain a moderate numbers of files, and use a value of 4 (the maximum) if your volumes tend to contain a relatively large number of files.

Important
Test any settings greater than 2, because setting this entry to a value greater than 2 will cause the system to reserve a much larger portion of the disk for the master file table.

NtfsMftZoneReservation

The maximum number of concurrent outstanding network requests between a Windows Server Message Block (SMB) client and server is determined when a session between the client and server is negotiated. The maximum value negotiated is determined by registry settings on both the client and server. If these values are set too low on the server, they can restrict the number of client sessions that can be established with the server.
The values that can be adjusted to improve system performance for work items exist in the LanmanServer and LanmanWorkstation registry keys and are:

• MaxWorkItems
  
• MaxMpxCt
  
• MaxCmds
  

Note
These values do not exist in the registry by default.

The MaxWorkItems value specifies the maximum number of receive buffers, or work items, the Server service is permitted to allocate at one time. If this limit is reached, then the transport must initiate flow control, which can significantly reduce performance.

MaxWorkItems

Key:	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value:	MaxWorkItems
Data Type:	REG_DWORD
Range:	0 – 65535
Default value:	Configured dynamically
Recommended value:	8192 Note The MaxWorkItems value must be at least four times as large as the MaxMpxCt value.
Value exists by default?	No, needs to be added.

The MaxMpxCt value enforces the maximum number of simultaneous outstanding requests from a particular client to a server. During negotiation of a Server Message Block between the client and the server, this value is passed to the client's redirector where the limit on outstanding requests is enforced. A higher value can increase server performance but requires more use of server work items (MaxWorkItems).

MaxMpxCt

Key:	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value:	MaxMpxCt
Data Type:	REG_DWORD
Range:	0 – 65535
Default value:	50
Recommended value:	2048 Note The MaxWorkItems value must be at least four times as large as the MaxMpxCt value.
Value exists by default?	No, needs to be added.

The MaxCmds value specifies the maximum number of network control blocks the redirector can reserve. The value of this entry coincides with the number of execution threads that can be outstanding simultaneously. Increasing this value will improve network throughput, especially if you are running applications that perform more than 15 operations simultaneously. This value is set on the SMB client computer.

MaxCmds

Note
Start with the default or recommended values for these registry keys, and increase the value in small increments as needed. The more outstanding connections that exist, the more memory resources will be used by the server. If you set the values too high, the server could run out of resources such as paged pool memory.

For more information about setting these values, see Microsoft Knowledge Base article “How to troubleshoot Event ID 2021 and Event ID 2022” at http://support.microsoft.com/kb/317249 and see Microsoft Knowledge Base article "The network BIOS command limit has been reached" error message in Windows Server 2003, in Windows XP, and in Windows 2000 Server available at http://support.microsoft.com/kb/810886.

When a long file name is created using the Windows NTFS file system, the default behavior is to generate a corresponding short file name in the older 8.3 DOS file name convention for compatibility with older operating systems. This functionality can be disabled through a registry entry, offering a performance increase.

Caution
Before disabling short name generation, ensure there are no DOS or 16-bit applications running on the server that require 8.3 file names.

NTFSDisable8dot3NameCreation

In Windows Server 2003, this value can be set by using the following command:

fsutil behavior set disable8dot3 1

If Windows Server is configured to optimize data throughput for network applications, the working set of BizTalk Server and other applications will have a priority over the working set of the file system cache. This setting is normally the best setting to use for all servers except dedicated file servers or with applications exhibiting file server-like characteristics.
To optimize data throughput for network applications follow these steps:

1. In Windows Explorer, right-click My Network Places, and then click Properties.
   
2. Right-click the Local Area Connection you want to optimize, and then click Properties.
   
3. In the This connection uses the following items list, click (but do not clear its check box) File and Printer Sharing for Microsoft Networks, and then click Properties.
   
4. Click Maximize data throughput for network applications, click OK, and then click Close.
   

Optimize data throughput for network applications can also be applied by setting the following registry entries to the recommended values:

Size

LargeSystemCache

The driver verifier at random intervals verifies drivers for debugging. Disabling this functionality might improve system performance. For many high-throughput systems, every CPU cycle counts. Disable random driver verification with the following registry entry:

DontVerifyRandomDrivers

Each file and folder on an NTFS volume includes an attribute called Last Access Time. This attribute shows when the file or folder was last accessed, such as when a user performs a folder listing, adds files to a folder, reads a file, or makes changes to a file. Maintaining this information creates performance overhead for the file system especially in environments where a large number of files and directories are accessed quickly and in a short period of time, for example when using the BizTalk File Adapter. Apart from in highly secure environments, retaining this information might add a burden to a server that can be avoided by updating the following registry key:

NTFSDisableLastAccessUpdate

In Windows Server 2003, this value can be set by using the following command:

fsutil behavior set disablelastaccess 1

For more information about disabling NTFS last access update, see the Windows Server 2003 Deployment Guide at http://go.microsoft.com/fwlink/?LinkID=111188