Running the Pilot Project

After you set up your test network, you are ready to start running the pilot project. To do so, complete the following tasks:

  1. Install SMS on the central site server, being careful to install all the components you want to run in a production environment.
  2. Install all the child primary sites and connect them to the central site.
  3. Install the secondary sites and add clients to your site hierarchy.


Important   Be sure that all your computers are synchronized to the same time. Synchronized system clocks will enable you to identify issues occurring across several computers by matching events recorded in log files with the same time stamps.


When all the computers have the necessary software installed and running, you are ready to begin using SMS and Windows NT performance tools to test your site hierarchy.

Using SMS Performance Tools

The main objective of the pilot project is to analyze your SMS site hierarchy design. To complete this analysis, you must use several different tools that are either included in this edition of the Microsoft BackOffice 4.5 Resource Kit CD-ROM or provided with SMS 2.0.

There are two types of tools in your pilot project: test tools and production tools. Production tools will run in your production environment. Therefore, they need to be part of your load signature and should not be run remotely. SMS status messages and Network Monitor are designed for use in a production environment.

Test tools, however, are not optimized for your production environment, and need to be moved to a remote computer or disabled on the pilot project after preliminary testing. SMS logging is a test feature and should be disabled after you complete the troubleshooting phase of your testing. Performance Monitor is both a test and production tool. However, it will only have a slight impact on system resources and will not significantly affect your load signature calculations.

The following sections explain the tools you will find useful.

Configuring the site hierarchy

SMS Site Property Manager enables you to create a site configuration and then save it for future use. You can use this tool in a test environment to quickly build and configure a hierarchy of sites. This tool can also help you enforce a configuration policy within your lab setting and test environment variables effectively. The ability to save a copy of your site control file might also be useful in your production environment.

In addition, SMS Site Property Manager enables you to make changes to your site that cannot be made through the SMS Administrator console. For example, you can use this tool to change client polling rates. Increasing the frequency of these rates enables you to investigate system performance over many more cycles than you might typically observe in the same time frame.

For more information about SMS Site Property Manager, see Chapter 11, “Configuring and Populating Pilot Sites,” in this guide.

Generating load for your site hierarchy

To troubleshoot your SMS site hierarchy, you must analyze the load signature, which can only be done when there is a load on your system. To generate artificial load for your pilot project, use SMS Object Generator to create data that mimics the real data that SMS produces during typical system operations. You can then use Performance Monitor to generate the load signature.

For more information about SMS Object Generator, see Chapter 11, “Configuring and Populating Pilot Sites,” in this guide.

Simulating running multiple remote Administrator consoles

The SMS Console Load Simulation tool enables you to issue queries against the SMS site database to simulate running as many as 50 remote SMS Administrator consoles on a site.

For more information about the SMS Console Load Simulation tool, see Chapter 14, “Using SMS 2.0 Tools — Part 2,” in this guide.

Using the SMS log files and status messages to monitor component performance

SMS can log the activities of any service or thread component. However, logging in a production environment might use an unacceptable amount of system resources. For this reason, all component logging is disabled by default and should not be enabled in a production environment except for diagnostic purposes. The status message system should provide sufficient troubleshooting information during typical operation of your SMS sites.

Using the logging capabilities during your pilot project will assist you in understanding how some components, especially those that interact with SQL Server, are functioning. (Note that SMS logging will provide a different load signature than is typical in a production environment.) Analyzing time stamps in the log files of certain server components can also be a useful way to determine exactly how fast the system is processing certain objects that are flowing through the system. The effect that logging has on your system is directly related to the disk subsystem that you have implemented — the better the disk subsystem, the less the impact of logging on your system.

SMS status messages are part of the standard SMS 2.0 installation. Status messages enable you to identify which SMS components are running at any given time and assess their performance. Status messages can also quickly alert you to failures in your site hierarchy design. When systems begin to fail due to site hierarchy failure, they usually do not completely stop working. Instead, their status messages report failure. For more information about SMS status messages, see Chapter 20, “Understanding the SMS Status System,” in the SMS 2.0 Administrator’s Guide.

Procedure Bullet  To enable logging for SMS components

  1. In the SMS Administrator console, navigate to SMS Service Manager.
  2. Systems Management Server   Lower levelTools      Lower levelSMS Service Manager
  3. Right-click SMS Service Manager, point to All Tasks, and then click Start SMS Service Manager.
  4. Expand the Primary Site item.
  5. Click Components.
  6. In the details pane, select the components you want to log.
  7. For each component, right-click the selected component, and then click Logging.
  8. Select the Logging enabled check box, and then click OK.

Using Network Monitor

You can select Network Monitor as an option during SMS 2.0 installation. Network Monitor captures and analyzes the content of network frames to diagnose network problems and identify bottlenecks and network traffic patterns. You can use this functionality in a test environment to analyze the functioning of your network. Network Monitor can be an invaluable aid to understanding your network usage.

For more information about Network Monitor, see Chapter 16, “Using SMS for Network Maintenance,” in the SMS 2.0 Administrator’s Guide.

Using Windows NT Performance Tools

Windows NT provides many administrator tools, some of which you might already use to test the performance of your computers. However, two Windows NT tools, Task Manager and Performance Monitor, are central to system performance engineering. This section explains how you can use these tools in your SMS pilot project.

Task Manager

Task Manager’s CPU and memory counters provide an overall picture of system performance and how it affects SMS operations. You should use Task Manager as your first line of defense for better performance. Using this tool enables you to quickly check system resources and SMS service components that are currently running.

Task Manager helps you identify processes that are using system resources. The itemized list of processes provides a quick overview of which processes are using system resources at any given time. A process using system resources at 100 percent (or close to 100 percent) is a likely indication of a hardware bottleneck.

To analyze the performance of individual threads, you can use Performance Monitor or the Quick Slice tool (Qslice.exe), which is available on the Windows NT Workstation Resource Kit compact disc.

Performance Monitor

Performance Monitor is a Windows NT 4.0 administrative tool that you can use to monitor the performance of computers running Windows NT Workstation and Windows NT Server. This tool uses a series of counters to track data, such as the number of processes waiting for disk time, the number of network packets transmitted per second, and the percentage of processor utilization. You can view this data in real time, log it for future study, use it in charts and reports, and set alerts to warn you when it exceeds threshold values.

In a test environment, you can use Performance Monitor to create a load signature for your site hierarchy. Logging all information that Performance Monitor provides is an effective way to achieve an accurate picture of the load on your system.

You should enable the following Performance Monitor counters on all servers and clients during the pilot project:

Memory
Committed bytes
Processor
%Processor Time on each CPU
PhysicalDisk/
%Disk Time on each disk

Disk Bytes/sec on each disk


Note   If you are using hardware RAID, these statistics might be difficult to interpret.


LogicalDisk/
Free Megabytes on each disk
SQLServer
Cache Hit Ratio
Process
%Processor Time on each instance of MMC

%Processor Time on SMSEXEC

%Processor Time on SQLSERVER

%Processor Time on WINMGMT

%Private Bytes on each instance of MMC

%Private Bytes on SMSEXEC

%Private Bytes on SQLSERVER

%Private Bytes on WINMGMT

For information about SMS Performance Monitor counters, see Chapter 27, “Using the SMS Perfmon Counters,” in this guide.

For client performance data, monitor the following client processes:

Remote Monitoring

To generate a true load signature, you must ensure that the computers and environment you are testing with simulate a production environment as much as possible. To do so, make sure that the only processes running on your test computers are processes that will be running in a production environment. This means that you will need to run some of your tools remotely or from a computer for which you are attempting to obtain a load signature.

You must run SMS Object Generator, SMS Site Property Manager, and the SMS Console Load Simulation tool from a remote server.