Monitoring the Microsoft Windows Server System with PATROL - a Best Practices Guide

Transcription

1 Monitoring the Microsoft Windows Server System with PATROL - a Best Practices Guide

2

3 Contents Introduction...1 Establishing a Baseline...1 The Operating System...1 CPU...2 Memory...4 Network...7 Disk...8 Server (Application Class = NT_SERVER)...11 System...11 Operating System Summary...12 Exchange...12 OS Parameters...13 Exchange Services...13 Exchange Processes...13 Events...14 Client Load...15 Client Perspective Availability...17 Data Access...18 Message Traffic...19 Exchange Connectors...21 Store...22 Monitoring Exchange in Summary...25 Active Directory...27 Operating System...27 Services and Processes...27 Events...29 Domain Level Services...32 FSMO Roles...33 Protocols...33 Replication...34 Monitoring Active Directory in Summary...36 Sources...38

4

5 Introduction While every Microsoft Windows environment is unique, there are certain practices that you can follow to ensure the overall availability of their Microsoft Windows Server System. A Windows environment can consist of many servers with each providing a different business critical application or service. Any application that affects the business should be monitored. This white paper discusses the critical components of a typical Windows environment, including the operating system, Active Directory, and Exchange. It will also show how to monitor these components with PATROL. Establishing a Baseline A baseline is a data set that indicates how system resources are being utilized. Once you establish a baseline, you can compare it with later system activity to help determine system usage and performance. PATROL products typically follow industry best practices for alarm threshold settings, every environment is unique, so a good baseline can help you ensure that these settings are appropriate for your environment. To create a Windows baseline, you should monitor these four basic server resources: memory processor disk network objects Over a several-day period, capture and save the history data from these parameters to determine what is normal for your system. You can do this offline by using the PATROL History Loader to archive PATROL history data to a database. If you need more information about establishing a baseline, refer to chapters 5 through 10 in the Microsoft Windows 2000 Resource Kit. The Operating System Begin by monitoring the Windows operating system (OS) itself. Without a healthy OS, no application will perform as expected. The following six operating systems categories will be discussed: CPU Memory Network Disk Server Page 1

6 System CPU The four most important PATROL parameters for can be found under the NT_CPU application class: CPUprcrInterruptsPerSec CPUprcrProcessorTimePercent CPUprcrPrivTimePercent CPUprcrUserTimePercent Interrupts per Second The CPUprcrInterruptsPerSec parameter monitors the number of device interrupts encountered by the processor per second. An interrupt occurs when a device completes a task or when it requires attention. Normal thread execution is suspended during interrupts. An interrupt may cause the processor to switch to another, higher priority thread. Under the _Total NT_CPU application class instance, this parameter shows the total number of interrupts per second for all processors on the computer, while each processor application class instance shows the number of interrupts for that processor. A high number of interrupts per second indicates that a hardware device is generating an excessive number of interrupts. The device causing the problem could be a video card, the network interface card (NIC), the hard disk driver, or the mouse. If the value of CPUprcrInterruptsPerSec is high, consider running a diagnostic test on your NIC to check for configuration and hardware errors. Most NIC manufacturers provide testing software with the card. If your keyboard or mouse appears to be behaving poorly, try replacing your keyboard or mouse to see if fewer interrupts occur. Processor Time Percent The CPUprcrProcessorTimePercent parameter monitors the percentage of time that a processor is busy executing the threads of a process. Threads are units of work that make up a process. Consistently high percentages (greater than 75%) indicate performance problems that can slow your system down. Temporarily high percentages (spikes) are normal. The _Total NT_CPU application class instance shows the total percentage of time that all processors are busy executing threads. Page 2

7 When in an alarm state, this parameter graph displays an annotation mark that shows you the names of the top 10 processes that are using the most CPU resources. If this parameter value is consistently greater than 75%, you should consider taking action to remedy the problem. Some actions you can take include: Reducing the workload of the CPU if possible - review the processes running on your system, and terminate unnecessary processes. Reviewing the processes listed in this parameter's graph annotation. You may find that processor cycles are being consumed by a poorly designed application that is not releasing system resources properly. In this case, you may need to contact the software vendor (or internal programmer) to update your version of the application. Upgrading to a multiprocessor system-if your problem stems from hardware resources, upgrading to a machine with more than one processor may solve the problem. Research possible hardware issues. There are several possibilities: If the CPUprcrTotalInterruptsPerSec (device interrupts to the processor) parameter's value is greater than the SYSsysSystemCallsPerSec (calls to system service routines) parameter's value, then a hardware device is probably generating excessive interrupts and degrading performance. Note that the SYSsysSystemCallsPerSec parameter is inactive by default, so if you have high interrupts, you should enable it using the Task => Show Parameter List menu command from the NT_SYSTEM application class in the PATROL Central Operator console. If the CPUprcrTotalInterruptsPerSec parameter's value is greater than 1,000, then an I/O device is probably generating these interrupts. If a disk controller that requires a large amount of physical I/O is consuming the processor cycles, install a DMA disk controller to reduce processor utilization. If a memory bottleneck exists, the increased paging activity may be taxing the processor and masking what is primarily a memory bottleneck instead of a processor bottleneck. Refer to the following NT_MEMORY parameter topics to help determine if you have a memory bottleneck: MEMmemAvailableBytes, MEMmemPageFaultsPerSec, and MEMmemPagesPerSec Privileged Time Percent The CPUprcrPrivTimePercent parameter monitors the percentage of processor time spent in privileged mode in non-idle threads. The following items run in privileged mode: Most device drivers (except those for graphics adapters and printers) Windows service layer Executive routines Windows kernel Page 3

8 Under the _Total NT_CPU application class instance, this parameter shows the total percentage of time spent in privileged mode for all processors. When this number is greater than SYSsysTotalUserTimePercent under the NT_SYSTEM application class, the system is spending more of its time processing operating system commands than application commands. Consider using the Microsoft Performance Monitor Process object to find out which processes are using the most privileged time. Terminate services that are not in use but are consuming privileged time. User Time Percent The CPUprcrUserTimePercent parameter monitors the percentage of CPU time currently spent in User Mode doing commands and tasks initiated by users. All application code and subsystem code executes in User Mode. This value helps identify how much time a particular process spends executing in User versus Privileged Mode. Under the _Total NT_CPU application class instance, this parameter shows the total percentage of time spent in User Mode for all processors. When the total system user time percentage is lower than the system privileged time percentage, the system is spending more of its time processing operating system commands than application commands. Consider using the Microsoft Performance Monitor's Process object to find out which processes are using the most privileged time. Terminate services that are not in use but are consuming privileged time. Memory Memory plays a key part in server availability. Applications and users will consume memory and sometimes make a server sluggish. A popular approach to solving a memory shortage is upgrading the amount of memory in the server. Alternatively, you can monitor memory usage to help isolate fixable issues. Consider these three application classes: NT_MEMORY NT_CACHE NT_PAGEFILE The value of monitoring each class is explained in detail in the subsequent paragraphs. Key Memory Parameters There are five parameters under the NT_MEMORY application class that can help you understand memory utilization. MEMmemAvailableBytes Page 4

9 MEMmemCacheFaultsPerSec MEMmemPageFaultsPerSec MEMmemPagesInputPerSec MEMmemPagesPerSec The MEMmemAvailableBytes parameter monitors the number of megabytes of physical memory currently available to processes, but it is not related to the amount of physical memory installed on your server. The value of the MEMmemAvailableBytes parameter is calculated by adding the space on the Zeroed, Free, and Standby memory lists. Zeroed memory is filled with zeros to prevent later processes from seeing data used by a previous process. Free memory is ready for use by any process. Standby memory has been removed from a process' working set on route to disk but is still available for recall. The value for this parameter should never drop to less than 4 MB, even during peak usage times, and should be 10 MB or more: If the value is less than 10 megabytes, reorganize your page file by increasing its size and changing or splitting its location on to different physical drives. If the value is less than 4 megabytes, add more physical memory to your computer. The MEMmemCacheFaultsPerSec parameter monitors the frequency of cache faults. Cache faults occur whenever the cache manager does not find a file's page in the immediate cache. The MEMmemPageFaultsPerSec parameter monitors the number of hard and soft page faults in the processor. Page faults are normal for processors and do not necessarily imply a performance bottleneck. There are two kinds of page faults: soft page faults occur when the processor needs a memory page that is not in the current working set but is still in the standby list in main memory. hard page faults occur when the processor needs a memory page that is no longer in the standby list in memory and must read the page from disk. A soft page fault can be resolved without accessing a disk drive. A hard page fault must be resolved by physically accessing a disk drive. Add memory if: The ratio of hard page faults to total page faults is greater than 0.05 to If the ratio is higher than this value, the system is spending too much time on paging activity, and you should consider installing additional memory. If MEMmemPagesPerSec is greater than 10 and MEMmemPageFaultsPerSec is greater than MEMmemCacheFaultsPerSec,the system is paging too much, and you should install additional memory. Alternatives to adding memory include: Schedule memory intensive applications to run during off-peak hours. Page 5

10 Spread the paging file across multiple hard disks and remove the paging file on the disk where the Windows system is located. Note: You can use composite parameters to monitor the relationship between MEMmem- PagesPerSec, MEMmemPageFaultsPerSec and MEMmemCacheFaultsPerSec. Composite parameters can be created directly from the NT_COMPOSITES application class. There is a wizard that will guide you through the creation of a custom KM that will compare two or more parameters. The MEMmemPagesInputPerSec parameter monitors the number of pages read from the disk to resolve memory references to pages that were not in memory at the time of the reference. This parameter also includes paging activity incurred by the system cache accessing file data for applications. The ratio of hard page faults to total page faults (that is, MEMmemPagesInputPerSec / MEMmemPageFaultsPerSec), should not be greater than If the ratio is higher than this, the system is spending too much time on paging activity, consider installing additional memory resources. The same alternatives to adding memory apply here as well. MEMmemPagesPerSec monitors the number of hard page faults for the processor, and the value often determines whether or not your system needs more RAM. If MEMmemPagesPerSec is consistently greater than 5, you probably have a memory bottleneck, and you may want to install additional memory. If MEMmemPagesPerSec is consistently greater than 10 to 12 and MEMmemPageFaultsPerSec is greater than MEMmemCacheFaultsPerSec, the system is paging too much and you should consider installing additional memory and increasing the size of the paging file system. Key Cache Parameters The NT_CACHE application class contains parameters for measuring memory consumption. Two parameters provide you with valuable memory statistics: CACcachCopyReadHitsPercent CACcachCopyReadsPerSec The CACcachCopyReadHitsPercent parameter monitors the percentage of cache copy read requests. A copy read is a file read operation that is satisfied by a memory copy from a cache page to the application's buffer. A CACcachCopyReadHitsPercent value greater Page 6

11 than 80 percent is excellent. If CACcachCopyReadHitsPercent decreases in value about 10 percent while CACcachCopyReadsPerSec remains relatively flat, there is an overall memory shortage. Consider adding physical memory. The CACcachCopyReadsPerSec parameter monitors the frequency of reads from cache pages that involve a memory copy of the data from the cache to the application's buffer. If CACcachCopyReadHitsPercent decreases in value about 10 percent while CACcach- CopyReadsPerSec remains relatively flat, there is an overall memory shortage. Consider adding physical memory. Key Pagefile Parameters The NT_PAGEFILE application class offers additional parameters that should be monitored. The PAGEpgUsagePercent parameter monitors the percentage of the page file currently in use. When page file usage exceeds 90 percent, Windows increases the size of the page file dynamically. This causes two performance-degrading events: Server performance is impacted by the dynamic update. The increase in page file size occurs in non-contiguous file space. When the page file is initially created, the file is a single contiguous block of disk space that can be efficiently written and read. The paging file should be maintained to minimize the need to dynamically change the file. In order to avoid these two events you can tune the server's paging configuration. When the page file system usage exceeds 80 percent, increase the page file size as part of your routine maintenance program in order to create contiguous file space allocation and avoid dynamic allocation. If paging is less that 20 percent, the system has an extremely large page file, and has a large amount of memory, then consider freeing the excess disk space by decreasing the size of the page file. Network Network-related issues should be monitored along with core components. As more and more users or applications leverage a server for the application or service it provides, network-related problems will occur. The NT_NETWORK application class includes three important parameters to isolate network issues: NETniBytesTotalPerSec NETniOutputQueueLength NETniPcktsPerSec Page 7

12 The NETniBytesTotalPerSec parameter monitors the rate that bytes are sent and received on the interface; this rate includes framing characters. The packet size is NETniBytesTotalPerSec/NETniPcktsPerSec. If the packet size drops, collisions are probably occurring and network efficiency is decreasing. The collisions may be caused by a large number of users in a poorly configured network, or by a defective network card (NIC) that is sending excessive messages. Consider running a diagnostic test on your NIC to check for configuration or hardware errors. Most NIC manufacturers provide a diskette that contains testing software. The NETniOutputQueueLength parameter monitors the length (in packets) of the output packet queue and can indicate network bottlenecks. If this parameter's value is consistently greater than two, then the local NIC may be malfunctioning, or the network is experiencing a collision condition that is decreasing network efficiency. These collisions may also be caused by having a large number of users on a poorly configured network or by a defective network card or printer that is sending excessive messages. The NETniPcktsPerSec parameter monitors the rate that packets are sent and received on the network. The packet size is NETniBytesTotalPerSec/NETniPcktsPerSec. If the packet size drops, collisions are probably occurring and network efficiency is decreasing. The collisions may be caused by a large number of users in a poorly configured network, or by a defective NIC that is sending excessive messages. Disk One of the key resources that affect a server's availability is the disk in use. At a very high level disk activity can be attributed to users and applications. Disk activity should be measured to determine if there are potential problems with the disk, or if there are potential problems in other areas of the OS. PATROL includes two application classes that can help solidify answers to disk related problems: NT_LOGICAL_DISKS NT_PHYSICAL_DISKS Logical Disks Under the NT_LOGICAL_DISKS application class, four critical parameters are included: LdldDiskQueueLength LdldDiskTimePercent LdldFreeMegabytes LdldFreeSpacePercent Page 8

13 The LdldDiskQueueLength parameter monitors the number of requests outstanding on the disk, including requests currently in service. This is an instantaneous value at the time the data was collected. If the number displayed is consistently high, there is a sustained load on your disk drive. If this number, minus the number of disk spindles, averages greater than 2, there may be a disk-related bottleneck. If one drive is more heavily loaded than another, you may want to move some of the most used files to other disks to distribute the load more evenly. The LdldDiskTimePercent parameter monitors the percentage of elapsed time that the selected disk drive is busy servicing read or write requests. If you have multiple disks in your system, you may want to check this parameter for each volume of a server to see how the load is distributed across the system. If one drive has a considerably larger load, you may want to move some of the files to other disks in the system to distribute the load across disks. You should investigate any major swing in utilization, as it can reveal problems. PATROL initiates an alarm if this parameter is between 69 and 100 percent. The LdldFreeMegabytes parameter monitors the amount of unused space on the disk drive in megabytes (MB). Applications that write to drives with limited space can cause operating system stress and possible failures. For drives larger than 1 GB: If this parameter falls below the number of megabytes that you have chosen for your system, free up some disk space. To provide free disk space: Delete or move duplicate or unneeded files from the drive. Consider archiving the data before taking these actions. Back up the files on the drive, replace the drive with a larger capacity drive, and restore the files to the new drive. For drives that are 1 gigabyte (GB) or smaller: Consider using the LDldFreeSpacePercent (percentage of free space on the logical disk) parameter rather than LdldFreeMegabytes. The LdldFreeSpacePercent parameter notifies you when its value falls below 10 percent (warning) and 5 percent (alarm). LdldFreeSpacePercent monitors the percentage of free space available on the selected logical disk drive. Applications that write to drives with limited space can cause operating system stress and possible failures. This parameter contains a recovery action that automatically clears the temporary directory when LdldFreeSpacePercent enters an alarm state. The same recommendations for LdldFreeMegabytes apply here. Page 9

14 Physical Disks Included with the NT_PHYSICAL_DISKS application class are two parameters that compliment the logical disks parameters in monitoring disk activity and usage: PdpdDiskQueueLength PDpdDiskTimePercent The PdpdDiskQueueLength parameter monitors the number of requests outstanding on the disk at the time the performance data is collected. If this parameter consistently has a value greater than 2, you should consider replacing the disk drive and/or the disk controller with faster versions. Before you upgrade the disk system however, make sure that you do not have a memory bottleneck, since excessive paging activity that is caused by insufficient memory can appear as a disk bottleneck. Verify that the paging parameters have low values relative to the total disk activity to help you decide if you have a disk bottleneck. Refer to the following parameters to help identify memory bottlenecks: MEMmemCacheFaultsPerSec MEMmemPageFaultsPerSec MEMmemPagesInputPerSec MEMmemPagesPerSec The PDpdDiskTimePercent parameter monitors the percentage of elapsed time that the disk spends servicing read or write requests. Good disk performance enhances virtual memory performance and reduces the elapsed time required to load programs that perform a large number of I/O requests. Disk performance may be impacted by a shortage of physical memory. If the PDpdDiskTimePercent parameter is greater than 60 percent or the PdpdDiskQueue- Length parameter is greater than 2, then physical disk congestion is adversely affecting your system's performance. To fix the situation, consider one or more of the following actions: Install a faster disk and controller. Distribute the workload as evenly as possible among different disk drives. Use the NTFS file system. NTFS is more efficient for large disks (400 MB or more). Create mirrored data sets. Create striped data sets. Disable short name generation on the NTFS file system. To determine if a memory shortage is impacting disk performance, calculate the portion of the disk I/O used for paging with the following formula: Page 10

15 % disk time used for paging = 100 * (MEMmemPagesPerSec * 'PhysicalDisk Avg,DiskSec/Transfer') MEMmemPagesPerSec is the number of hard page faults. PhysicalDisk Avg,DiskSec/Transfer is the time in seconds of the average disk transfer. You can add this parameter to PATROL using the PATROL Performance Monitor Wizard. You can also find this value using Windows Performance Monitor. If this value is greater than 10 percent of the total disk activity, then paging is considered excessive. If this value is less than 10 percent of the total disk activity, consider adding more physical memory and increasing the paging file size. Server (Application Class = NT_SERVER) The NT_SERVER application class monitors statistics related to network and shows the workload that the server is experiencing. The SVRsvrBytesTotalPerSec parameter indicates the number of bytes that the server has sent to and received from the network. This value provides an overall indication of server workload. If this number is consistently at or above 50 percent of the network capacity, you may need to put the server on a faster switch or hub. You can also add a second network interface card (NIC) to the server and build a subnetwork using the routing capability in Windows NT. System The NT_SYSTEM application class provides information about the state of objects in a Windows system. The application class also provides information about the number of processes interrupts amount of CPU utilization. This application class also provides you with an overall workload metric experienced by the server. The SYSsysProcessorQueueLength parameter monitors the length of the processor queue in number of threads. If the queue length is consistently greater than 2, the processor is probably congested. Consider adding processors to the system or upgrading to a machine with faster processors. If the queue length is consistently between four and eight, check the CPUprcrProcessorTimePercent parameter to see if processor utilization is consistently at 100 percent, which may indicate a poorly-behaved process that is not releasing system resources properly. Page 11

16 Operating System Summary System Resource Parameters CPU Memory Network Disks Server System NT_CPU\CPUprcrInterruptsPerSec NT_CPU\CPUprcrPrivTimePercent NT_CPU\CPUprcrProcessorTimePercent NT_CPU\CPUprcrUserTimePercent NT_MEMORY\MEMmemAvailableBytes NT_MEMORY\MEMmemAvailableBytes NT_MEMORY\MEMmemCacheFaultsPerSec NT_MEMORY\MEMmemPageFaultsPerSec NT_MEMORY\MEMmemPagesInputPerSec NT_MEMORY\MEMmemPagesPerSec NT_CACHE\CACcachCopyReadHitsPercent NT_CACHE\CACcachCopyReadsPerSec NT_PAGEFILE\PAGEpgUsagePercent NT_NETWORK\NETniBytesTotalPerSec NT_NETWORK\NETniOutputQueueLength NT_NETWORK\NETniPcktsPerSec NT_LOGICAL_DISKS\LdldDiskQueueLength NT_LOGICAL_DISKS\LdldDiskTimePercent NT_LOGICAL_DISKS\LdldFreeMegabytes NT_LOGICAL_DISKS\LdldFreeSpacePercent NT_PYSICAL_DISKS\PDpdDiskQueueLength NT_PYSICAL_DISKS\PDpdDiskTimePercent NT_SERVER\SVRsvrBytesTotalPerSec NT_SYSTEM\SYSsysProcessorQueueLength Exchange When monitoring Exchange it is important to look at the key areas of the application that affect availability. No one single service or area of Exchange should be ignored, as they all relate directly or indirectly to each other. The major areas to look at are: OS Parameters (CPU, Memory, Disk, Network) Exchange Services Exchange Processes Events Client Load Client Perspective Availability Data Access Message Traffic (Connectors, Queues) Store Page 12

17 OS Parameters Begin by monitoring the Windows operating system (OS) itself. The performance and availability of applications and databases are intimately tied to the operating systems that they run on; without a healthy OS, no application (ie: Exchange) will perform as expected. Use the previous part of this paper as a guide to monitoring the base operating system. Exchange Services Services are application types that run in the system background. Services provide core operating system features, such as Web serving, event logging, file serving, help and support, printing, cryptography, and error reporting. To provide core system features to its users, Exchange provides a number of services that run on an Exchange server. Of these services, the following components should be monitored: Microsoft Exchange Information Store Microsoft Exchange MTA Stacks Microsoft Exchange Routing Engine Microsoft Exchange System Attendant Simple Mail Transport Protocol World Wide Web Publishing The NT KM provides a number of parameters that give the status of all of these services. The two most important parameters to monitor are ServiceStatus and SvcDown. The ServiceStatus parameter indicates whether or not the Exchange services have been started and whether or not clients can make connections. The SvcDown parameter indicates the opposite. The NT KM monitors all services out of the box so there is little configuration necessary to achieve service monitoring. If any of the Exchange services enters a down state, it can be detrimental to your mail flow and your organization. Exchange Processes In addition to service monitoring, you should also monitor the processes that run on behalf of an application. Exchange has critical processes that should be watched to determine their availability and resource usage. Exchange processes include the following Store.exe (Information Store Service) Inetinfo.exe (IIS, Routing Engine) Mad.exe (System Attendant) Emsmta.exe (MTA Stacks Service) Windows Memory Handler System Process Page 13

18 Measure the percentage of processor time used to monitor for excessive processor usage and overall process status. Use the Process KM, which is part of the NT KM. The two most important parameters to look at are: PROCDown PROCProcessorTimePercent The PROCDown parameter indicates that a process is down. In monitoring the processor time percentage of a parameter, you can determine if a process is using too much processor time. Inetinfo.exe, store.exe, emsmta.exe and system.exe normally consume 90 percent of the processor time combined. In addition to processor time, the working set used by each process should be monitored. The working set is the set of memory pages touched recently by the threads in the process. This will give you an indication of memory usage per process. The PROCWorkingSet parameter can be found in the NT_PROCESS application class. Store.exe will consume most of the committed bytes due to the Exchange store maintaining a large cache. When used with PATROL KM for Microsoft Windows Operating System (the OS KM), PATROL for Microsoft Exchange Servers automatically monitors Exchange Server processes that are initiated at startup. You can also configure PATROL to monitor additional Exchange Server processes. Events Events can be monitored by configuring the NT_EVENTLOG application class. Exchange writes information and errors to the Windows Event Log. When troubleshooting a problematic server, this is often the first place to look. If your event log is not free from errors and potentially escalating warnings, users will suffer. With the OS KM, you can select specific IDs directly from a Windows Event Viewer and launch them from the console. Store errors and warnings should be monitored closely, as they will cause the most problems with Exchange. Store errors that are not resolved affect access and present the impression that your servers are unavailable. Any errors indicating a failure to access a Global Catalog (GC) by the store or a domain controller by the MTA should be monitored as well. Failure to access a GC will cause the store to dismount. Failure to access a domain controller will cause the MTA to shutdown. Monitoring all critical Exchange events ensures that your Exchange server is functioning properly. To monitor these events, use the Event Log KM found in the OS KM. The following services write events to the Application event log: IMAP4Svc (IMAP4 Protocol) Page 14

19 MS-ExhangeAL (Address List) MSExchangeIS\System (Information Store System) MSExchangeIS\Mailbox (Information Store Mailbox) MSExchangeIS\Public Folder (Information Store Public Folders) MSExchangeSRS (Site Replication Service) MSExchangeTransport (SMTP Routing Engine and Transport) MSExchangeMTA (MTA Service) MSExchangeSA (System Attendant Service) POP3SVC (POP3 Protocol) Aside from watching for errors generated by the above sources, server availability can also be assessed by looking for key events: Event ID 6005: This is a startup event indicating the time the operating system became available to Exchange. Event ID 6006: This event indicates the time the system became unavailable to Exchange due to a shutdown. Event ID 6008: This event is written upon restart if the server was not shutdown properly. Event ID=9582: The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue. Client Load PATROL gives you the ability to monitor client-level resource usage. Monitoring from the client perspective is unique because it gives you information about the user's experience. The following Exchange statistics can be monitored to determine client usage: client load top mail senders and mail receivers top mailbox users and public folders Monitoring the top senders allows you to determine the top senders either by the number of messages sent or the total size of the messages sent. Message tracking must be enabled to use this functionality. Under the MSEXCH_Top_Senders application class, you can monitor these three parameters: MsgSize MsgCount AvgMsgsPerHour Page 15

20 You can also monitor the top receivers. The MsgSize, MsgCount, and AvgMsgsPerHour parameters can also be found in the MSEXCH_Top_Receivers application class. Message tracking must also be enabled to use this functionality. Top mailbox users can be monitored with the MSEXCH_Top_Mailboxes application class. The Top Mailboxes application class monitors the top resource-consuming private folders (mailboxes) with these two parameters: MsgCount: number of messages MsgSize: size of messages Monitoring the Public folders should be considered a best practice approach to monitoring Exchange at the client level. Clients will update and add data to public folders; therefore, this is a natural progression in a monitoring plan. These top public folders can be monitored with the MSEXCH_Top_Folders application class, and the MsgCount and MsgSize parameters. Both application classes should be monitored. You can configure the Exchange KM to perform recovery actions such as automatically notifying the top senders, receivers, or mailbox users of their usage. You can also specify whether to use the number of messages or the total message size to determine the top senders, receivers, mailboxes, and folders. PATROL also lets you monitor specified users. You can use the MSEXCH_Watched_Users application class to monitor the following statistics for specified Exchange users: message send and receive rate Internet messages sent and received whether the client is over the send or receive limits An administrator can better understand the amount of storage that a user is consuming and better allocate storage resources by gathering these statistics. For example, the CEO of the company may require a larger storage capacity than a regular employee. Conversely, some employees' storage needs may be less than what they have allocated. Knowing this allows the administrator to free up storage space for those who require it, rather than purchasing more storage capacity. Additionally, understanding storage consumption may help prevent storage abuse by individual users. If the administrator understands the amount of network bandwidth that is consumed by individual users, then he or she can help prevent or alleviate network problems. For example, the administrator can move the mailboxes of those using the most bandwidth onto an Exchange server that is connected to a higher capacity WAN or LAN that will not be as affected by the amount of that the user is sending. By tracking the activity of each user, an administrator can also Page 16