Optimizing Performance by Server Roles

In addition to monitoring the common set of bottlenecks (memory, processor, disk subsystem, and network subsystem), the functional roles of the server influence what other counters you should monitor. The following sections outline some of the most common roles for Windows Server 2003 that also require the use of additional performance counters.

Terminal Services Server

Terminal Server has its own performance objects for the Performance Console called the Terminal Services Session and Terminal Services objects. It provides resource statistics such as errors, cache activity, network traffic from Terminal Server, and other session-specific activity. Many of these counters are similar to those found in the Process object. Some examples include % Privileged Time, % Processor Time, % User Time, Working Set, Working Set Peak, and so on.

Note

You can find more information on Terminal Services in Chapter 27, "Windows Server 2003 Terminal Services."

Three important areas to always monitor for Terminal Server capacity analysis are the memory, processor, and application processes for each session. Application processes are by far the hardest to monitor and control because of the extreme variances in programmatic behavior. For example, all applications may be 32-bit, but some may not be certified to run on Windows Server 2003. You may also have in-house applications running on Terminal Services that may be poorly designed or too resource intensive for the workloads they are performing.

Domain Controllers

A Windows Server 2003 domain controller (DC) houses the Active Directory (AD) and may have additional roles such as being responsible for one or more Flexible Single Master Operation (FSMO) roles (schema master, domain naming master, relative ID master, PDC Emulator, or infrastructure master) or a global catalog (GC) server. Also, depending on the size and design of the system, a DC may serve many other functional roles. In this section, AD, replication, and DNS monitoring will be explored.

Monitoring AD

Active Directory is the heart of Windows Server 2003 systems. It's used for many different facets, including, but not limited to, authentication, authorization, encryption, and Group Policies. Because AD plays a central role in a Windows Server 2003 network environment, it must perform its responsibilities as efficiently as possible. You can find more information on Windows Server 2003's AD in Chapter 4, "Active Directory Primer." Each facet by itself can be optimized, but this section focuses on the NTDS and Database objects.

The NTDS object provides various AD performance indicators and statistics that are useful for determining AD's workload capacity. Many of these counters can be used to determine current workloads and how these workloads may affect other system resources. There are relatively few counters in this object, so it's recommended that you monitor each one in addition to the common set of bottleneck objects. With this combination of counters, you can determine whether the system is overloaded.

Another performance object that you should use to monitor AD is the Database object. This object is not installed by default, so you must manually add it to be able to start gathering more information on AD.

To load the Database object, perform the following steps:

1.	Copy the performance DLL (esentprf.dll) located in %SystemRoot%\System32 to any directory (for example, c:\esent).
2.	Launch the Registry Editor (Regedt32.exe).
3.	Create the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ _Services\ESENT.
4.	Create the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ _Services\ESENT\Performance.
5.	Select the ESENT\Performance subkey.
6.	Create the value Open using data type REG_SZ and string equal to OpenPerformanceData.
7.	Create the value Collect using the data type REG_SZ and string equal to CollectPerformanceData.
8.	Create the value Close using the data type REG_SZ and string equal to ClosePerformanceData.
9.	Create the value Library using the data type REG_SZ and string equal to c:\esent\esentprf.dll.
10.	Exit the Registry Editor.
11.	Open a command prompt and change the directory to %SystemRoot%\System32.
12.	Run Lodctr.exe Esentprf.ini at the command prompt.

After you complete the Database object installation, you can execute the Performance Console and use the Database object to monitor AD. Some of the relevant counters contained within the Database object to monitor AD are described in Table 35.4.

Table 35.4. AD Performance Counters

Counter	Description
Database Cache % Hit	The percentage of page requests for the database file that were fulfilled by the database cache without causing a file operation. If this percentage is low (85% or lower), you may consider adding more memory.
Database Cache Page Fault Stalls/sec	The number of page faults per second that cannot be serviced because there are no pages available for allocation from the database cache. This number should be low if the system is configured with the proper amount of memory.
Database Cache Page Faults/sec	The number of page requests per second for the database file that require the database cache manager to allocate a new page from the database cache.
Database Cache Size	The amount of system memory used by the database cache manager to hold commonly used information from the database to prevent file operations.

Monitoring DNS

The domain name system (DNS) has been the primary name resolution mechanism in Windows 2000 and continues to be with Windows Server 2003. For more information on DNS, refer to Chapter 9, "The Domain Name System." There are numerous counters available for monitoring various aspects of DNS in Windows Server 2003. The most important categories in terms of capacity analysis are name resolution response times and workloads as well as replication performance.

The counters listed in Table 35.5 are used to compute name query traffic and the workload that the DNS server is servicing. These counters should be monitored along with the common set of bottlenecks to determine the system's health under various workload conditions. If users are noticing slower responses, you can compare the query workload usage growth with your performance information from memory, processor, disk subsystem, and network subsystem counters.

Table 35.5. Counters to Monitor DNS

Counter	Description
Dynamic Update Received/sec	Dynamic Update Received/sec is the average number of dynamic update requests received by the DNS server in each second.
Recursive Queries/sec	Recursive Queries/sec is the average number of recursive queries received by the DNS server in each second.
Recursive Query Failure/sec	Recursive Query Failure/sec is the average number of recursive query failures in each second.
Secure Update Received/sec	Secure Update Received/sec is the average number of secure update requests received by the DNS server in each second.
TCP Query Received/sec	TCP Query Received/sec is the average number of TCP queries received by the DNS server in each second.
TCP Response Sent/sec	TCP Response Sent/sec is the average number of TCP responses sent by the DNS server in each second.
Total Query Received/sec	Total Query Received/sec is the average number of queries received by the DNS server in each second.
Total Response Sent/sec	Total Response Sent/sec is the average number of responses sent by the DNS server in each second.
UDP Query Received/sec	UDP Query Received/sec is the average number of UDP queries received by the DNS server in each second.
UDP Response Sent/sec	UDP Response Sent/sec is the average number of UDP responses sent by the DNS server in each second.

Comparing results with other DNS servers in the environment can also help you to determine whether you should relinquish some of the name query responsibility to other DNS servers that are less busy.

Replication performance is another important aspect of DNS. Windows Server 2003 supports legacy DNS replication, also known as zone transfers, which populate information from the primary DNS to any secondary servers. There are two types of legacy DNS replication: incremental (propagating only changes to save bandwidth) and full (the entire zone file is replicated to secondary servers).

Full zone transfers (AXFR) occur on the initial transfers and then the incremental zone transfers (IXFR) are performed thereafter. The performance counters for both AXFR and IXFR (see Table 35.6) measure both requests and the successful transfers. It is important to note that if your network environment integrates DNS with non-Windows systems, it is recommended to have those systems support IXFR.

Table 35.6. DNS Zone Transfer Counters

Counter	Description
AXFR Request Received	Total number of full zone transfer requests received by the DNS Server service when operating as a master server for a zone.
AXFR Request Sent	Total number of full zone transfer requests sent by the DNS Server service when operating as a secondary server for a zone.
AXFR Response Received	Total number of full zone transfer requests received by the DNS Server service when operating as a secondary server for a zone.
AXFR Success Received	Total number of full zone transfers received by the DNS Server service when operating as a secondary server for a zone.
AXFR Success Sent	Total number of full zone transfers successfully sent by the DNS Server service when operating as a master server for a zone.
IXFR Request Received	Total number of incremental zone transfer requests received by the master DNS server.
IXFR Request Sent	Total number of incremental zone transfer requests sent by the secondary DNS server.
IXFR Response Received	Total number of incremental zone transfer responses received by the secondary DNS server.
IXFR Success Received	Total number of successful incremental zone transfers received by the secondary DNS server.
IXFR Success Sent	Total number of successful incremental zone transfers sent by the master DNS server.

If your network environment is fully Active Directoryintegrated, the counters listed in Table 35.6 will all be zero.

Monitoring AD Replication

Measuring AD replication performance is a complex process because of the many variables associated with replication. They include, but aren't limited to, the following:

• Intrasite versus intersite replication

• The compression being used (if any)

• Available bandwidth

• Inbound versus outbound replication traffic

Fortunately, there are performance counters for every possible AD replication scenario. These counters are located within the NTDS object and are prefixed by the primary process that is responsible for AD replicationthe Directory Replication Agent (DRA). Therefore, to monitor AD replication, you need to choose those counters beginning with DRA.