Performance Tuning your Windows Server (Part 3)

This is the 3rd part of a series of posts I’ll be describing several settings and parameters that can be tuned to optimize your server performance. I hope you’ll find them useful and help you improve your servers performance.

• Performance Tuning your Windows Server (Part 1)
• Performance Tuning your Windows Server (Part 2)
• Performance Tuning your Windows Server (Part 4)

Note: As with all changes, you should implement the following suggestions one at a time and verify that there was a performance improvement. If system performance decreases after making a change, you should reverse the change.

 

Registry optimizations

Note that several of the memory specific tuning parameters listed here hold relevance only for the 32-bit (x86) versions of the Windows Server 2003 operating system. They are no longer valid for the 64-bit (x64) editions given the greatly expanded memory architecture.

 

As with all changes, ensure you have a working and tested backup of the registry and entire server before making the change. Changes should be made and tested only one at a time. If system performance is negatively affected by making such a change, it should be reversed immediately.

 

Memory registry optimizations:

AdditionalDelayedWorkerThreads

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.

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Executive
Value:	AdditionalDelayedWorkerThreads
Recommended value:	0x10 (16)

 

AdditionalCriticalWorkerThreads

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Executive
Value:	AdditionalCriticalWorkerThreads
Recommended value:	0x10 (16)

 

PagedPoolSize

Windows allocates memory in pools for the operating system and its components, which processes access through the use of kernel mode. Two pools of kernel mode memory exist: The paged pool (which can be paged to the pagefile) and the non-paged pool (which can never be paged).

Performance and system stability can be seriously impacted if Windows experiences memory resource constraints and is unable to assign memory to these pools. The amount of physical memory assigned to these two pools is assigned dynamically at system boot time.

Some applications and workloads can demand more pooled memory than the system has been allocated by default. Setting the PagedPoolSize registry value as listed below can assist in ensuring sufficient pooled memory is available.

Key:	HKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement
Value:	PagedPoolSize
Recommended value:	0xFFFFFFFF

With this value, Windows will calculate the maximum paged pool allowed for the system. For 32-bit systems, this is 491 MB. This setting is typically used for servers that are attempting to cache a very large number of frequently used small files, some number of very large size files, or both. In these cases, the file cache that relies on the paged pool to manage its caching it able to cache more files (and for longer periods of time) if more paged pool is available.

Caution: The 0xFFFFFFFF PagedPoolSize setting is not recommended for use on 32-bit Windows Server 2003-based computers that have 64GB of RAM. This will potentially bring the Free System PTE entry down and can cause continuous reboot of the computer.

 

PoolUsageMaximum

By default, the Memory Manager tries to trim allocated paged pool memory when the system reaches 80 percent of the total paged pool. By tuning the Memory Manager to start the trimming process earlier, it would be possible to keep up with the paged pool demand during sudden peak usage, and avoid running out of paged pool memory.

Key:	HKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement
Value:	PoolUsageMaximum
Recommended value:	0x3C (60)

Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent.

 

SystemPages

SystemPages defines the number of system page table entries (PTEs) that are reserved for mapping I/O buffers and other information into the system address space. Each system page table entry maps one page.

Key:	HKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement
Value:	SystemPages
Recommended value:	0x0

Setting the value at 0 informs the Memory Manager to calculate an optimal number of page table entries based on the platform type and the amount of memory available to the system. The system adjusts this value if the amount of memory changes.

 

DontVerifyRandomDrivers

The driver verifier at random intervals verifies drivers for debugging randomly. Disabling this functionality might improve system performance.

Key:	HKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement
Value:	DontVerifyRandomDrivers
Recommended value:	0x1

 

 

File system registry optimizations

NtfsMftZoneReservation

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
Value:	NtfsMftZoneReservation
Recommended value:	1 if volumes typically store fewer files. 2 or 3 if volumes typically store a moderate number of files. 4 if volumes typically store a 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.

 

MaxWorkItems, MaxMpxCt, MaxCmds

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 and MaxCmds

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value:	MaxWorkItems
Recommended value:	8192 Note: The MaxWorkItems value must be at least four times as large as the MaxMpxCt value

 

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).

Key:	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value:	MaxMpxCt
Recommended value:	2048 Note: The MaxWorkItems value must be at least four times as large as the MaxMpxCt value.

 

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Value:	MaxCmds
Recommended value:	2048

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.

 

NTFSDisable8dot3NameCreation

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.

Key:	HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
Value:	NTFSDisable8dot3NameCreation
Recommended value:	1

 

NTFSDisableLastAccessUpdate

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:

Key:	HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
Value:	NTFSDisableLastAccessUpdate
Recommended value:	1

 

Maximize data throughput for network applications

If Windows Server is configured to optimize data throughput for network applications, the working set 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 set the following registry entries:

Key:	HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
Value:	Size
Recommended value:	3

Key:	HKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement
Value:	LargeSystemCache
Recommended value:	0

 

Related reading:

• Pushing the Limits of Windows: Paged and Nonpaged Pool
• Server is unable to allocate memory from the system paged pool
• About Cache Manager in Windows Server 2003

Advertisements

Performance Tuning your Windows Server (Part 2)

This is the 2nd part of a series of posts I’ll be describing several settings and parameters that can be tuned to optimize your server performance. I hope you’ll find them useful and help you improve your servers performance.

• Performance Tuning your Windows Server (Part 1)
• Performance Tuning your Windows Server (Part 3)
• Performance Tuning your Windows Server (Part 4)

Note: As with all changes, you should implement the following suggestions one at a time and verify that there was a performance improvement. If system performance decreases after making a change, you should reverse the change.

 

Unnecessary Services

When Windows is first installed, many services are enabled that might not be necessary for a particular server. Each service requires system resources and as a result is best to disable unnecessary services to improve performance. All services that are not required to be running on the server should be stopped and disabled. This will prevent the service from automatically starting at system boot time.

Note: Unless you are completely certain of the purpose of a given service it is recommended to research it further before choosing to disable it.

For example, the Print Spooler service is enabled by default but is not usually required if the server is not functioning as a print server or does not have local printing requirements.

But don’t disable the Spooler on your Domain Controllers. Printers which are advertised in Active Directory are monitored periodically by the DCs which have the spooler service enabled and running that they actually exist on the associated print server(s). If and when printers are found which do not exist on a print server, the spooler service will remove the associated object from AD. Thus, if all spooler services (on DCs) are disabled, print queues advertised in AD will need to be manually managed. See http://support.microsoft.com/kb/246269/ for more details.

The table below lists a few services on a standard Windows Server 2003 installation that should be reviewed for their requirement on your systems.

Service	Default startup type	Recommended setting
Alerter	Automatic	Disabled
Computer Browser	Automatic	Disabled
Distributed file system	Automatic	Disabled
Error Reporting Service	Automatic	Disabled
Help and Support	Automatic	Disabled
Messenger	Automatic	Disabled
Windows Audio	Automatic	Disabled
Wireless Configuration	Automatic	Disabled

 

Boot.ini

The NTLDR (NT Loader) allows the user to choose which operating system to boot from at the menu; for NT and NT-based operating systems, it also allows the user to pass preconfigured options to the kernel. The menu options are stored in the boot.ini file. There are several switch options for the boot.ini file. I’ll describe 3 of them that have to do with memory management.

/3GB

By default, the 32-bit (x86) editions of Windows can address a total of 4 GB of virtual address space. This is a constraint of the 32-bit (x86) architecture. Normally, 2 GB of this is reserved for the operating system kernel requirements (privileged-mode) and the other 2 GB is reserved for application (user-mode) requirements. Under normal circumstances, this creates a 2 GB per-process address limitation.

Windows provides a /3GB parameter to be added to the BOOT.INI file that reallocates 3 GB of memory to be available for user-mode applications and reduces the amount of memory for the system kernel to 1 GB. Some applications, written to do so, can derive performance benefits from having large amounts of addressable memory available to individual user-mode processes. In such instances, having as much free space for user-mode processes is desirable.

You normally use this switch only when a specific application recommends its use, meaning the applications have been compiled to use more than 2 GB per process, such as Microsoft Exchange and Microsoft SQL Server.

 

/PAE

The Physical Address Extension (PAE) is a 36-bit memory addressing mode that allows 32-bit (x86) systems to address memory above 4 GB.

Windows uses 4 KB pages with PAE to map up to 64 GB of physical memory into a 32-bit (4 GB) virtual address space. The kernel creates a “map” in the privileged mode addressable memory space to manage the physical memory above 4 GB.

This allows the operating system to use physical memory above 4 GB. As the 64-bit (x64) editions of Windows are not bound by this same memory architecture constraint, the PAE switch is not used in these versions of the Windows Server.

Even with PAE enabled, the underlying architecture of the system is still based on 32-bit linear addresses. This effectively retains the usual 2 GB of application space per user-mode process and the 2 GB of kernel mode space because only 4 GB of addresses are available. However, multiple processes can immediately benefit from the increased amount of addressable memory because they are less likely to encounter physical memory restrictions and begin paging.

 

/USERVA=####

The /userva=#### switch is designed to allow for more precise tuning of User-mode address space for programs that require more than 2 GB of User-mode space but do not require all the space that is provided by the /3GB tuning switch alone. Using the /3GB switch reduces the memory available in the Nonpaged Pool, Paged Pool & System Page Table Entries (PTEs).

If the memory reduction in the pools is too great in a specific server installation, the server or the applications may generate an error or appear to stop responding.

Using the /userva switch you can add a small amount of the additional 1 GB back to the operating system by decreasing the amount of User-mode space that is typically allocated by the /3GB switch. This additional Kernel-mode address space is held in reserve and is used as additional address space for PTEs if the system runs out of free PTE space. This address space is not allocated to PTEs until the system runs low on PTE space.

Use /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB, with the difference (3,072 less ####) being returned to Kernel mode. Note that #### is expressed in megabytes (MB).

 

Related reading:

• How to use the /userva switch with the /3GB switch to tune the User-mode…
• Memory Management – Demystifying /3GB

Microsoft TechNet Desktop Player (Beta)

Microsoft recently launched a Desktop player that allows users to consume selected Microsoft content for IT professionals and developers based on your adoption lifecycle.

The Desktop Player filters content by topic based on your role and where you are in your adoption lifecycle (Evaluation, Development/Pilot, Support).

Find videos, webcasts, podcasts, whitepapers and relevant links based on your specific criteria. And get a feed of the latest news for IT pros.

From the EULA:

The Microsoft TechNet Desktop Player (the “PLAYER”) is a content aggregator that surfaces filtered content that exist at Microsoft across various engines that have relevant contextual content for the user.

Use it online or download from http://www.microsoft.com/click/desktopplayer/

Requirements: .NET Framework 3.5 SP1 installed for the offline version and Silverlight for the online version.

Performance Tuning your Windows Server (Part 1)

In this series of posts I’ll be describing several settings and parameters that can be tuned to optimize your server performance. I hope you’ll find them useful and help you improve your servers performance.

• Performance Tuning your Windows Server (Part 2)
• Performance Tuning your Windows Server (Part 3)
• Performance Tuning your Windows Server (Part 4)

Note: As with all changes, you should implement the following suggestions one at a time and verify that there was a performance improvement. If system performance decreases after making a change, you should reverse the change.

 

Processor scheduling

Windows uses multitasking to prioritize process threads that the CPU has to handle. The execution of a process is halted and another is started, preventing a single thread from monopolizing the entire 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.

Typically for a server, it is not desirable to allow the foreground program to have more CPU time allocated to it than background processes. That is, all applications and their processes running on the server should be given equal contention for the CPU.

To set this, Open the System Control Panel, select the Advanced tab, in the Performance frame click Settings, go to the Advance tab, and within the Processor Scheduling frame, set the Adjust for best performance of: to Background Services.

 

Memory usage

The file system cache is an area of physical memory set aside to dynamically store recently
accessed data that has been read or written from or to the I/O subsystem (hard drives, networks interfaces, and networks). The file system cache improves performance by reducing the number of accesses to physical devices attached to the I/O subsystem, by moving commonly used files into system cache, disk and network read and write operations are reduced and system performance is increased. You can optimize Windows server performance by tuning the file system cache.

System Cache: This option is the default setting. It instructs the operating system to give the working set of the file system cache a higher priority for memory allocation than the working sets of applications. It will give the best performance on a file server that is not running other applications.
Programs: This choice is the recommended setting for machines running applications that are memory-intensive (SQL, Exchange, etc’). With this option chosen, the working set of applications will have a priority over the working set of the file system cache.

 

Virtual memory

Memory paging occurs when memory resources required by the processes running on the server exceed the physical amount of memory installed. Windows uses virtual memory techniques that allow applications to address greater amounts of memory than what is physically available. This is achieved by setting aside a portion of disk for paging. This area, known as the paging file, is used by the operating system to page portions of physical memory contents to disk, freeing up physical memory to be used by applications that require it at a given time. The combination of the paging file and the physical memory installed in the server is known as virtual memory.

Physical memory can be accessed faster than the disk. Every time the operating system needs to move data between physical memory and the disk, there will be a significant system delay. While some degree of paging is normal on servers, excessive memory paging activity can effect the overall system performance. Thus, it is always desirable to minimize paging activity.

A pagefile can be created for each individual volume on a server, up to a maximum of 16
page files and a maximum 4 GB limit per pagefile. This allows for a maximum total pagefile size of 64 GB. The total of all pagefiles on all volumes is managed and used by the operating system as one large pagefile.
When a pagefile is split between smaller pagefiles on separate volumes as described above, when it needs to write to the pagefile, the virtual memory manager optimizes the workload by
selecting the least busy disk based on internal algorithms. This ensures best possible performance for a multiple-volume pagefile.

Optimal pagefile performance can be achieved by isolating pagefiles to dedicated physical drives on RAID-0 (striping) or RAID-1 (mirroring) arrays, or on single disk without RAID at all. By doing so, the PAGEFILE.SYS is the only file on the entire volume and there is no risk of fragmentation caused by other files or directories on the same volume. As with most disk-arrays, the more physical disks in the array, the better the performance.

 

Where pagefile optimization is critical, do not place the pagefile on the same physical drive as
the operating system, which happens to be the system default. If you don’t have a choice, put the pagefile on the same volume (typically C:) as the operating system. Putting it on another volume on the same physical drive will only increase disk seek time and reduce system performance.

To configure the PageFile, Open the System Control Panel, select the Advanced tab, in the Performance frame click Settings, go to the Advance tab, and within the Virtual Memory frame, click Change.

Best-practice tuning is to set the initial (minimum) and maximum size for the pagefile to the same value. This ensures that no processing resources are lost to the dynamic resizing of the pagefile. Setting the same minimum and maximum page file size values ensures that the paging area on a disk is one single, contiguous area, improving disk seek time.

The pagefile on all disks combined should be configured up to twice the physical memory for
optimal performance.

 

Related reading:

• Performance Tuning Guidelines for Windows Server 2003
• The Case of the Enormous Page File
• Pushing the Limits of Windows: Virtual Memory

VBScript Tools and Links

 

Here are a bunch of tools and links you’ll find useful if you are (or want to get) into scripting in VBS.

 

Code Collections:

TechNet Script Center Sample Scripts
Sample scripts found in the TechNet Script Center Repository.

Script Center All-in-One
Script Center All-in-One features over 160 scripting-related articles collected in a single .CHM file. This collection features all of the Tales From the Script and Office Space columns.

Sesame Script, 2005-2007
The complete collection of Sesame Script, the beginning scripting column published in the TechNet Script Center in a fully-searchable help file, with individual topics arranged by category.

SMS 2003 Scripting Guide
The SMS 2003 Scripting Guide provides over 40 scripts, ranging from tasks such as creating advertisements to running queries. It explains the basics of SMS objects, WMI, and VBScript through a series of ‘How To’ examples.

 

Code Generators:

Scriptomatic 2.0
Utility that helps you write WMI scripts for system administration.
Scriptomatic 2.0 isn’t limited to writing just VBScript scripts; instead, Scriptomatic 2.0 can write scripts in Perl, Python, or JScript as well. In addition, Scriptomatic 2.0 gives you a host of new output formats to use when running scripts, including saving data as plain-text, as a stand-alone Web page, or even as XML. Scriptomatic 2.0 handles arrays, it converts dates to a more readable format, and it works with all the WMI classes on your computer; on top of all that, it also writes scripts that can be run against multiple machines.

ADSI Scriptomatic
The ADSI Scriptomatic is designed to help you write ADSI scripts; that is, scripts that can be used to manage Active Directory. The ADSI Scriptomatic also teaches you an important point about ADSI scripting: like WMI, there are consistent patterns to ADSI scripts.

WMI Code Creator v1.0
The WMI Code Creator tool allows you to generate VBScript, C#, and VB .NET code that uses WMI to complete a management task such as querying for management data, executing a method from a WMI class, or receiving event notifications using WMI.
The tool is meant to help IT Professionals quickly create management scripts and to help developers learn WMI scripting and WMI .NET. The tool helps take the complexity out of writing code that uses WMI and helps developers and IT Professionals understand how powerful and useful WMI can be for managing computers.
Using the tool, you can query for management information such as the name and version of an operating system, how much free disk space is on a hard drive, or the state of a service. You can also use the tool to execute a method from a WMI class to perform a management task. For example, you can create code that executes the Create method of the Win32_Process class to create a new process such as Notepad or another executable. The tool also allows you to generate code to receive event notifications using WMI. For example, you can select to receive an event every time a process is started or stopped, or when a computer shuts down.
The tool also allows you to browse through the available WMI namespaces and classes on the local computer to find their descriptions, properties, methods, and qualifiers

HTA Helpomatic
The HTA Helpomatic is a utility that helps script writers create HTML Applications (HTAs). HTAs enable you to provide a graphical user interface for your scripts, an interface that can include anything from list boxes to radio buttons to checkboxes. The HTA Helpomatic includes sample VBScript code and sample HTML code showing you how to do things like add a button to an HTA. Equally important, the Helpomatic also shows you how you can run a script any time that button is clicked. As an added bonus, the Helpomatic enables you to modify the scripts and HTML code and test those modifications in the utility itself.

Tweakomatic
Tweakomatic is a utility that writes scripts that enable you to retrieve and/or configure Windows and Internet Explorer settings.

 

Language Documentation and References:

Windows Script 5.6 Documentation
Extensive reference and conceptual documentation for all of Microsoft Windows Script Technologies, including VBScript, JScript and WSH.

VBScript Quick Reference
Four-page booklet Word Document reference guide to commonly-used VBScript commands.

VBScript (Visual Basic Script)
Microsoft Visual Basic Scripting Edition (VBScript) is an easy-to-use scripting language that enables system administrators to create powerful tools for managing their Windows based computers.

WSH (Windows Script Host)
Windows Script Host (WSH), a feature of the Microsoft® Windows® 2000 family of operating systems, is a powerful multi-language scripting environment ideal for automating system administration tasks. Scripts running in the WSH environment can leverage the power of WSH objects and other COM-based technologies that support Automation, such as Windows Management Instrumentation (WMI) and Active Directory Service Interfaces (ADSI), to manage the Windows subsystems that are central to many system administration tasks.

WMI (Windows Management Instrumentation)
Windows Management Instrumentation (WMI) is the primary management technology for Microsoft Windows operating systems. It enables consistent and uniform management, control, and monitoring of systems throughout your enterprise. WMI allows system administrators to query, change, and monitor configuration settings on desktop and server systems, applications, networks, and other enterprise components.

ADSI (Active Directory Service Interfaces)
Administering a directory service often involves numerous repetitive tasks such as creating, deleting, and modifying users, groups, organizational units, computers, and other directory resources. Performing these steps manually by using graphical user interface (GUI) tools is time-consuming, tedious, and error prone. A key to reducing time consumption, tedium, and errors when administering a directory is automating repetitive tasks by using scripts.
Active Directory Service Interfaces (ADSI) is the technology that allows you to create custom scripts to administer directories. ADSI-enabled scripts are capable of performing a wide range of administrative tasks involving network directories such as the Active Directory directory service.

EventLog Query Options

This post is actually an answer to Grant’s question.
I quote:

"I discovered eventcombmt today and have been playing round with it. I have an application whereby I want to write out a listing showing any/all accesses by a particular user. I want to run this once a day. I have not been able to figure out what the commandline switch is to specify to only scan the last 24 hours.
Do you know what it is?"

 

Well Grant, If you want to use EventCombMT, you can use the command line parameters /before & /after but then you’ll need to specify the full date and time in the form of MMDDYYYYHHMMSS. The date-time format needs to be exactly 14 characters, and both parameters must be used together. I think this only works in the ALTools version.

A more elegant way, would be to use Log Parser and query the Security EventLog using:

LogParser "SELECT * INTO C:\myEvents.xml FROM \\Server1\Security,\\Server2\Security WHERE EXTRACT_TOKEN(Strings, 1, ‘|’) = ‘myUser’ AND TimeGenerated >= TO_LOCALTIME(SUB(SYSTEM_TIMESTAMP(), TIMESTAMP(’23:59:59′, ‘hh:mm:ss’)))"

(You can open the C:\myEvents.xml with Excel as an XML table).

 

But… A simpler way, would be to use PsLogList from the Sysinternals Suite and run the command:

PsLoglist \\Server1,Server2 -s -h 24 security |find "myUser" >c:\myEvents.log

 

Which one do you prefer?

PerfMon BlackBox

When an airplane crashes, the first thing to do (after searching for survivors of course) is to search for the “blackbox” since it would contain vital information about what might have caused the plane to crash. You can apply this technique on your servers as well.

The “PerfMon BlackBox” is an always-running capture of key performance counters. So when a server crashes, hangs or starts to slow down significantly, you can take the collected data (the blg file) and analyze it for memory leaks or other unexpected resource consumption.

For this, you’ll need a set of two files. One (BlackBox_Counters.txt) containing the list of performance counters to be collected, and a second (BlackBox.cmd) containing the script set of commands to create the data collector using logman.exe.

BlackBox_Counters.txt:

\Cache\Dirty Pages
\Cache\Lazy Write Flushes/sec
\LogicalDisk(*)\% Free Space
\LogicalDisk(*)\% Idle Time
\LogicalDisk(*)\Avg. Disk Bytes/Read
\LogicalDisk(*)\Avg. Disk Bytes/Write
\LogicalDisk(*)\Avg. Disk Queue Length
\LogicalDisk(*)\Avg. Disk sec/Read
\LogicalDisk(*)\Avg. Disk sec/Write
\LogicalDisk(*)\Current Disk Queue Length
\LogicalDisk(*)\Disk Bytes/sec
\LogicalDisk(*)\Disk Reads/sec
\LogicalDisk(*)\Disk Transfers/sec
\LogicalDisk(*)\Disk Writes/sec
\LogicalDisk(*)\Free Megabytes
\Memory\% Committed Bytes In Use
\Memory\Available MBytes
\Memory\Cache Bytes
\Memory\Commit Limit
\Memory\Committed Bytes
\Memory\Free & Zero Page List Bytes
\Memory\Free System Page Table Entries
\Memory\Pages Input/sec
\Memory\Pages Output/sec
\Memory\Pages/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes
\Memory\System Cache Resident Bytes
\Memory\Transition Pages RePurposed/sec
\Network Inspection System\Average inspection latency (sec/bytes)
\Network Interface(*)\Bytes Received/sec
\Network Interface(*)\Bytes Sent/sec
\Network Interface(*)\Bytes Total/sec
\Network Interface(*)\Current Bandwidth
\Network Interface(*)\Output Queue Length
\Network Interface(*)\Packets Outbound Errors
\Network Interface(*)\Packets Received/sec
\Network Interface(*)\Packets Sent/sec
\Network Interface(*)\Packets/sec
\Paging File(*)\% Usage
\PhysicalDisk(*)\Avg. Disk Queue Length
\PhysicalDisk(*)\Avg. Disk sec/Read
\PhysicalDisk(*)\Avg. Disk sec/Write
\PhysicalDisk(*)\Current Disk Queue Length
\PhysicalDisk(*)\Disk Bytes/sec
\PhysicalDisk(*)\Disk Reads/sec
\PhysicalDisk(*)\Disk Writes/sec
\Process(*)\% Privileged Time
\Process(*)\% Processor Time
\Process(*)\Handle Count
\Process(*)\ID Process
\Process(*)\IO Data Operations/sec
\Process(*)\IO Other Operations/sec
\Process(*)\IO Read Operations/sec
\Process(*)\IO Write Operations/sec
\Process(*)\Private Bytes
\Process(*)\Thread Count
\Process(*)\Virtual Bytes
\Process(*)\Working Set
\Processor Information(*)\% of Maximum Frequency
\Processor Information(*)\Parking Status
\Processor(*)\% DPC Time
\Processor(*)\% Interrupt Time
\Processor(*)\% Privileged Time
\Processor(*)\% Processor Time
\Processor(*)\% User Time
\Processor(*)\DPC Rate
\Server\Pool Nonpaged Failures
\Server\Pool Paged Failures
\System\Context Switches/sec
\System\Processor Queue Length
\System\System Calls/sec
\TCPv4\Connection Failures

BlackBox.cmd:

set “LogName=BlackBox”
set “LogsPath=D:\Perflogs”
set “CountersFile=BlackBox_Counters.txt”

logman query |find /i /c “%LogName%”
if ERRORLEVEL 1 goto CreateLog

:UpdateLog
logman update %LogName% -v nnnnnn -cf “%~dp0%CountersFile%” -si 00:01:00 -f bincirc -o “%LogsPath%\%LogName%_%COMPUTERNAME%” -max 1024
goto StartLog

:CreateLog
logman create counter %LogName% -v nnnnnn -cf “%~dp0%CountersFile%” -si 00:01:00 -f bincirc -o “%LogsPath%\%LogName%_%COMPUTERNAME%” -max 1024

:StartLog
logman start %LogName%

:ClearOldLogs
forfiles /p %LogsPath% /m *.blg /d -7 /c “cmd /c del /q @path”

Now you can set your server’s “PerfMon BlackBox” by putting both files in a folder under your %USERDOMAIN%\NETLOGON folder, then create a new GPO, and assign the BlackBox.cmd script as the computer startup script. This way, whenever a server boots up, it will cerate/update the BlackBox collector and run it.

Note: The last line of the script file (under ClearOldLogs) is responsible for deleting blg files older than 7 days, so your disk is not bloated with old and irrelevant counter files.

Before you go and analyze the counters using perfmon, I recommend you use a set of registry tweaks that will make your life working with PerfMon a little easier.

PerfMonTweaks.reg:

Windows Registry Editor Version 5.00

#http://support.microsoft.com/kb/281884
#The Process object in Performance Monitor can display Process IDs (PIDs)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance]
“ProcessNameFormat”=dword:00000002

#http://support.microsoft.com/kb/300884
#Display Comma Separators in the Windows Performance Tool
[HKEY_CURRENT_USER\Software\Microsoft\SystemMonitor]
“DisplayThousandsSeparator”=dword:00000001

#http://support.microsoft.com/kb/283110
#Vertical lines are displayed in the Sysmon tool that obscure the graph view
[HKEY_CURRENT_USER\Software\Microsoft\SystemMonitor]
“DisplaySingleLogSampleValue”=dword:00000001

And if you don’t know how, you can always use PAL to analyze the performance logs. It generates an HTML based report which graphically charts important performance counters and show alerts when thresholds are exceeded. Just remember PAL is not a replacement of traditional performance analysis, but it automates the analysis of performance counter logs enough to save you time.

Related reading:

• Use PerfMon to Diagnose Common Server Performance Problems
• Manipulating Performance Monitor Logs
• Performance Tuning Guidelines for Windows Server 2003