CHAPTER 33
Capacity Analysis and Performance Optimization

Capacity analysis and performance optimization are critical parts of deploying or migrating to Windows Server 2016. Capacity analysis and performance optimization ensures that resources and applications are available, uptime is maximized, and systems scale well to meet the growing demands of business. The release of Windows Server 2016 includes some new and some refreshed tools to assist IT administrators and staff with properly assessing server capacity and performance—before and after Windows Server 2016 is deployed on the network. If you invest time in understanding and using these processes, you will spend less time troubleshooting or putting out fires, thus making your life less stressful and also reducing business costs.

If you have ever found yourself having to specify configuration requirements for a new server or having to estimate whether your configuration will have enough power to sustain various workloads now and in the foreseeable future, proper capacity analysis can help in the design and configuration. These capacity-analysis processes help weed out the unknowns and assist you while making decisions as accurately as possible. They do so by giving you a greater understanding of your Windows Server 2016 environment. You can then use this knowledge and understanding to reduce time and costs associated with supporting and designing an infrastructure. The result is that you gain more control over the environment, reduce maintenance and support costs, minimize firefighting, and make more efficient use of your time.

Business depends on network systems for a variety of different operations, such as performing transactions or providing security so that the business functions as efficiently as possible. Systems that are underutilized are probably wasting money and are of little value. Systems that are overworked or cannot handle workloads might prevent the business from completing tasks or transactions in a timely manner, cause a loss of opportunity, or keep the users from being productive. Either way, these systems are typically not providing as much benefit as they can to operating the business. To keep network systems well tuned for the given workloads, capacity analysis seeks a balance between the resources available and the workload required of the resources. The balance provides just the right amount of computing power for given and anticipated workloads.

This concept of balancing resources extends beyond the technical details of server configuration to include issues such as gauging the number of administrators that might be needed to maintain various systems in your environment. Many of these questions relate to capacity analysis, and the answers are not readily known because they cannot be predicted with complete accuracy.

To lessen the burden and dispel some of the mysteries of estimating resource requirements, capacity analysis provides the processes to guide you. These processes include vendor guidelines, industry benchmarks, analysis of present system resource utilization, and more. Through these processes, you’ll gain as much understanding as possible of the network environment and step away from the compartmentalized or limited understanding of the systems. In turn, you’ll also gain more control over the systems and increase your chances of successfully maintaining the reliability, serviceability, and availability of your system.

There is no set or formal way to start your capacity-analysis processes. However, a proven and effective means to begin to proactively manage your system is to first establish systemwide policies and procedures. Policies and procedures, discussed shortly, help shape service levels and users’ expectations. After these policies and procedures are classified and defined, you can more easily start characterizing system workloads, which will help gauge acceptable baseline performance values.

Another benefit of capacity analysis is that it can be applied to small environments and scale well into enterprise-level systems. The level of effort needed to initially drive the capacity-analysis processes will vary depending on the size of your environment, geography, and political divisions. With a little upfront effort, you’ll save time, expense, and gain a wealth of knowledge and control over the network environment.

Essentially, policies and procedures define how the system is supposed to be used—establishing guidelines to help users understand that they cannot use the system in just any way they see fit. Many benefits are derived from these policies and procedures. For example, in an environment where policies and procedures are working successfully but where network performance becomes sluggish, it would be safe to assume that groups of people weren’t playing a multiuser network game, that several individuals weren’t sending enormous email attachments to everyone in the global address list, or that a rogue web or FTP server was not placed on the network.

The network environment is shaped by the business more so than the IT department. Therefore, it is equally important to gain an understanding of users’ expectations and requirements through interviews, questionnaires, surveys, and more. Some examples of policies and procedures that you can implement in your environment pertaining to end users are the following:

Email message size, including attachments, cannot exceed 10MB.

SQL Server databases settings are enforced with Policy-Based Management.

Beta software, freeware, and shareware can be installed only on test equipment (that is, not on client machines or servers in the production environment).

Specify what software is allowed to run on a user’s PC through centrally managed but flexible group policies.

All computing resources are for business use only (in other words, no gaming or personal use of computers is allowed).

Only business-related and approved applications are supported and allowed on the network.

All home directories are limited in size (e.g., 5GB) per user.

Users can receive IT support by filling out the technical support web form or through the advertised help desk phone number.

Policies and procedures, however, aren’t just for end users. They can also be established and applied to IT personnel. In this scenario, policies and procedures can serve as guidelines for technical issues, rules of engagement, or an internal set of rules to abide by. The following list provides some examples of policies and procedures that might be applied to the IT department:

System backups must include system state data and should be completed by 5 a.m. each workday, and restores should be tested monthly for accuracy and disaster preparedness.

Routine system maintenance should be performed only outside of normal business hours (e.g., weekdays between 8 p.m. and 5 a.m. or on weekends).

Basic technical support requests should be attended to within two business days.

Priority technical support requests should be attended to within four hours of the request.

Any planned downtime for servers should follow a change-control process and must be approved by the IT director at least one week in advance with a 5-day lead time provided to those impacted by the change.

Baselines give you a starting point with which you can compare results. For the most part, determining baseline performance levels involves working with hard numbers that represent the health of a system. A few variables coincide with the statistical representations, however, such as workload characterization, vendor requirements or recommendations, industry-recognized benchmarks, and the data that you collect.

It is unlikely that each system in your environment is a separate entity that has its own workload characterization. Most, if not all, network environments have systems that depend on other systems or are even intertwined among different workloads. This makes workload characterization difficult at best.

So, why is workload characterization so important? Identifying system workloads allows you to determine the appropriate resource requirements for each of them. This way, you can properly plan the resources according to the performance levels the workloads expect and demand.

As you would suspect, sales and marketing departments all too often exploit the benchmark results to sway IT professionals over their way. For this reason, it is important to investigate the benchmark results and the companies or organizations that produced the results. Vendors, for the most part, are honest with the results, but it is always a good idea to check with other sources, especially if the results are suspicious. For example, if a vendor has supplied benchmarks for a particular product, check to ensure that the benchmarks are consistent with other benchmarks produced by third-party organizations (such as magazines, benchmark organizations, and in-house testing labs). If none are available, try to gain insight from other IT professionals or run benchmarks on the product yourself before implementing it in production.

Although some suspicion might arise from benchmarks because of the sales and marketing techniques, the real purpose of benchmarks is to point out the performance levels that you can expect when using the product. Benchmarks can be extremely beneficial for decision-making, but they should not serve as your sole source for evaluating and measuring performance. Use the benchmark results only as a guideline or starting point when consulting benchmark results during capacity analysis. It is also recommended that you pay close attention to their interpretation.

Table 33.1 lists companies or organizations that provide benchmark statistics and benchmark-related information, and some also offer tools for evaluating product performance.

A number of sizing tools are available from various companies. A sizing tool takes data relative to the networking environment and returns recommended hardware configurations, usually in a Microsoft Excel spreadsheet or similar reporting application. One such tool is the Microsoft Assessment and Planning (MAP) Toolkit. This tool, available for download from Microsoft at http://technet.microsoft.com/en-us/solutionaccelerators/dd537566, assists you when planning your migration to Windows Server 2016 by creating an inventory of your current server infrastructure; therefore, you can determine hardware and device compatibility and Windows Server 2016 readiness.

Microsoft also offers free virtualization solution accelerators. For example, you can use the MAP Toolkit to accelerate your migration to Hyper-V on Windows Server 2016 by identifying underutilized servers within your infrastructure, which can be potential virtualization candidates.

Microsoft also offers several useful utilities that are either inherent to Windows Server 2016 or are sold as separate products. Some of these utilities are included with the operating system, such as Task Manager, Network Monitor, Performance Monitor, and the enhanced Event Viewer. Data that is collected from these applications can be exported to other applications, such as Excel or Microsoft Access, for inventory and analysis. Other Microsoft utilities like System Center Configuration Manager (SCCM) and System Center Operations Manager (OpsMgr) can also be used; however, they are sold separately.

To begin using Task Manager, use any of the following methods:

Right-click the taskbar and select Task Manager.

Press Ctrl+Alt+Delete, and then click Task Manager.

Press Ctrl+Shift+Esc or Ctrl+Alt+End (if connected through Remote Desktop).

When you start Task Manager, a screen similar to that shown in Figure 33.1 opens.

The default view of Task Manager in Windows Server 2016 is the Summary view, which shows the list of running applications. You can end applications from this view.

The More Details button opens the more familiar Task Manager window, which contains the following five tabs:

Processes—On this tab, you can find basic information about processes currently running on the system. Sorted by application processes and background processes, available data includes CPU and memory usage, process status, command line, and more.

Performance—This tab provides a lot of information about CPU utilization and configuration, memory usage and allocation, and network utilization and configuration. This tab also includes a link to Resource Monitor, a full-featured monitoring tool included in Windows Server 2016 and discussed in depth in this chapter.

Users—This tab displays users who are currently logged on to the system and includes the option to disconnect users.

Details—The Details tab presents detailed information about running processes in a view familiar from earlier versions of the Task Manager tool. The more in-depth information includes I/O information, session ID, memory pool data, process affinity, and priority.

Services—A somewhat recent addition to Task Manager is the Services tab. With it, administrators can see what services are running and can start and stop services without having to load an additional console.

As you can see, Task Manager presents a variety of valuable real-time performance information. This tool is particularly useful for determining what processes or applications are problematic and gives you an overall picture of system health with quick access to terminate applications and processes or identify potential bottlenecks.

There are limitations, however, that prevent it from becoming a useful tool for long-term or historical analysis. For example, Task Manager cannot store collected performance information for future analysis and viewing; it is capable of monitoring only certain aspects of the system’s health, and the information that is displayed pertains only to the local machine. For these reasons alone, Task Manager is typically used for troubleshooting and only the most basic of capacity planning tasks.

The features in Network Monitor 3.4 include the following:

Support for Windows Server 2016 and 2012, Hyper-V, Windows 8, and Windows 7

The ability to capture WWAN and tunnel traffic on Window 7 and Windows 8 computers

Support for both IPv4 and IPv6

To capture network traffic, install Network Monitor 3.4 and follow these steps:

1. Run Network Monitor (Start, Microsoft Network Monitor 3.4).

2. Click the New Capture Tab link in the left pane.

3. Click the Start button or press F5 to start capturing traffic.

To apply filters to a captured stream of information, follow these steps:

To create a capture filter—With the Capture tab selected, click the Capture Settings button or press F4. Click Load Filter, Standard Filters to select a preconfigured filter that will capture traffic relative to a specific item such as DNS, as shown in Figure 33.4.

To create a display filter—From the Filter menu, click Display Filter, Load Filter, Standard Filters to select a preconfigured filter that will only display information relative to a specific item such as DNS from captured data.

To create a color filter—From the Frames menu, select Color Rules. Click New to create a new rule, select Load Filter, Standard Filters to apply a color effect to specific items such as DNS.

After a capture or display filter has been added, it must be applied, as shown in Figure 33.5. Apply the filters:

To apply a capture filter, open the capture settings and click the Apply button.

To apply a display filter, select the Display Filter pane and click Apply Filter.

A color rule or display filter can be fine-tuned based on captured data. Hover the mouse over the desired value, right-click, and select Add Property to Color Rule or Display Filter. This action adds a filter condition for the property to equal the value of the selected frame, as shown in Figure 33.6.

To remove a filter, follow these steps:

To remove a capture filter, open the capture settings and click the Remove button.

To remove a display filter, select the Display Filter pane and click Remote.

To remove a color rule, delete the rule from the Color Rules tab of the Options dialog.

To capture network traffic between two different computers using IPv4 source and destination addresses, as shown in Figure 33.7, follow these steps:

1. In Network Monitor, click the New Capture button on the left.

2. Click the Capture Settings button. Click Load Filter, Standard Filters.

3. Select Addresses, and then IPv4 Addresses.

4. Edit the filter to specify the IP addresses that should be filtered in the Capture Filter window (for example, 192.168.0.100 and Any).

5. Click the Apply button in the Capture Filter pane, and then click Close.

6. Click the Start button on the main Network Monitor menu bar or press the F5 key to start the capture.

To modify parsing of captured data in Network Monitor, follow these steps:

1. With a capture running or loaded from a saved file, select the Parsers tab in Network Monitor, as shown in Figure 33.8.

2. Expand the appropriate parsing category and double-click the desired parser to load the parser code into the editor. Parsers use Network Monitor Parser Language (NPL), a simple-to-use language. Help for NPL is included in the Network Monitor Help file.

Using Performance Monitor, administrators can identify bottlenecks and pinpoint resource issues with applications, processes, or hardware. Monitoring of these items can help identify and resolve issues, plan for capacity changes, and help establish baselines for use in future analysis. Upon launching the Performance Monitor, a summary of system performance is displayed, showing current memory, disk, processor, and network loads.

To create and view reports in Performance Monitor, follow these steps:

1. Expand Data Collector Sets and System in the console tree of Performance Monitor.

2. Right-click either the System Diagnostics or System Performance sets and select Start. Windows will begin collecting data for the report.

3. When you have collected enough data, right-click the collection set again and select Stop.

4. Expand Reports, System and click the collection set you chose earlier. Double-click the report listed under that performance set.

The report will be compiled and displayed, as in Figure 33.12.

Discussing each of these tools in depth is beyond the scope of this book; however, a basic understanding and overview of their purposes will help you make an informed decision when selecting the right technologies for analyzing system resources, availability, and performance.

Although it might be true that most third-party capacity-analysis and performance-monitoring products might add more or different functionality to your capacity-analysis and performance-monitoring procedures or goals, there are still pros and cons to using them instead of the free tools included with Windows Server 2016 or other solutions available from Microsoft. The key is to decide what you need to adequately and efficiently perform capacity-analysis and performance-monitoring procedures in your environment. Taking the time to research and experiment with the different solutions available today, from Microsoft and others, will only benefit you in making an informed decision for managing your Windows Server 2016 environment.

Every Windows Server 2016 server has a common set of resources that can affect performance, reliability, stability, and availability. For this reason, it is important that you monitor this common set of resources (namely CPU, memory, disk, and network utilization).

In addition to the common set of resources, the functions that the Windows Server 2016 server performs can influence what you should consider monitoring. So, for example, you would monitor certain aspects of system performance on file servers differently than you would for a domain controller running on Windows Server 2016 Active Directory Domain Services (AD DS). There are many functional roles (such as file and print sharing, application clustering, database functions, web server duties, domain controller roles, and more) that Windows Server 2016 can perform, and it is important to understand all those roles that pertain to each server system. By identifying these functions and monitoring them along with the common set of resources, you gain much greater control and understanding of the system.

The following sections go more in-depth on what specific items you should monitor for the different components that constitute the common set of resources. It’s important to realize, though, that there are several other items that should be considered when monitoring in addition to the ones described in this chapter. You should consider the following material a baseline of the minimum number of things to begin your capacity-analysis and performance-optimization procedures.

A less-common, but equally important, form of bottleneck is one where a system has significantly more RAM, processors, or other system resources than the application requires. In these cases, the system creates extremely large pagefiles, has to manage very large sets of disk or memory sets, but yet never uses the resources. When an application needs to access memory, processors, or disks, the system might be busy managing the idle resource, thus creating an unnecessary bottleneck caused by having too many resources allocated to a system. Thus, performance optimization means not having too few resources, but also means not having too many resources allocated to a system.

There are many significant counters in the memory object that could help determine system memory requirements. Most network environments shouldn’t need to consistently monitor every single counter to get accurate representations of performance. For long-term monitoring, two very important counters can give you a fairly accurate picture of memory pressure: Page Faults/sec and Pages/sec Memory. These two memory counters alone can indicate whether the system is properly configured and experiencing memory pressure. Table 33.3 describes the counters necessary to monitor memory and pagefile usage.

By default, the Memory tab in Resource Monitor, shown in Figure 33.13, provides a good high-level view of current memory activity. For more advanced monitoring of memory and pagefile activity, use the Performance Monitor snap-in.

Systems experience page faults when a process requires code or data that it cannot find in its working set. A working set is the amount of memory that is committed to a particular process. When this happens, the process has to retrieve the code or data in another part of physical memory (referred to as a soft fault) or, in the worst case, has to retrieve it from the disk subsystem (a hard fault). Systems today can handle a large number of soft faults without significant performance hits. However, because hard faults require disk subsystem access, they can cause the process to wait significantly, which can drag performance to a crawl. The difference between memory and disk subsystem access speeds is exponential even with the fastest solid state drives available. The Memory section of the Resource Monitor in Performance Monitor includes columns that display working sets and hard faults by default.

The Page Faults/sec counter reports both soft and hard faults. It’s not uncommon to see this counter displaying rather large numbers. Depending on the workload placed on the system, this counter can display several hundred faults per second. When it gets beyond several hundred page faults per second for long durations, you should begin checking other memory counters to identify whether a bottleneck exists.

Probably the most important memory counter is Pages/sec. It reveals the number of pages read from or written to disk and is, therefore, a direct representation of the number of hard page faults the system is experiencing. Microsoft recommends upgrading the amount of memory in systems that are seeing Pages/sec values consistently averaging above five pages per second. In actuality, you’ll begin noticing slower performance when this value is consistently higher than 20. So, it’s important to carefully watch this counter as it nudges higher than 10 pages per second.

System memory (RAM) is limited in size, and Windows supplements the use of RAM with virtual memory, which is not as limited. Windows will begin paging to disk when all RAM is being consumed, which, in turn, frees RAM for new applications and processes. Virtual memory resides in the pagefile.sys file or in specific application-designated memory-mapped files. The primary paging file, pagefile.sys is usually located in the root of the system drive and can be relocated or configured for performance reasons. Each disk can contain a pagefile. The location and size of the pagefile is configured under the Virtual Memory section, shown in Figure 33.14.

To access the Performance Options window, follow these steps:

1. Open the metro UI and type Control Panel and launch the Control Panel from the search results.

2. Click the System and Security category and then the System control panel.

3. Click the Advanced System Settings link on the left.

4. When the System Properties window opens, click the Settings button under the Performance section.

5. Select the Advanced tab.

6. Click Change under Virtual Memory.

The % Processor Time counter indicates the percentage of overall processor utilization. If the system has more than one processor, an instance for each one is included along with a total (combined) value counter. If this counter averages a usage rate of 50% or greater for long durations, you should first consult other system counters to identify any processes that might be improperly using the processors or consider upgrading the processor or processors. Generally speaking, consistent utilization in the 50% range doesn’t necessarily adversely affect how the system handles given workloads. When the average processor utilization spills over the 65% or higher range, performance might become intolerable. If you have multiple processors installed in the system, use the % Total Processor Time counter to determine the average usage of all processors.

The Interrupts/sec counter is also a good guide of processor health. It indicates the number of device interrupts that the processor (either hardware or software driven) is handling per second. Like the Page Faults/sec counter mentioned in the section “Monitoring System Memory and Pagefile Usage,” this counter might display very high numbers (in the thousands) without significantly impacting how the system handles workloads.

Conditions that could indicate a processor bottleneck include the following:

Average of % Processor Time is consistently over 60% to 70%. In addition, spikes that occur frequently at 90% or greater could also indicate a bottleneck even if the average drops below the 60% to 70% mark.

Maximum of % Processor Time is consistently over 90%.

Average of the System Performance Counter; Context Switches/second is consistently greater than 20,000.

The System Performance Counter; Processor Queue Length is consistently greater than 2.

By default, the CPU tab in Resource Monitor, shown in Figure 33.15, provides a good high-level view of current processor activity. For more advanced monitoring of processors, use the Performance Monitor snap-in with the counters discussed previously.

To support the Resource Monitor’s Disk section, the physical and logical disk counters are enabled by default in Windows Server 2016. The Disk section in Resource Monitor, shown in Figure 33.16, provides a good high-level view of current physical and logical disk activity (combined). For more advanced monitoring of disk activity, use the Performance Monitor component with the desired counters found in the Physical Disk and Logical Disk sections.

Monitoring with the Physical and Logical Disk objects does come with a small price. Each object requires a little resource overhead when you use them for monitoring. As a result, you might want to keep them disabled unless you are going to use them for monitoring purposes.

So, what specific disk subsystem counters should be monitored? The most informative counters for the disk subsystem are % Disk Time and Avg. Disk Queue Length. The % Disk Time counter monitors the time that the selected physical or logical drive spends servicing read and write requests. The Avg. Disk Queue Length monitors the number of requests not yet serviced on the physical or logical drive. The Avg. Disk Queue length value is an interval average; it is a mathematical representation of the number of delays the drive is experiencing. If the delay is frequently greater than two, the disks are not equipped to service the workload and delays in performance might occur.

The information that you’ll want to gain from monitoring the network pertains to network activity and throughput. You can find this information with the Performance Monitor alone, but it will be difficult at best. Instead, it is important to use other tools, such as Network Monitor, discussed earlier in this chapter in the section “Network Monitor,” in conjunction with Performance Monitor, to get the best representation of network performance as possible. You might also consider using third-party network-analysis tools such as network sniffers to ease monitoring and analysis efforts. Using these tools simultaneously can broaden the scope of monitoring and more accurately depict what is happening on the wire.

Because the TCP/IP suite is the underlying set of protocols for a Windows Server 2016 network subsystem, this discussion of capacity analysis focuses on this protocol.

Several different network performance objects relate to TCP/IP, including ICMP, IPv4, IPv6, Network Interface, TCPv4, UDPv6, and more. Other counters, such as FTP Server and WINS Server, are added after these services are installed. Because entire books are dedicated to optimizing TCP/IP, this section focuses on a few important counters that you should monitor for capacity-analysis purposes.

First, examining error counters, such as Network Interface: Packets Received Errors or Packets Outbound Errors, is extremely useful in determining whether traffic is easily traversing the network. The greater the number of errors indicates that packets must be present, causing more network traffic. If a high number of errors are persistent on the network, throughput will suffer. This can be caused by a bad NIC, unreliable links, and so on.

If network throughput appears to be slowing because of excessive traffic, keep a close watch on the traffic being generated from network-based services, such as the ones described in Table 33.4. Figure 33.17 shows these items being recorded in Performance Monitor.

Microsoft also makes several other tools available that will analyze systems and recommend changes. Ensuring a system is properly configured to deliver services for the role it supports is essential before performance monitoring and capacity planning can be taken seriously.

The Directory Services Performance Monitor object provides various AD performance indicators and statistics that are useful for determining AD’s workload capacity. You can use many of these counters to determine current workloads and how these workloads can affect other system resources. This object has quite a few counters, so it’s recommended to identify your specific monitoring needs in advance. The naming convention of many counters is used to group them by component, such as Lightweight Directory Access Protocol (LDAP), DRA (directory replication agent), DS, and Security Accounts Manager (SAM). With this combination of counters, you can review the status of every component of AD DS and determine whether the system is overloaded and whether AD performance is impacted.

Measuring AD DS replication performance is a complex process because of the many variables associated with replication, including the following:

Intrasite versus intersite replication

The compression being used (if any)

Available bandwidth

Inbound versus outbound replication traffic

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

Like most other server products, AD DS uses a database, and its performance should also be monitored to provide an accurate reflection of AD DS performance. Understanding a domain controller’s overall system resource usage and the performance of AD DS will help you align future upgrades and changes with capacity and performance needs. As companies continue to grow, it is essential that the systems be able to grow with them, especially with regard to something critical like AD DS. Many counters are available, and Table 33.5 describes some of the relevant counters necessary to monitor AD DS and the database. This is only a sample list, and additional counters might need to be added, depending on the desired outcome of the monitoring and specific AD DS functionality.

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

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

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

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

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

By properly analyzing the operational functions of a network, a network administrator can consolidate servers or virtualize servers to gain more density in system resources, which can result in additional physical servers that can ultimately be used for other purposes, such as disaster recovery failover servers or cluster servers providing high availability of IT resources.

Although it is easy to get caught up in daily administration and firefighting, it is important to step back and begin capacity-analysis and performance-optimization processes and procedures. These processes and procedures can minimize the environment’s complexity, help IT personnel gain control over the environment, assist in anticipating future resource requirements, and, ultimately, reduce costs, and keep users of the network happy.

Spend time performing capacity analysis to save time troubleshooting and firefighting.

Use capacity-analysis processes to help weed out the unknowns.

Establish systemwide policies and procedures to begin to proactively manage your system.

After establishing systemwide policies and procedures, start characterizing system workloads.

Use performance metrics and other variables such as workload characterization, vendor requirements or recommendations, industry-recognized benchmarks, and the data that you collect to establish a baseline.

Use the benchmark results only as a guideline or starting point.

Use the Task Manager or the Resource Monitor in Performance Monitor to quickly view performance.

Use the Performance Monitor to capture performance data on a regular basis.

Consider using System Center Operations Manager or Microsoft products and third-party products to assist with performance monitoring, capacity and data analysis, and reporting.

Carefully choose what to monitor so that the information doesn’t become unwieldy.

At a minimum, monitor the most common contributors to performance bottlenecks: memory and pagefile usage, processor, disk subsystem, and network subsystem.

Identify and monitor server functions and roles along with the common set of resources.

When monitoring specific roles like virtual servers or AD DS, include the common performance counters such as memory, CPU, disk, and network as well as counters specific to the role of the server.

Examine network-related error counters.