A friend of mine, asked me to help him out and write the script he needed. I thought of creating a script that asks the user for input (account name, new password and a list of computers) and then runs against all the computers in the list and changes the password accordingly… but wouldn’t it be nicer to have a nifty application that does all that, and that you wouldn’t have to edit a text file, or type-in all the parameters each time you want to run the process but with a different set of arguments?

So I decided to write the application. The list of requirements included:

• The computer list should be easy to manage, and the user should be able to easily add a computer to the list, or a pre-created list from a text file, or even directly from an Active Directory container.
• The process results should be easy to understand, and even available to export and save for future references.
• Have an option to manage only services, only scheduled tasks or both.
• Have an option to restart the services after the password was changed.
• Have an option to change the user account running the services and/or scheduled tasks.
• Have a “dry-run” option that would only show the objects (services and scheduled tasks) that their credentials would have been changed.
• Have an option to quickly connect using Remote Desktop to a selected computer in the list, and to edit the properties of scheduled task listed in the results.

The result from this list, together with other ideas and suggestions that came along the way is SSTUM (Service and Scheduled Task User Manager).

I think it’s easy to use, and the GUI is pretty much self explanatory:

1. Add computers to the list. you can add a specific computer name, a list of computers from an Active Directory container or from a csv or text file) using the buttons in the Computer List box, right-click the list area and use the context menu, or drag-and-drop a csv or a text file to the computers list area.

Note: When using the specific computer option you can use a comma (“,”) to add many computers or an asterisk (“*”) to be used with a search filter to add computers from Active Directory. As a combined example: by typing in “SQL*,*TEST” in the Add a specific computer box, you will be adding to the list all computer accounts in Active Directory that start with “SQL” and all computer accounts that end with “TEST”.

2. Type-in the Current User that you want to change it’s password on all the listed computers, type in the New User if you want the change the user account running the services and scheduled tasks (or type-in the same account as in the current user text box, to leave the account information unchanged)

3. Enter the new password, and type it again in the validate field.

4. Select to Manage Scheduled Tasks, Manage Services and whether to Restart the services after the password was changed or not.

5. Click the Report Objects for a “dry-run”, or the Change Credentials to run the process and actually change the credentials for the selected objects (Services and Scheduled Tasks) on the listed computers.

Note: For the Report Objects option, you need only the Current User information.

6. You can right-click the Results pane to quickly connect to a computer using Remote Desktop, to open the Task Properties window, or to export the results report to a CSV or an XML file to be later opened as an XML table in Excel.

SSTUM uses TaskScheduler.dll from http://www.codeproject.com/KB/cs/tsnewlib.aspx and dsuiext.dll from the Active Directory Service Interfaces, both included in the downloadable zipped file.

Download SSTUM.zip
Please note it requires you to have at least .NET Framework 2.0 installed

Microsoft just released a new poster. The Windows Server 2008 R2 Hyper-V Component Architecture poster:

This poster provides a visual reference for understanding key Hyper-V technologies in Windows Server 2008 R2. It focuses on architecture, snapshots, live migration, virtual networking, storage, and import/export.

Additional IT posters available:

Windows Server 2008 R2 Feature Components poster:

This poster provides a visual reference for understanding key technologies in Windows Server 2008 R2. It focuses on Active Directory Domain Services, Hyper-V, Internet Information Services, Remote Desktop Services (including Virtual Desktop Infrastructure (VDI)), BranchCache, and DirectAccess technologies. In addition, updates to core file services and server management are illustrated. You can use this poster in conjunction with the previously published Windows Server 2008 Component Posters.

Windows Server 2008 Component posters:

These two posters provide a strong visual tool to aide in the understanding of various features and components of Windows Server 2008. One poster focuses exclusively on powerful new Active Directory technologies, while the other provides a technical look at a variety of new features available in Windows Server 2008 (such as Server Core, Network Access Protection, and more).

Exchange Server 2007 Component Architecture poster:

Aside from showing the high-level architecture, this poster highlights the feature set of Exchange Server 2007. Sections include Management and Monitoring, High Availability, Client Access, Edge Transport, Hub Transport, Mailbox, and Unified Messaging server roles

Exchange Server 2010 Transport Server Role Architecture diagrams:

Many components are involved in the transport of messages through the Exchange Server 2010 mail flow pipeline. The Hub Transport server role diagram can help you understand the role each component plays in the processing of messages that enter the Exchange 2010 mail flow pipeline. Exchange administrators can use this information to help diagnose mail flow problems. The Hub Transport extensibility diagram can help you understand how the agents process a message that is in the Exchange 2010 mail flow pipeline. Developers can use this information to help create third-party agents and applications to work with Exchange 2010.

Active Directory 2003 Component Jigsaw poster:

This poster provides a strong visual tool to aide in the understanding of Active Directory components and technologies. From Site Component Topology, to Security, to Group Policy and more, this poster distills all of the must-have information about Active Directory into one easy reference.

20 years ago today, Windows 3.0 was released.

These days, almost everyone is familiar with the "Start" menu in the left-bottom corner of their Windows desktop, the fancy themes, toolbars, and menus. All computers running modern Windows now have these features. But it wasn’t always that way. Very few people remember about the days back before the "Start" button, when they had the simple desktop and the file manager.

Windows 3.0 was not really an operating system. It was a graphical environment with many application services. You had to start it by running the ‘win’ command from the DOS prompt. It relied on DOS not only for booting the computer, but for many basic services like file I/O.

As the third major release of the Windows platform from Microsoft, it offered improved performance, advanced graphics with 16 colors, and full support of the more powerful Intel 386 processor. A new wave of 386 PCs helped drive the popularity of Windows 3.0, which offered a wide range of useful features and capabilities, such as File Manager, Write, Paint Brush, Print manager and Program manager.

The Windows 3.0 GUI is also widely regarded as the reason why IBM killed its own OS/2 operating system. Microsoft launched Windows 3.0 despite the fact that it had signed a strategic partnership with Big Blue to support OS/2.

The rest, as they say, is history. Windows 3.0 was soon to be forgotten as Windows NT and Windows 3.11 were launched a few years later.

For those looking to have a quick play with the Windows 3.1 Program Manager, can visit Michael Vincent’s website and fool around with the Windows 3.1 emulator:

See the Windows History at http://www.microsoft.com/windows/winhistorydesktop.mspx and at http://en.wikipedia.org/wiki/History_of_Microsoft_Windows, and read more about Windows 3.0 at http://en.wikipedia.org/wiki/Windows_3.0

In Windows management, best practices are guidelines to configure a server as defined by experts. For example, it is considered a best practice for most server technologies to keep open ports that are required for the technologies to communicate with other networked computers and also block unused ports. Whereas best practice violations, even very important best practice violations, are not necessarily problematic, they indicate server configurations that can result in poor performance, poor reliability, unexpected conflicts, increased security risks, or other potential problems.

The resulting report of the Best Practices Analyzers, details critical configuration issues, potential problems, and other vital information. By following the recommendations of the tool, administrators can achieve greater performance, scalability, reliability, and uptime.

Some of the IT related BPAs are:

Hyper-V Best Practices Analyzer for Windows Server 2008 R2

You can use Hyper-V Best Practices Analyzer to scan a server that is running the Hyper-V role, and help identify configurations that do not comply with the best practices of Microsoft for this role. BPA scans the configuration of the physical computer, the virtual machines, and other resources such as virtual networking and virtual storage. Scan results are displayed as a list of issues that you can sort by severity, and include recommendations for fixing issues and links to instructions. No configuration changes are made by running the scan.

Microsoft Exchange Best Practices Analyzer v2.8

The Exchange Best Practices Analyzer programmatically collects settings and values from data repositories such as Active Directory, registry, metabase and performance monitor. Once collected, a set of comprehensive ‘best practice’ rules are applied to the topology.

Note: Exchange Best Practices Analyzer v2.8 should not be used to scan Exchange Server 2007 and Exchange Server 2010. In Exchange Server 2007 and Exchange Server 2010, the Best Practices Analyzer is installed during Exchange Setup and can be run from the Exchange Management Console Toolbox.

Microsoft Exchange Troubleshooting Assistant v1.1

The Exchange Troubleshooting Assistant programmatically executes a set of troubleshooting steps to identify the root cause of performance, mail flow, and database mounting issues. The tool automatically determines what set of data is required to troubleshoot the identified symptoms and collects configuration data, performance counters, event logs and live tracing information from an Exchange server and other appropriate sources. The tool analyzes each subsystem to determine individual bottlenecks and component failures, then aggregates the information to provide root cause analysis.

SQL Server 2000 Best Practices Analyzer

The SQL Server 2000 Best Practices Analyzer is a database management tool that lets you verify the implementation of common Best Practices. These best practices typically relate to the usage and administration aspects of SQL Server databases and ensure that your SQL Servers are managed and operated well.

SQL Server 2005 Best Practices Analyzer

The SQL Server 2005 Best Practices Analyzer gathers data from Microsoft Windows and SQL Server configuration settings. BPA uses a predefined list of SQL Server 2005 recommendations and best practices to determine if there are potential issues in the database environment.

Windows SharePoint Services 3.0 and Microsoft Office System 2007 Best Practices Analyzer

The Windows SharePoint Services 3.0 and Microsoft Office System 2007 Best Practices Analyzer programmatically collects settings and values from data repositories such as MS SQL, registry, metabase and performance monitor. Once collected, a set of comprehensive ‘best practice’ rules are applied to the topology.

Internet Security and Acceleration (ISA) Server Best Practices Analyzer

The ISA Server Best Practices Analyzer (BPA) is a diagnostic tool that automatically performs specific tests on configuration data collected on the local ISA Server computer from the ISA Server hierarchy of administration COM objects, Windows Management Instrumentation (WMI) classes, the system registry, files on disk, and the Domain Name System (DNS) settings.

Forefront Threat Management Gateway Best Practices Analyzer

The Forefront Threat Management Gateway Best Practices Analyzer is a diagnostic tool that automatically performs specific tests on configuration data collected on the local Forefront TMG computer from the Forefront TMG hierarchy of administration COM objects, Windows Management Instrumentation (WMI) classes, the system registry, files on disk, and the Domain Name System (DNS) settings.

This is the 4th 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 3)

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.

Networking

Windows servers often have more network services and protocols installed than are actually required. Each additional network client, service or protocol places additional overhead on system resources. In addition, each protocol generates network traffic. By removing unnecessary network clients, services and protocols, system resources are made available for other processes.

On a system supporting more than one network protocol, the order in which they are bound to the network clients and services running on the server is important. All network communications for a given service or client start with the protocol listed at the top of the binding list. If after a given period, no response is received, communications are routed to the next protocol in the list until all protocols are exhausted. As a result it is crucial to ensure the most frequently used protocol for a given client or service is moved to the top of the binding list to offer the best network I/O performance possible.

To view the order of network bindings, Open the Network Connections applet from the Control Panel, and from the menu bar, click Advanced → Advanced Settings.

By selecting a protocol and clicking the up and down buttons, you can change the binding priority of your protocols. If an installed protocol is not required by a particular service or client, it should be disabled.Do so by removing the tick in the check box beside the protocol in question. This will improve system performance and possibly improve security.

Disable Chimney and Offload features

TCP Offload Engine is an emerging technology which is designed to offload TCP stack handling from the main system CPU to a processor built into NIC cards. This technology is still relatively new, and when engaged, has been known to cause unstable connections. This results in dropped sockets, dropped packets, packet reordering and packet retransmits.

To disable the TCP Chimney Offload features:

1. Install the KB948496 update that turns off default SNP features

2. Run the following command at the command prompt:

netsh int ip set chimney DISABLED

3. Set the registry values as described below, or use the Microsoft Fix it #50051

Disable TCP Chimney:

Disable Receive Side Scaling:

Key:	HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value:	EnableRSS
Set to:	0×0 (0)

Disable TCP Window Auto-Tuning:

Key:	HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value:	EnableTCPA
Set to:	0×0 (0)

4. Open Network Connections, locate each connection to see its properties and click Configure  → Advanced. Look for one or more entries as listed below (or similar, it depends on the manufacturer) and verify they are set to Off / Disabled / False:

• TCP/IP Offload
• Checksum Offload
• IPv4 Checksum Offload
• Large Send Offload (IPv4)
• Large Send Offload

Harmful code detection (Antivirus) exclude settings:

Important: This section contains information that shows how to help lower security settings or how to temporarily turn off security features on a computer. You can make these changes to understand the nature of a specific problem. Before you make these changes, you should evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

Exclude the Windows Update or Automatic Update database file:

Folder Path:	%windir%\SoftwareDistribution\Datastore
Files Mask:	Datastore.edb

Exclude the Windows Update or Automatic Update log files:

Exclude the Windows Security files:

Note: If these files are not excluded, antivirus software may prevent proper access to these files, and security databases can become corrupted. Scanning these files can prevent the files from being used or may prevent a security policy from being applied to the files. These files should not be scanned because antivirus software may not correctly treat them as proprietary database files.

Exclude the Group Policy user registry information:

Exclude the Group Policy client settings file:

Exclude the Active Directory and Active Directory main NTDS database files:

Exclude the Active Directory transaction log files:

Exclude the files in the NTDS Working folder:

Exclude the Database Log files and other files in the File Replication Service (FRS) Working folder:

Drivers, Firmware and Service Packs:

Use the latest drivers, firmware, and service packs.
Installing the latest version of a device driver, patch, BIOS update, microcode, or firmware revision for hardware is a very important part of routine server maintenance. Newer device drivers not only fix bugs and increase system stability, but can also increase the performance and efficiency of a device, improving overall system performance.
Microsoft periodically issues service packs and hot fixes for their operating systems. After a period of testing in your environment, these should be deployed to production systems.
Service packs and hot fixes often introduce updated code to key kernel and sub-system components of the operating system and can add extra performance and functionality benefits.

The first thing that came into my mind was the Get-MailboxStatistics PowerShell cmdlet. But then he said that the environment he needed the script for, was a Windows 2003 Domain with Exchange 2003. So I decided I’d do it VBS style.

The details he needed for the report were not only from the Exchange Mailbox but also from the Active Directory:

So I started with an ADSI query to the configurationNamingContext to get the Exchange Servers listed in Active Directory.

(&(objectCategory=msExchExchangeServer)(objectClass=msExchExchangeServer))

For each server, a WMI query to the Exchange_Mailbox Class under the  /root/MicrosoftExchangeV2 namespace to get the StorageLimitInfo, Size, TotalItems, ServerName, StorageGroupName, StoreName and the MailboxDisplayName.

And for each mailbox, query the Active Directory for the additional required details (samAccountName, userPrincipalName, displayName, mail, mDBStorageQuota, mDBOverQuotaLimit and the mDBOverHardQuotaLimit). I used the legacyExchangeDN to match the mailbox to the user account in Active Directory.

(&(ObjectClass=user)(ObjectCategory=person)(legacyExchangeDN=" & legacyExchangeDN & "))

* But then, It got to me that the user may not have specific quota limits set to his user in the Active Directory, and that those settings would be inherited from the mailbox store.

So I added an ADSI query to get the information from the Mailbox Stores,

(&(objectClass=msExchPrivateMDB)(!objectClass=msExchPrivateMDBPolicy))

and put the needed values (mDBStorageQuota, mDBOverQuotaLimit and mDBOverHardQuotaLimit) into to a key-paired Dictionary Object (like a Hashtable). Then, when a user had the mDBUseDefaults set to true, I’d pull the information from the dictionary using his homeMDB property. Actually what I used was the value of:

GetObject("LDAP://" & oRs.Fields("homeMDB")).cn

After a few dry runs, I came across mailboxes that failed to be fully reported. I did some debugging (wscript.echo this and wscript.echo that), and noted that I forgot to handle disconnected mailboxes. So by checking if the DateDiscoveredAbsentInDS property had a value I was able to separate the “connected” from the “disconnected” mailboxes.

The script could still be tweaked for better performance and could use a bit more of logging, but I think it’s good enough to share here and definitely meets my colleague needs.

You can download the full script from here or here.

Just remember to run it using the cscript engine:

cscript //NoLogo ExchMailBoxStats.vbs

Notes:

• You will need administrative rights on the Exchange Server to connect to it using WMI.
• The CSV report will be created in the format of ExchMailBoxStats.yyyyMMdd.csv and located on the same folder as the ExchMailBoxStats.vbs is on.

Microsoft has released a Quick-reference guide to commonly-used Windows PowerShell commands.

For best results, open the file in Microsoft Word, print the contents to legal-sized paper (8 inches by 14 inches), and fold the resulting printout in half, making a four-page booklet.

Download: Windows PowerShell Quick Reference.

Related Download:
Windows PowerShell 1.0 Graphical Help File (including cmdlet help and the About topics) in a fully-searchable, graphical format (a standard Windows .chm file). Also included in the help file is the VBScript to Windows PowerShell Conversion Guide and a collection of PowerShell Tips of the Week.

Related Video:
How Do I: Windows PowerShell 2.0?
Explore how Windows PowerShell 2.0 can help increase the productivity of IT professionals by providing a powerful, complete scripting language to automate repetitive tasks and conduct remote troubleshooting. It delivers a growing set of cmdlets that can be used to manage Windows–based PCs and servers, and it can be easily extended.

PowerShell Code Repositories:

• PowerShell TechNet Script Center
• PoshCode
• PowerShell.com
• PowerShell Scripts

Happy scripting.

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:	0×10 (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:	0×10 (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:	0×0

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:	0×1

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

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