Systems Management Server 2.0 Server Sizing in an Organization

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: August 1, 1999

Abstract

A realistic example of sizing servers to support Microsoft® Systems Management Server (SMS) 2.0, including relevant theory and details, and pointers to related documentation.

On This Page

Introduction
Overview
Sizing SMS Servers
SMS Server Sizing at Contoso Pharmaceuticals
Conclusion
Appendix A: Using Visual Basic Scripts to Get Performance Monitor Thread Information
Appendix B: SMS_THREADS.VBS
Appendix C: An Alternate Method for Relating Thread Numbers to SMS Components
Additional Resources About SMS
Additional Resources About Related Topics

Introduction

This white paper discusses issues and details to help ensure that planned Systems Management Server (SMS) version 2.0 servers are powerful enough for the load they will be expected to carry. These issues and details are illustrated by showing how they are resolved and used at a fictitious company.

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.

Many related topics are discussed extensively elsewhere, and those sources should be referred to for relevant planning issues and technical details. This document supplements details discussed elsewhere. The sources for related SMS and Microsoft® Windows NT® information are listed in Table 1. Other specific references to these documents will also be given throughout this document.

Table 1 Relevant SMS Documentation

Complementary Documents	Relevant Topics	Relevant Chapters
Microsoft Systems Management Server Administrator's Guide (ships with SMS 2.0 CD)	Planning; SMS concepts; SMS administration details	Chapter 1; chapter 3 (primary)
Microsoft Systems Management Server Version 2.0 Resource Guide (part of Microsoft BackOffice 4.5 Resource Kit, from Microsoft Press)	Hardware sizing; scalability tools	Chapter 2; chapters 10 and 14
Windows NT Workstation 4.0 Resource Kit (from Microsoft Press)	Windows NT performance issues	Chapters 9 to 16
SQL Server Resource Guide (part of Microsoft BackOffice 4.5 Resource Kit, from Microsoft Press)	Microsoft SQL Server™ performance issues	Various
https://www.microsoft.com/ntserver/techresources/management/default.asp	Windows Script Host, Windows Management Instrumentation	Various
Microsoft Official Curriculum, Course 828: Deploying and Supporting Microsoft Systems Management Server 2.0	Networking activity	Student lab manual
Microsoft Systems Management Server Web site at https://www.microsoft.com/smserver/default.asp	Product information	Various

Caution: Whenever you refer to SMS documentation, be sure to check all relevant release notes for any late-breaking clarifications.

Overview

Contoso Pharmaceuticals (CP) uses personal computers extensively and effectively for a wide variety of information processing needs. Like many companies, CP needs an effective method for managing their computers. They have chosen Microsoft's Systems Management Server 2.0 (SMS) as their primary computer management tool. At this time, CP is in the midst of planning to deploy SMS 2.0. One of the most important decisions they face is determining how to size the servers they will need to provide SMS services. Also, CP doesn't want to spend any more money than it has to.

The SMS Team members at CP have taken appropriate SMS 2.0 training courses and studied the Microsoft® Systems Management Server Administrator's Guide (referred to later in this paper as the SMS 2.0 Administrator's Guide). They have also become familiar with the SMS portions of the Microsoft® BackOffice® 4.5 Resource Kit, the SMS Software Development Kit (https://www.microsoft.com/smserver/downloads/20/default.asp) , and various SMS documents at the Microsoft Web site. Thus, the SMS Team is well qualified to deploy SMS and use it effectively.

After CP's IT Director, Kim Hightower, decided to purchase Systems Management Server, she went to one of her best systems analysts, John Fortune, and asked him to lead the SMS Team. John knew that SMS complements many of the other Microsoft products that CP uses extensively, so he was excited to help solve this most critical of IT problems-computer management. John assembled a competent team and started the project.

With the help of his SMS Team, John produced a detailed project plan, conducted extensive pilot testing, started the communication process early, and performed several other important steps that every good project requires. While those steps were proceeding, John knew that the time for SMS deployment would arrive soon, and he wanted to ensure that the necessary resources would be in place to support SMS.

One of the most critical resources was the hardware that SMS itself would run on. John needed to work with the SMS Team and others in the company to properly determine where to place each of the SMS sites, how big each site would be, what their system requirements might be, what hardware they had, and what additional hardware he might need to purchase. John knew all this would not be easy in a large organization, but it would certainly be critical to the success of the project.

Reality Check Although your organization might not be as large as CP, you might still find their planning process enlightening. You might also want to concentrate on a subset of their sites that appear similar to your organization, in terms of the number of people at each site, the kinds of problems they have, and how they choose to design their hierarchy.

Introduction to Contoso Pharmaceuticals

John Fortune has worked at CP long enough to have a good idea of how the company functions and what its sites are like. He knows that it has about 20,000 employees and 14,000 personal computers and servers. CP employs many knowledge workers, including scientists, engineers, managers, secretaries, accountants, clerks, and shipping personnel. These workers use many common computer applications, and they often use specialty applications appropriate to their specific roles as well.

John also knows that CP has over 200 locations, most of which are distributed widely throughout the United States, but some of which are located around the world. The company has its headquarters in New York, which is essentially a holding company for the three regional divisions, where the major work of the organization is done. He knows that although some locations have been using SMS 1.2 already, a substantial part of the company has not used SMS before.

John's boss, Kim, has provided him with a chart of CP's main locations, as shown in Figure 1. After talking with Kim, people in the human resources department, and others, John has annotated the diagram with some additional details about how many users are at each site or how many report through the hierarchy to each site, what special issues might be encountered at each site, and so forth.

Figure 1: Contoso Pharmaceutical locations

Collecting Details about Contoso Pharmaceuticals for SMS Planning

As the SMS Team dug into the details of CP's many sites, they produced the SMS Sites spreadsheet shown in Tables 2a and 2b, which they would refer to repeatedly throughout the SMS project. When the SMS Team had enough information about each site individually, they needed to determine how the sites were connected to each other. This information was readily available from the IT department's Networking Team. However, the SMS Team also needed contact people at each site who could answer some computer-related questions and provide physical access to the buildings when necessary. From talking with their site contacts, who were often regional IT staff, the SMS Team was able to determine what types of client computers were at each site, which servers they might be able to use, and a variety of other details.

Table 2a Contoso Pharmaceutical's SMS Sites Details: Spreadsheet A

Line	Site Name	City	Site Code	Business Function	Site Server Name	Network Link to Parent	IT Staff
1	Central	New York	CCE	SMS central server	CENTRAL	n/a	Central
2	U.S. Region	New York	CUR	Headquarters	NEWYORK	LAN - 100-MB Ethernet	Regional
3	Japanese Region	Tokyo	CJR	Sales, etc. in Japan	TOKYO	T1	Regional
4	European Region	Paris	CER	Sales, etc. in Europe	PARIS	T1	Regional
5	U.S. Midwest	Chicago	CMW	Lab services, sales, etc.	CHICAGO	T3	Local
6	Duluth	Duluth	CDU	Testing	DULUTH	56 KB	None

Table 2b Contoso Pharmaceutical's SMS Sites Details: Spreadsheet B

Line	Site Name	Parent Site Code	Initial SMS Version	Planned SMS Version	SQL Server Version	Windows NT Server Version	Client Mix	Client Count at Site	Clients Report to This Site
1	Primary	n/a	None	2.0	7.0	4.0 SP4	n/a	0	14,000
2	Primary	CCE	None	2.0	7.0	4.0 SP4	Win95 Win98 WinNT 4.0	50	12,000
3	Primary	CCE	None	2.0	7.0	4.0 SP4	Win95 Win98 WinNT 4.0	650	650
4	Primary	CCE	None	2.0	7.0	4.0 SP4	Win95 Win98 WinNT 4.0	1,300	1,300
5	Primary	CUR	1.2	2.0	7.0	4.0 SP4	Win95 Win98 WinNT 4.0	100	100
6	Secondary	CMW	1.2	2.0	n/a	4.0 SP4	Win95 Win98 WinNT 4.0	20	20

Documenting Details about Contoso Pharmaceuticals for SMS Planning

When they finished collecting details, John Fortune and the other senior members of the SMS Team were ready to fill in the SMS-specific parts of the SMS Sites spreadsheet. One of their first jobs was to assign a unique site code to every site. They decided to use the two most prominent letters from each site name, with "C" as the first letter. John knew that if CP ever merged with another company, this would help set apart CP's original hierarchy.

After they assigned site codes, the SMS Team filled in the parent site column for each site, following the reporting hierarchy of the company, which was also reflected in the network links. The next big step was to determine which sites would be primary sites, and which would be secondary sites. The SMS Team followed the usual SMS logic of putting primary sites wherever there were local computer administrators, so that the administrators could manage both their own computers and the computers at subsidiary sites, but would not be responsible for computers that were managed by their peers. The SMS Team then produced an SMS Topology diagram, shown in Figure 2, which would allow everyone to quickly understand the planned SMS hierarchy.

Figure 2: SMS Topology diagram for Contoso Pharmaceuticals

Sizing SMS Servers

Now the team faces one of its most critical tasks—determining hardware requirements for each site. The SMS Team knows that every situation is unique and that there are no easy answers. It would be tempting to merely put a huge computer at every site, but with over 200 sites, that could be very expensive. The SMS Team needs to determine whether current hardware is sufficient or if upgrades are necessary. In some cases, CP will have to purchase new hardware, but even then they want to hold their costs down. And yet, the CP staff knows that one of the easiest ways for the project to fail is to depend on hardware that is insufficient and doesn't allow SMS to do its job.

The SMS Team has a variety of issues to consider and decisions to make concerning hardware sizing questions. They also have an assortment of tools to help them as they're considering deployment issues and deciding how to size their hardware. John Fortune refers to the issues in the following list as a summary of the items his team must consider:

• Budget constraints

• Discovery methods used

• Hardware and software inventory frequencies

• Hardware and software inventory sizes

• Network capacity

• Other applications

• Peak periods

• Reporting

• SMS features used

• Site size

• SMS overhead

• Software distribution

• Software metering

• User community

Note: These issues, which should be considered when sizing SMS servers, are discussed in detail in this white paper.

When John Fortune and the other senior SMS Team members wanted to learn about SMS capacity planning, they turned to chapter 3, "Planning for SMS in Your Organization," in the SMS 2.0 Administrator's Guide. They found that chapter 3 had great information, including conceptual overviews and disk considerations. Another good resource was the Microsoft® Systems Management Server Resource Guide (which is referred to later in this paper as the SMS 2.0 Resource Guide) in the Microsoft® BackOffice® 4.5 Resource Kit, especially chapter 2, "Designing Your SMS Site Hierarchy and Running the Pilot Project." Pages 17-31 were especially useful, and they included results from Microsoft's scalability lab testing, indicating what size computer was needed to handle certain types of loads. Other helpful subjects in the chapter included using specific tools to analyze performance and adjusting servers to improve system performance.

The SMS Team knew that it would have to do some of its own testing, because the information in chapter 2 of the SMS 2.0 Resource Guide was about dedicated SMS servers, and the team wanted some servers to serve other multiple applications as well, such as file or print serving, domain controlling, or serving Microsoft Exchange.

The team also wanted to know how some of their servers—those that didn't sufficiently match the ones in the tables—would handle expected SMS loads. John consulted chapter 11 in the SMS 2.0 Resource Guide, "Configuring and Populating Pilot Sites," for its extensive information about simulating SMS loads. Chapter 14, "Using SMS 2.0 Tools — Part 2," pages 412-414, supplemented chapter 11 well, and even discussed a special tool—SMS Console Load Simulation Tool—which simulates the activity of a number of SMS administrators using SMS.

Determining Site Requirements

Before the SMS Team could determine their server sizes, they needed to determine the requirements at each site. They also had to realistically assess how well each server would handle its workload. And, they needed to determine the nature of the workload itself; that is, how consistent and predictable it would be, as well as what specific types of functions it would include. To a large extent, the nature of the work at each site and the business goals of CP would determine the answers to these questions.

Acceptable Performance

John Fortune and the other senior SMS Team members realize that computer performance can be difficult to evaluate. They know that performance can change as loads change. They also know that poor performance in the middle of the night is not nearly as serious as mediocre performance in the middle of the day when a vice president is trying to get a report produced. Therefore, John's first goal is to answer the question, "What constitutes acceptable performance for Systems Management Server at Contoso Pharmaceuticals?"

Is the Performance Acceptable to the Users?

John believes the answer to this important question is ultimately determined by the users of SMS. But who are the SMS users?

End Users

One obvious category of SMS users is the end user. However, end users only use SMS to receive software distributions, to get help with SMS remote tools, and to get licenses from SMS software metering. These users are also affected by SMS discovery; client setup and configuration; the inventory collection processes; and the monitoring aspects of software metering, even if they have no active involvement themselves. However, except for software distributions and client setup and configuration, the performance of these functions is primarily determined by client computer performance, which involves a different set of issues that John isn't considering today. Software distribution performance will be strongly influenced by the performance of SMS distribution points and to a small degree by the performance of client access points (CAPs), but the CAPs will have a more significant impact on client installation and discovery. SMS logon points will also greatly influence client installation and discovery.

Knowing these facts, John ensures that the distribution points are adequate for the big software distributions that the SMS Team will occasionally send out. He also ensures that the SMS logon points and CAPs have adequate capacity to accommodate many clients being discovered and set up at the same time. However, John also recognizes that the SMS Team must use appropriate strategies for software distribution and client setup in order to ensure that too many users won't download software at any given time.

Help Desk Staff

Another important category of SMS users is the help desk staff and others who will use SMS to help end users solve problems. Such people will do a variety of tasks to help users, including:

• Finding a user's machine and then initiating a remote control session.

• Looking up the configuration details of user machines, including hardware and software inventory details.

• Checking the status of software distributions to specific users.

• Distributing software to a user in order to fix a problem.

• Checking software metering issues.

The people helping end users will often have the user on the phone while they're trying to fix a problem. To give users the best service, system performance must consistently be very good. John knows that most of this activity takes place during traditional business hours, and almost all of it involves primary site servers.

Server Administrators

Another SMS user group similar to the help desk staff is the server administrators. These people are not necessarily SMS administrators, or administrators of SMS servers, although there might be some overlap. For the most part, these are administrators of Windows NT file and print servers, domain controllers, Microsoft® Exchange servers, and a wide variety of other servers. This group will use SMS in much the same way that the help desk staff does, but they will do so for their own purposes, rather than for helping specific end users. They will also use Health Monitor and the other SMS network monitoring tools. Because they will use SMS in much the same way as the help desk staff, their performance considerations will be about the same, although this group will probably be more tolerant of occasional performance problems.

Reporting Customers

A big part of John Fortune's vision for CP's use of SMS is providing information about the company's computer resources to the people who require that information. This involves generating a wide variety of reports. Making the right reports available at the right times to the right people will be a challenge for the SMS Team. John wants to generate reports quickly, which means that performance must be fairly good. John can accomplish this goal by ensuring adequate performance on the primary site servers. However, John will also take into consideration the architecture that CP uses to generate reports, and he'll consider providing dedicated servers for reporting.

SMS Administrators

A group of users to which the SMS Team can particularly relate is the SMS administrators. These people will maintain and configure SMS, initiate software distributions, tailor inventory collection, and expand software metering, among other activities. All of these functions are dependent on the primary site servers.

Acceptable Performance on SMS Servers

In terms of user happiness, John can see that good SMS performance is chiefly a matter of good primary site server performance, and, when needed, good performance on the distribution points, CAPs, and SMS logon points. Performance constraints on secondary site servers or component servers only matter when performance is so bad that a server becomes a bottleneck. If a queue of SMS work forms at those servers and the server can't catch up in a reasonable amount of time, then it's considered a serious problem.

SMS Activities that Affect SMS Server Performance

When John Fortune and the SMS Team looked at SMS 2.0 activity on the SMS servers, they found it useful to examine different aspects of SMS server activities in isolation. They found that pages 29-31 of the SMS 2.0 Resource Guide provided a good overview of activities that occur at CAPs, distribution points, and software metering servers. They also examined the system flow charts, especially those in chapters 17, 20, and 23 in the SMS 2.0 Resource Guide, which provided details on the flow of activity of Discovery Data Records (DDRs), hardware and software inventory MIFs, and status messages, respectively. Having reviewed this, they came up with a list of activities that might particularly influence SMS server performance, as follows:

• Loading DDRs. Each DDR is relatively small by itself, but when many clients are discovered on a regular basis, this activity can use a lot of system resources. Discovery activities affect both primary and secondary site servers, as well as CAPs. Various discovery methods are available, including the regular Heartbeat Discovery. Activity level depends on the combination of methods used and the frequency at which they are used, along with the number of clients involved.

• Loading hardware inventory. A full hardware inventory can be quite large, and when many clients upload data to CAPs at the same time, the load can be quite significant. Fortunately, SMS 2.0 calculates the difference between the current and previous hardware inventory (called a delta) at the client, and then uploads only the difference between the two inventories. Hardware inventory frequency is set on a site-wide basis.

• Loading software inventory. This is done much like the hardware inventories.

• Reporting. Reporting is done at the discretion of SMS 2.0 users, but since many people will undoubtedly require SMS information in various forms, the SMS reporting function is essential. Requirements for SMS reports are extremely varied, and approaches taken to produce them often vary greatly. The SMS reporting function can often use considerable system resources, because much of the database might need to be scanned, but reports can usually be generated over a wide range of times so that an SMS site server is not essential.

• Moving files between CAPs and site servers and between SMS logon points and site servers. Various kinds of files must be moved to reflect configuration changes, software distributions, client activities, and so forth. The activity pattern can be quite complex due to the interaction of many different components. This activity can be considered constant over time. However, more CAPs and logon points will increase this workload on the site servers.

• Distributing software from site servers to distribution points. One of the most important steps in distributing packages with SMS is getting the software to the distribution points. For large packages, this can be a significant load on the servers and network, but the load can be managed by controlling distribution times.

• Distributing software from distribution points and CAPs to clients. Client computers will poll the CAPs on a regular basis to determine if any new advertisements are available. The polling frequency is set on a site-wide basis. Each client accesses a small number of small files, but depending on how often this occurs and the potential number of clients involved, this activity could be substantial. When clients execute advertisements, there is considerable activity as the software is downloaded from the distribution point. When a lot of software is distributed in a fairly short period of time, there is also considerable activity from status files being uploaded.

• Refreshing and changing client configurations. Client computers will review their SMS configuration against the settings at the CAPs every time they are rebooted, or every 23 hours, whichever comes first. The review itself will consume some resources, but if software changes are required, there will be more substantial activity.

• Maintaining databases. Various SMS database maintenance tasks must be done on a routine basis to ensure that SMS runs efficiently. SMS performs various tasks automatically to maintain the databases, but their frequency can be adjusted and other tasks can be added.

• Collecting status messages. Various SMS activities report their status on a routine basis and as required, so that SMS administrators are aware of their status. Activities that report their status include SMS Executive components at all site servers, package distributions, and advertisements.

• Communicating between sites. Site-to-site communications is an SMS feature that has one of the largest sets of configuration options, through the control of addresses and senders. The load is usually most significant on the wide area network (WAN) links, but there is some load on the sending and receiving servers. This is especially true when a site is sending to multiple sites simultaneously.

• Software metering, server-side functions. A variety of tasks are required for software metering on the server side. Beyond basic metering functions, there might be activity due to license balancing, which is highly configurable.

• Software metering, client-side functions. Software metering activity can be considerable when an online mode is used, which allows license enforcement. Software metering is considerably less active when the client is being used in the offline mode.

• Summarizing status messages. The status subsystem summarizes the collected status information in order to make it more useful to the SMS administrator. This summarization process takes some processing and will result in queries and updates to the SMS site database. The summarization process is highly configurable.

• Network monitoring, health monitoring, remote control. Remote control and monitoring activities refer to SMS site systems during initiation and when verifying security (in the case of remote control), but otherwise the load is carried only by the network, the SMS Administrator console, and the client computers. With network monitoring, however, the computer running the network monitoring agent, rather than the client computer, carries the load.

Many of these activities are dependent on how CP chooses to use SMS. These activities are also configurable, often with a tradeoff between timeliness and performance. (See chapter 2 of the SMS2.0 Resource Guide for some details on these considerations.)

Assessing Site Hardware Requirements

With SMS activities that affect performance in mind, the SMS Team must assess the specific workload that will be created by SMS. They can then go on to size the servers to accommodate that workload.

Assessing SMS Activity Levels

With their understanding of Systems Management Server activities, the SMS Team must now estimate the degree to which these activities will be performed at each site. They begin their analysis by determining how many computers at each site will be managed by SMS, and whether there will be computer specialists who will use SMS for special functions. They also determine whether all the users work the same shift and start at the same time. The SMS Team collects other relevant details, including how often inventory and software distributions will be required at the site. They also know that an important factor in assessing SMS site requirements is the number of client computers reporting to the parent site from child sites.

From an understanding of the number of end users at the site and the discovery methods that are enabled, the SMS Team estimates the number of DDRs that will be produced each day and each week. They also estimate whether those DDRs arrive at the CAPs (and then at the site server) on a well-distributed basis or in clumps.

If there are technical computer specialists at the site who will use SMS 2.0, then the SMS Team must factor into the workload such activities as queries against the SMS site database from SMS Administrator consoles, additional reporting activities, and possibly extra software distributions.

Because the team understands the types of users at the sites, they can estimate the software distribution activity that will occur. If the users have very similar, simple needs, then few packages will be required, and advertisements will rarely be sent out. But users who are very dissimilar will probably require many packages. If the users always require the latest software or have constantly changing needs, then many advertisements will be created.

Assess Impact of SMS Reporting

Another factor in assessing site requirements is the degree of management interest in the computer assets. If managers (and similar staff) want to keep a close eye on these valuable assets, or if they often make decisions based on details of the current computing environment, then many SMS reports will be necessary, and the reports might be complex. It might also be appropriate to increase the frequency at which hardware and software inventory is collected, so that they are even more up-to-date. This will increase the load on the SMS servers.

Assess Impact of the SMS Features Used

The particular SMS features that are used and how they are used will certainly affect the SMS workload. For instance, software metering will add a load, and frequently balancing licenses between servers and sites will increase the load again.

A powerful feature of SMS is the ease with which it can be extended, as discussed in the SMS Software Development Kit. Some companies use SMS as part of their asset management system, and therefore extend SMS to collect serial numbers and other information that SMS would not normally collect. Depending on how complex these extensions are, they could impose an additional workload on SMS.

Even such details as how the SMS 2.0 client components are installed on each computer can affect performance. Some SMS client activities occur on a regular basis from the time the client is set up. Hardware inventory is a good example of these activities, especially when the inventory is configured for weekly updates. If all clients are set up at the same hour on the same day, then those weekly activities will kick in at the same hour the next week, and so on. If the clients are set up at the same hour, but evenly spaced over the days of the workweek, then the activity on any given day will be one-fifth of what it would be in the first scenario. This is true if clients are set up during user logon, and all users tend to come in at about the same time, but only certain users are enabled each day. If clients are set up at different hours throughout the day and spaced evenly throughout the week, then the activity in any hour would be one-fortieth of the first scenario, but it would be constant.

Assess Impact of SMS Configuration Used

Configuration of Systems Management Server components will have a critical impact on site performance if the components are not configured to produce their results at a fairly even rate over time. If there are peak periods during which a large number of inventory MIFs, status messages or DDRs arrive at the site server simultaneously, then the server will experience relatively poor performance at those times. John and the team know that they have to give consideration to how discovery methods and inventory agents will be configured, and when software distribution will be done. The same considerations have to be applied to child sites reporting to the parent site, keeping in mind time zone differences and sender configuration.

As an example of assessing a site, John looks at the CP European Region site, in Paris, which has 1,300 employees. Most of the employees have computers and there are various servers as well, so there are 1,300 SMS client computers. The Paris site uses Windows Networking Logon Discovery without any restrictions in the logon script, which produces one DDR with every logon. The SMS Team anticipates that this will average out to once per day per user. This site also uses Heartbeat Discovery with the default settings. It will also generate 1,300 DDRs over the course of the workweek. Network Discovery is enabled to run every other weekend, but for the most part it discovers servers and other devices that are permanently powered up, which leads to the generation of only a few hundred DDRs. Therefore, on most days, the Paris site will generate 1,560 DDRs, and one day every other weekend there will be about 300 DDRs. The DDRs will always be generated in a 2-hour or 3-hour time frame.

Hardware and software inventory will be run weekly at CP's Paris site, which is approximately 260 inventory MIF files of each kind every day, most of which will be deltas. The SMS Team expects to have one or two advertisements per week on average for each user. These will be packages such as antivirus data file updates, service packs for installed software, and internally developed applications for some users. Some packages will be needed for specialty applications, and a reasonable number of advertisements will be needed to reinstall software that could benefit from reinstallation. These activities will generate status messages as well, usually at the rate of one per transaction.

The Paris office has a fairly active local computer support staff of 15 people who provide computer services for the staff in French. The support staff uses SMS extensively to solve user problems and to provide local management and others with the reports they need. The Paris office has a reputation for being well managed and for expecting the most from their computers, since computers are so critical to the productivity of their workers. Therefore, the team expects that reporting demands and SMS Administrator console activity will be quite aggressive.

The SMS Team plans to use Windows Networking Logon Discovery and Client Installation, since this works well and is not labor intensive. They'll only set up 100 clients each day, to have a manageable network load as clients are installed, and the site setup for clients will occur over three business weeks. Almost all users arrive for work between 7:45 and 9:15 A.M., so the team expects to see a lot of SMS discovery, client setup, and inventory activity happen until 10:00 A.M. each day. The SMS servers might build up a queue of activity that doesn't get fully processed for some time after this, but the team expects that the servers will complete this processing by 12:00 noon at the latest. The team will ensure that advertisements go out in the afternoons, and encourage users to run them in the afternoons. Throughout the day, administrators will use SMS for reporting, software metering, remote control, and its other features.

Sizing Servers Based on Microsoft's Test Results

With a good understanding of the CP sites, how each site plans to use and configure SMS, and the details of the workload the SMS servers will carry, the team has an excellent starting point for SMS server sizing. They can consult chapter 2 of the SMS 2.0 Resource Guide and look at the results of Microsoft testing. Microsoft tested a variety of SMS loads on a wide variety of server configurations, and has recommended the types of servers required for various SMS loads. John and his team studied those server recommendations.

With a large number of clients at the Paris site, the SMS Team will provide three servers as CAPs and distribution points. The site server will not be a CAP or distribution point, and it won't serve other applications either, such as domain controlling or file and print serving.

John Fortune and the SMS Team decided to more thoroughly analyze their site needs later, but to familiarize himself with the process, John considered the assessment of the Paris workload and checked Table 2.4 in the SMS 2.0 Resource Guide, which gives recommended site server hardware sizes for organizations (or sites) with up to 5,000 clients. The previous Table, 2.3, was only good for up to 500 clients, which was too small for the Paris site. CP expects to use discovery methods and advertisements much like those listed in the second half of Table 2.4. Even though John knows the Paris site has only 1,300 users, he is aware of the aggressive demands of these users, and believes he'll need a computer comparable to a Pentium Pro server running at 200 MHz, with three disk drives and 192 MB of RAM.

This kind of analysis is quite sufficient for server sizing purposes for many organizations. The issues and loads are well understood, and the organizations know what kind of hardware they are likely to need (discussed in chapter 2 of the SMS2.0 Resource Guide). The SMS teams for such organizations can be confident that they have adequate hardware and move on to other project tasks. However, spending a day or more closely analyzing their requirements and hardware sizing might still be very beneficial.

Sizing Servers Based on Your Own Test Results

For CP, John Fortune and the SMS Team know that they will need several hundred SMS servers, which is a considerable expense, even for a large multinational company. For this reason, they want to be sure that the hardware they use is sufficient for the job, while not being excessively powerful. To verify this, they want to reproduce a normal production load for the server setup in a test lab environment, and then observe how well the system handles that load.

Simulating SMS Activity in the Test Lab

In the lab, the SMS Team doesn't have to solve performance problems while users are trying to use SMS for actual work, but they also don't have hundreds or thousands of users to reproduce the effects of the eventual SMS clients. The SMS Team doesn't want to spend weeks watching the system for performance results through the course of normal business cycles. They need to simulate real SMS activity, including worst-case scenarios. If the system can handle the loads under those conditions, the team can be confident that there will be no surprises when they go into production.

An important task for the SMS Team is to produce a realistic model of how CP production will use SMS. The model is based on how SMS is configured and on how the team expects users to work at different sites. For instance, if users turn their computers off at night and log on in the morning at the same time, then any activities that occur during logon could put a dramatic load on the systems. If such sites use Windows Networking Logon Discovery, then many DDRs will be produced in a short period of time, and hardware or software inventory might follow soon after, depending on how the system is configured.

The BackOffice 4.5 Resource Kit includes scalability tools that produce the kinds of simulations the SMS Team requires. The team uses these tools to build a hierarchy on the site server without actually connecting many computers together. The team uses the tools to load the database and simulate the ongoing activities of an SMS hierarchy. They can escalate activity to simulate the times of day when the most activity is expected. They can also quickly reproduce their tests with minor configuration changes to see how those changes affect performance.

With all of this simulated activity, the SMS Team then monitors the proposed hardware to see if acceptable performance is maintained. When it isn't, they make adjustments to improve the system or lighten the load while still accomplishing the business goals. When the team determines that servers are more than adequate, they can scale them back before they submit purchase orders.

The SMS Team recognizes that simulations cannot reproduce all the activities that occur on a real system, but with a little thought the team can easily produce test plans to fill in the gap. They use SMS Administrator consoles to see how responsive the system is. They initiate software distributions, database maintenance, reports, and other activities to ensure that the system works well and produces results in a timely manner. The SMS Team then monitors performance carefully and looks for any problems that occur.

SMS Site Properties Manager

One of the important SMS 2.0 scalability tools in the BackOffice 4.5 Resource Kit is the SMS Site Properties Manager, shown in Figure 3. The SMS 2.0 Resource Guide describes the Site Properties Manager in detail in chapter 11, pages 261-266. The Site Properties Manager allows the team to reproduce the test environment exactly and to automate the testing of SMS with different configuration changes.

Figure 3: SMS Site Properties Manager

The SMS Team understands SMS well and knows the business goals that SMS must accomplish. On this basis they've determined configurations for the various SMS components. They set up test servers in the lab with the same configuration that the team plans to use in production. When the team begins scalability testing, they adjust various settings to assess the impact of those changes on system performance. Among their many options, they might:

• Set the component status summarizer to replicate at a higher priority or to not replicate to the parent at all.

• Set the site system status summarizer to replicate less frequently.

• Create more status filter rules.

• Set software distribution to use more threads or to retry less often.

• Set the Microsoft® Windows® Networking Logon Client Installation method to update the CAPs less frequently.

When the SMS Team has a server set up and configured, they use Site Properties Manager to save all the site settings to a file, as described in the SMS 2.0 Resource Guide. Then they make changes and test with the new settings. When this testing is complete, they can restore the site to its original state, confident that all settings are back to the intended values.

Another feature of SMS Site Properties Manager that the team finds useful is the ability to restore site settings on a schedule. This feature allows the team to configure the site fully and save the site settings to a file. Then the team can change a setting and save the site again to a different file. They can do this for as many variations as they want to test. Then they create tasks, using SMS Site Properties Manager to restore a different file every few hours. In the intervals, they use SMS Object Generator to send a constant load to the server and record the results using Performance Monitor. Later, the team can quickly review the test results to see what effect the different settings had on performance. Scheduling the restoration of different site properties files is also described in the SMS2.0 Resource Guide.

SMS Object Generator

The primary Systems Management Server scalability tool included in the BackOffice 4.5 Resource Kit is the SMS Object Generator. The SMS 2.0 Resource Guide thoroughly describes the SMS Object Generator and how to use it on pages 267-298. The SMS Object Generator allows the SMS Team to load the site server with data files and records to realistically mimic the files and records that client computers send to a production site server. These files are tailored to accurately simulate CP's own configurations. The SMS Team can evaluate performance issues while data is being loaded onto the site server and also when the data is used later for software distributions, database maintenance tasks, reporting, and other activities.

SMS Object Generator creates a wide variety of SMS objects, as shown in Figure 4. Not only are inventory MIFs and discovery data created, but also status files, site definitions, packages, and advertisements. Each kind of object has realistic properties set. The creation of these objects can be scheduled so that inventory MIFs are created after the corresponding DDRs, for instance. There can even be multiple combinations of schedules and properties for the same object. For example, inventory data can be produced for each site once per hour in the test hierarchy.

Figure 4: SMS Object Generator

To see how well the test servers would handle the load during the morning rush as users arrive for work at the Paris site, the SMS Team sets the SMS Object Generator to create:

• 300 DDRs every 10 minutes for an hour and a half, for a total of 2,700 DDRs.

• 25 delta hardware inventory MIFs every 10 minutes for an hour and a half, for a total of 225 (1,350 over the course of a week), arriving 5 minutes after the DDRs.

• 5 complete hardware inventory MIFs every 10 minutes for an hour and a half, for a total of 45, also arriving 5 minutes after the DDRs.

• 25 delta software inventory MIFS every 10 minutes for an hour and a half, for a total of 225, arriving 30 minutes after the DDRs.

• 5 complete software inventory MIFs every 10 minutes for an hour and a half, for a total of 45, also arriving 30 minutes after the DDRs.

• 100 status messages every 5 minutes for an hour and a half, totaling 1,800, to simulate the messages that would report the success (or failure) of these operations.

The SMS Team has two servers available for the Paris site; one is a 200-MHz 64-MB server with a 4-GB IDE drive, and the other is a 400-MHz 128-MB server with dual 8-GB SCSI disk drives on a fast and wide SCSI controller. The team prefers to use the less powerful of the two computers and save the more powerful one for other purposes, but they suspect its small amount of memory is not enough for the job. Microsoft recommends a computer similar to the less powerful one, but with 192 MB of memory and definitely no less than 96 MB, which is the next lower configuration in the Microsoft recommendations.

To make the final decision, the SMS Team configures both computers as SMS primary site servers with exactly the same options and configurations and no other applications. On a third computer, they install SMS Object Generator. They set up the above schedule, using the third computer to initiate the same operations on both servers at the same time. This way the team can use Performance Monitor to compare how both handled the same load. SMS Object Generator sends SMS files to two servers to simulate a morning rush of SMS activity. The results for both servers appear at the same time, as shown in Figure 5, and there is no question about how the two compared in performance. The dialog boxes generating files for the larger server are on the top half of the screen, and the equivalent dialog boxes for the smaller server are on the lower half of the screen.

Figure 5: SMS Object Generator sending files to two servers

The results reveal no noticeable differences between the two. Both computers passed the test without hesitation. Table 4 presents the highlights of the test results.

Table 4 SMS Object Generator Results

Test Parameter	Large Server Results	Small Server Results
Average number of DDRs processed per minute	300	300
Average number of hardware inventory MIFs processed per minute	30	30
Average number of software inventory MIFs processed per minute	30	30
Average number of status messages processed per second	4	4
Peak number of status messages processed per second	12	17
Average time to process 100 status messages	25 seconds	25 seconds

As the table shows, both servers performed virtually the same because neither computer was pushed to its peak capacity. Both servers processed all the data easily and quickly, with queues of files existing for no longer than 30 seconds, regardless of what types of files arrived or in what combinations. Given these results, the team is confident that the smaller server can handle the morning rush at their Paris site. To test for maximum throughput, the team decides to run a similar test and to increase the number of files and the frequency of generation until the servers can no longer keep up with the SMS processing queues.

The SMS Team also uses SMS Object Generator to simulate the processing of 500 or 1,000 status files arriving in a short period of time, as might happen after an urgent or popular software distribution has been run. They also use the SMS Console Load Simulation tool and other techniques to simulate additional activities. They use the results of these tests to adjust their choice of server or its configuration if necessary.

SMS Console Load Simulation Tool

When the SMS Team sets up a test server with an Systems Management Server 2.0 hierarchy appropriate for the test site and loads it with test data, they are ready to simulate the activities that the computer would normally be expected to process. Such activities include loading hardware and software inventory MIFs, DDRs, and other data that will come into the SMS server through the course of normal working days. With this setup, they're ready to test what it might be like to use SMS Administrator consoles at that site. CP will have many help desk personnel, SMS administrators, and others working with the SMS system through SMS Administrator consoles, and the console activity itself puts a load on the site server. For the system to be efficient, all of those workers must be able to get responses in a reasonable period of time.

The SMS Team could have set up a number of SMS Administrator consoles, staffed by team workers, to conduct the test, but this would have been quite labor intensive over the course of an extended test. Instead, the team uses the SMS Console Load Simulation tool to conduct their tests. As shown in Figure 6, this tool sends a variety of queries to the site server, simulating basic SMS Administrator console activity. Collections are then retrieved with their details, hardware details are extracted, the status of various SMS configuration options are checked, and a wide variety of other activities are performed. Even at the low setting, the SMS Console Load Simulation tool can simulate the activities of up to ten people working continually with SMS. At higher settings the simulated load more than doubles, and it can be doubled again.

Figure 6: Console Load Simulation tool

Knowing that the Paris site will have 15 local computer support staff, most of who will find SMS invaluable in performing their job, the SMS Team sets the SMS Console Load Simulation tool at low stress level. They do this while SMS Object Generator is providing the site server with the kind of load expected at the site.

With the SMS Object Generator simulating the morning rush, as shown in Figure 5 earlier in this white paper, the team sees that both servers behave the same as before. The CPU was busier overall, but not excessively.

Simulating Other SMS Activities

Even with the great scalability testing tools that the BackOffice 4.5 Resource Kit provides, the SMS Team knows that it can't simulate all SMS activities. However, with a little ingenuity they can simulate some of the relevant activities in other ways and have a complete picture of SMS performance with their hardware in their projected environment.

Some SMS 2.0 activities are Windows NT file server activities. For example, installing Microsoft® Office 2000 from a distribution point is identical to installing Office 2000 from a regular Windows NT file share, except that SMS distributions also generate status MIFs. Recognizing this, John Fortune and the team plan to simulate distribution point, CAP, and SMS logon point activity by estimating the amount of activity they expect. They estimate this activity in megabytes per hour and megabytes per minute (in worst-case scenarios) and then copy files to and from representative servers in the appropriate quantities and for the appropriate lengths of time. They then monitor both server and network performance to ensure that both are capable of supporting the loads.

Reporting can be a very resource-intensive activity, so John wants his team to seriously test the reporting performance. With the sample data produced with SMS Object Generator, the team can simulate the activity of any report generation fairly closely. The main questions for the team are:

• When will the reports be run?

• How many reports will be run at any given time?

• How will the reporting system be designed (if Crystal Info for SMS is not used for all reporting)?

When these questions are answered, and some sample reports generated, then the reports can be manually initiated to simulate reporting activity.

The team gives similar consideration to database maintenance, status summarization, and similar activities. These activities are easy to initiate in a test environment, so the only substantial work is to ensure that the database is loaded with realistic data.

To simulate software metering online mode activity, the SMS Team uses a few clients to open and close applications as quickly as possible. To simulate offline activity, they capture an offline mode data file and submit it from many clients simultaneously and repeatedly. When the team initiates the simulated SMS activity, they want to see how the activities impact the perceived performance of the servers, and they want to generate quantitative data as well.

Monitoring SMS Activity

With actual numerical data, the SMS Team can more accurately compare one server configuration against another, and can compare expected workloads with test workloads.

There are several specific parameters that the SMS Team is hoping to watch when they monitor server performance. Performance is usually reduced at the first level to CPU activity, memory activity, and disk activity. In some cases, network activity is also important. The SMS Team has read various books about computer performance tuning, and now they must learn what percentage of time the CPU is busy, how long the queue is at the CPU when there's 100 percent activity, how much hard memory page faulting occurs, and how large the input/output queues are on the disks.

In addition to these general computer performance numbers, the SMS Team wants to know how much SMS activity is being processed, especially at its peak. The SMS Team primarily looks at how many data files are received, processed, and loaded into the SMS site database. The team could have done this by using Windows Explorer or by executing DIR commands at a command prompt to watch the relevant SMS inboxes, but these techniques are time consuming when thousands of files are involved, and they do not lend themselves to automation. Fortunately, SMS 2.0 has performance counters to provide this data, as described in chapter 27 of the SMS 2.0 Resource Guide, "Using the SMS Perfmon Counters." In addition to Performance Monitor, the SMS Team finds that they can watch SMS performance with a variety of other tools, as described in the following sections.

Performance Monitor

The SMS Team is quite familiar with Windows NT and other Microsoft® BackOffice® products, and they have used Performance Monitor quite extensively. They find the SMS 2.0 Resource Guide has some good pointers on using Windows NT performance counters to monitor SMS server performance. These counters allow the SMS Team to have a good overall understanding of how busy the SMS server is and which products are the busiest. The team also finds Performance Monitor invaluable for watching disk activity and memory usage, for ensuring that disk activity is balanced, queues are reasonable, and hard memory page faulting is not excessive.

Monitoring SMS Components

The SMS Team also uses Performance Monitor to monitor the activity levels of various SMS components, such as the Scheduler, Inventory Data Loader, and Discovery Data Manager. When a particular component is consistently working hard and consuming many resources, the team concentrates on improving the efficiency of that component. They also consider whether it really needs to be working as hard as it is. For instance, if software metering is working a lot and using many resources, presumably to balance licenses between servers and sites, but all the software metering servers always have more than enough licenses available, it might be possible to set software metering so it balances the licenses less often.

The SMS Team determines which SMS component is most active by adding all the SMS Executive instances in the Thread object to Performance Monitor. (It is possible to use the standard Windows multi-select options when adding instances to a Performance Monitor chart, so adding all the threads is very easy.) They then use a common Performance Monitor trick, which is to press the BACKSPACE key once. This activates a feature that changes the graph line for the currently selected performance counter into a white line. They then quickly scroll through the long list of counters and, when the graph line they're interested in turns white, they know they have the right counter, and the busy SMS component they want to isolate. Figure 7 shows Performance Monitor monitoring all of the SMS components. Note that the white line and the thread number 12 (or instance 12) are selected.

Figure 7: Performance Monitor

One complication for the team when they are monitoring SMS components is that the components have thread numbers in Performance Monitor, but the SMS Team thinks of them in terms of their SMS 2.0 component names. To solve this problem, the SMS Team uses SMS_Threads.vbs (provided in Appendix B). An example of its output is provided in Figure 8. Notice that thread 12 is the SMS Inventory Data Loader (in this case).

Note: Appendix A briefly introduces Microsoft® Visual Basic® scripts and how to use them for accessing performance counters. This introduction includes details about compiling the requisite MOF file. An alternate method for relating thread numbers to SMS component names is provided in Appendix C.

Figure 8: The output from SMS_Threads.VBS

Caution: John Fortune always cautions his team to remember, when interpreting performance data, that a busy component is not necessarily a component requiring fixing. If there's a lot of work to do, then the component should be busy. Or, if other components are not getting the required disk inputs and outputs and are, therefore, not able to process, they might require tuning more than the currently active component does. For this reason, the SMS Team has to look very carefully at CPU-intensive SMS components to be sure that they're actually excessively busy before deciding to tune them.

Performance Monitor also has other options that the SMS Team likes. One is logging performance data to a file. Using this option, the SMS Team sets up testing for a weekend and then reviews what happened on Monday morning. Another option is using alerts, which notifies them when a performance counter reaches an unacceptable level.

Monitoring SMS Throughput

The SMS Team also wants to measure the actual work that Systems Management Server does. After reviewing chapter 27 of the SMS 2.0 Resource Guide and experimenting with various counters, they find that several performance counters are particularly useful:

SMS Discovery Data Manager

• DDRs processed/minute. The maximum rate, or number of DDRs, that SMS Discovery Data Manager can process in a minute. If real-time processing is required (no queue), then the maximum processed rate should be higher than the number expected to arrive at a site server at any time in the production environment.

• Total DDRs enqueued. How long the queue becomes when DDRs arrive faster than the SMS Discovery Data Manager can process them. This counter also makes it easy to tell when the SMS Discovery Data Manager processing rate goes down due to lack of work (as opposed to performance bottlenecks).

SMS Inventory Data Loader

• MIFs processed/minute. The maximum rate, or number of MIFs, that SMS Inventory Data Loader can process in a minute. If real-time processing is required (no queue), then the maximum processed rate should be higher than the number expected to arrive at a site server at any time in the production environment.

• Total MIFs enqueued. How long the queue becomes when hardware inventory MIFs arrive faster than the SMS Inventory Data Loader can process it. This counter also makes it easy to tell when the SMS Inventory Data Loader processing rate goes down due to lack of work (as opposed to performance bottlenecks).

SMS Software Inventory Processor

• SINVs processed/minute. The maximum rate, or number of SINVs that SMS Software Inventory Processor can process in a minute. If real-time processing is required (no queue), then the maximum processed rate should be higher than the number expected to arrive at a site server at any time in the production environment.

• Total SINVs enqueued. The length the queue becomes when software inventory MIFs arrive faster than the SMS Software Inventory Processor can process it. This counter also makes it easy to tell when the SMS Software Inventory Processor processing rate goes down due to lack of work (as opposed to performance bottlenecks).

SMS Status Messages

• Processed/second. The maximum rate, or number of status messages that are processed in a second. If real-time processing is required (no queue), then the maximum processed rate should be higher than the number expected to arrive at a site server at any time in the production environment.

Figure 9 shows the monitoring results on two servers tested during simulated peak morning activities. The period of activity is for the test shown in Figure 5 earlier in this white paper.

• The horizontal line at the 30 marker indicates the number of MIFs processed per minute, which has peaked at the maximum number of MIFs provided, rather than the maximum number that can be processed by either server.

• The upwardly diagonal thick line is the average number of DDRs being processed per minute on the smaller server. The number of DDRs being processed per second actually rises much faster, but because this counter is averaged per minute, it will rise and fall slowly. The almost vertical thick line starting at the same point is the number of DDRs in the queue at the smaller server. 300 DDRs arrived at essentially the same time, so it is not surprising that a queue exists.

• The downward diagonal line is the queue decreasing. Notice that the average DDRs processed per minute do not decrease at the same time, even when the queue gets to zero, because the counter is averaged over a minute.

• Thin lines, close to the center of Figure 9, mirror much the same behavior for the faster server. They start a little later because SMS Object Generator finishes generating one set of files before generating the set of DDRs for the faster server. Even so, the queue for the faster server is completed before the queue for the slower server is completed, but both complete so fast that there is no significant difference. Also, the DDR queue line actually went to zero twice, because SMS Object Generator hesitated when it was creating the DDRs for the faster server while beginning to create another set of files. That hesitation gave the SMS Discovery Data Manager on the fast server enough time to process the first half of the 300 DDRs it had already received.

Figure 9: Performance Monitor monitoring key SMS performance counters

With these counters, the SMS Team uses the SMS Object Generator to send simulated activity to the server and then watches how SMS processes the files. Files often are not processed immediately, causing the queues to grow, but they should be processed in a reasonable time period. The number of files that can be processed per day on the hardware can be determined by multiplying the average number processed in a given time period during the testing by the number of time periods in a day. For example, if an average of 50 DDRs can be processed per minute, then 72,000 DDRs can be processed per day. This should be adequate for any given site, but for a large organization with many sites, this might be inadequate for the central site. Note that Performance Monitor's Report view can also be particularly useful for watching the SMS performance counters.

Other Tools

John Fortune's SMS Team uses a variety of other tools to monitor SMS performance. These include:

• Qslice.exe

• SQL Trace

• Network Monitor

• SMS Status Subsystem

• SMS log files

The team finds that Performance Monitor is very effective and powerful because it can monitor multiple servers simultaneously, and it can monitor remotely. However, the team also finds that Performance Monitor requires some setup time to be used properly, and can be difficult to interpret sometimes.

When the team wants to determine which SMS components are currently most active, they find that the Qslice.exe file, from the Windows NT Resource Kit gives them answers very quickly. Figure 10 shows Qslice.exe monitoring SMS Executive Thread components. Notice that SMS Executive Threads F9 and 2BF are active. Qslice.exe shows them what processes on the server are busy, and by double-clicking on any one of these they can see which threads are busy within the process. For example, by double-clicking smsexec, they can see which components in SMS Executive are currently active. The only problem they have with this tool is that the threads are identified by thread ID's, which change at least every time SMS Executive is restarted. SMS_Threads.vbs solves this problem.

Figure 10: Qslice.exe monitoring SMS Executive Thread components

Because SMS uses Microsoft® SQL Server™ extensively, the SMS Team finds it very beneficial to understand SQL Server well. The SQL Server performance counters are definitely useful, but another tool the team finds valuable is SQL Trace, for SQL Server 6.5 and earlier (renamed to Profiler for Microsoft® SQL Server™ 7.0), as shown in Figure 11. This tool displays all the queries and other SQL Server activities being processed. It allows the team to see which SMS components are using SQL Server the most. If a SQL Server performance problem was suspected, the team could then investigate options to reduce the load from the most appropriate SMS components.

Figure 11: SQL Server 7.0's Profiler

SMS 2.0 can use a fair amount of network capacity, depending on system configuration. Between sites, SMS senders can be set to ensure that excess bandwidth is not used. However, no such controls exist within a site. In addition, if network links are already busy, SMS might not be able to get the capacity to perform its functions, even if its requirements are relatively low. To monitor these issues, the SMS Team used Network Monitor, as described in chapter 16, "Using SMS for Network Maintenance," of the SMS2.0 Administrator's Guide.

Other tools that the SMS Team uses to analyze system performance are the Status Subsystem and the SMS log files. These show when specific functions start and finish, so that the team can accurately match performance monitoring results to the specific activities being studied.

Caution: Monitoring a system requires some resources for the monitoring itself. For large computers monitored at a reasonable rate, the workload for the monitoring process should be insignificant. However, if you are monitoring many factors very closely, especially on smaller computers, or you are using resource-intensive tools such as SQL Server 7.0's Profiler, the performance test results might be worse than the computer can actually provide in normal operation.

Adjusting Workloads and Servers to Ensure Optimal Performance

With their strong understanding of the SMS requirements and their thorough analysis of the hardware required at each site, the SMS Team is very clear about what hardware they want for each site. Unfortunately, the reality is that they won't always have the budget to acquire all the hardware they would like. The team wants to be sure that they have planned their SMS hardware deployment as intelligently as possible, so that management can be confident that the SMS hardware budget is being used as efficiently as possible.

Fortunately, with a little creativity, the SMS Team can stretch their hardware budget quite far. They can upgrade current systems. They can use SMS efficiently, with only minor compromises on service levels. And, the team can ensure that they place hardware where it is needed most.

High-Level Strategies

The SMS Team has developed seven high-level strategies to ensure that they are using their systems as efficiently as possible.

• Configure SMS to run efficiently while still serving the business goals. The SMS Team, from its lab testing, knows how to configure their servers to process the maximum number of objects. However, the team found that there were additional strategies for optimizing SMS performance that were not apparent from their initial lab testing of individual machines. Those strategies are discussed in the following section, "Strategies for Optimizing SMS Performance."

• Concentrate the hardware investment on the resources that SMS is going to use the most. When purchasing new systems or upgrading current ones, invest the hardware dollars on the components that SMS is going to work the hardest. The use of hardware by SMS is discussed in "How SMS Uses Computer Resources" later in this paper.

• Put the hardware resources where the users are going to be the most sensitive to performance issues. Lab testing can never demonstrate this point, but it made sense when John Fortune explained it to the team. Some sites are going to have more high-profile users than others. Some sites will also be very demanding in their SMS usage, while others will merely run SMS in the background. Some sites will have very computer-aware users, who will be very conscious of SMS performance issues. These factors must be considered, and the best hardware must be placed where it will minimize the largest number of issues. In many cases this will have no adverse effect on the sites that get the less powerful hardware. For example, if a secondary site develops small occasional backlogs of SMS processing, it is unlikely that any business goals will be compromised.

• Ensure that there is capacity for the future. Demands on the system will increase for a variety of reasons. The SMS Team's customers will become more sophisticated as time goes on. SMS will have to manage more computers. Additional features might be implemented. Unexpected events will occur. If the servers have spare capacity, they readily accommodate these changes. If the servers are fully utilized when they are first implemented, then both company growth and greater system demands will cause SMS functions to suffer. Getting approval for additional hardware might be difficult, and retrofitting an existing implementation is always costly.

• Understand how SMS uses resources. In addition to understanding SMS by using previously discussed sources, the team found it important to better understand software metering and SMS's use of networks. These are discussed in the sections, "How SMS Software Metering Performs" and "How Network Issues Impact SMS Performance," later in this paper.

• Tune Windows NT and SQL Server. SMS is highly dependent on Microsoft® Windows NT® Server, SQL Server, the server hardware, and the network that connects the servers. Optimizing the performance of these components will increase SMS performance. The Microsoft®WindowsNT® Workstation 4.0 Resource Guide includes an overview of performance monitoring and analysis, with some suggestions for tuning Windows NT. These details are contained in chapters 9-16. The Microsoft® SQL Server™ Resource Guide includes suggestions for SQL Server performance considerations and relevant settings. Books on efficient network design are readily available in most computer bookstores.

• Use SMS best practices. This is discussed in the section, "SMS Best Practices To Avoid Performance Issues," below.

Strategies for Optimizing SMS Performance

Configuring and using SMS efficiently includes several strategies.

Optimize SQL Server

Based on what constitutes acceptable SMS performance, and especially what's important to various SMS users, John realizes that many SMS activities are merely different forms of getting information from primary site servers. In more technical terms, these are queries against the SMS site database. These queries originate at the SMS Administrator console, go to the Windows Management interface on an SMS site server, and in turn go to the SQL Server database. Many of the behind-the-scenes SMS activities involve loading data into the SQL Server database, or extracting information from the SQL Server database to transmit files to servers lower in the hierarchy. John can see that, to a significant degree, optimizing SMS is really a matter of optimizing SQL Server. Therefore, the SMS Team makes sure that it is well qualified to maintain SQL Server effectively, and they plan to do that maintenance regularly.

Use Separate Servers for Client Access Points and Distribution Points

Another approach to optimizing site server performance is to provide separate servers to serve as CAPs and distribution points. This not only has the benefit of taking a considerable load off the site servers, but it also gives the end users greater reliability, because when one server is down, others are available.

Schedule SMS Activities for Non-Peak Hours

As much as possible, the team schedules SMS activities when end users are not using the servers. Typically, this is overnight and weekends. Most SMS activities can be scheduled for convenient times. The only trick is to decide which activities could cause unacceptable delays or compromise business goals if they aren't run during peak hours. For instance, if there are times when SMS packages must reach all end users as soon as possible, then there must be an option to use the senders and related SMS components during normal work hours. This means that high-priority sending must be enabled during the workday.

Efficient Reporting

Analyzing the reporting strategy is critical for sites where reporting must be done. Reporting can use considerable resources and impact performance on even the heftiest hardware. An option to reduce this load includes putting the reporting function, and the data it requires, on a separate server. The data can also be summarized into smaller tables ready for reporting. For example, if users often want reports about the variety of operating systems in the company, in the different regions and at each site, then counts of each operating system by site can be placed in a table overnight, and users can request reports based on this relatively small, simple table in whatever combination of organization units they might require. They would need to access the full SMS site database only if they want to know the operating system for individual computers. The SMS Software Development Kit, available as part of the Platform SDK through the Microsoft Developer Network (MSDN), includes information on how to extract SMS data.

It might also be possible to give users the option to request reports at any time, with the understanding that the reports will be scheduled to run overnight and the results provided the next day. Often, when users are aware of this requirement to preorder reports, they can plan accordingly.

Use SMS Component Servers

In addition to dedicating a separate server to reporting, SMS 2.0 can also put senders and SQL Server on separate servers. Senders do the site-to-site communication for the various SMS components, and much of this communication is often postponed until quiet hours. Nonetheless, the workload of transferring many files, some quite large (as with some packages), can be considerable; isolating these activities on separate sender servers can reduce system load. The server on which a sender runs is determined when the sender is created in the SMS Administrator console. Using a separate sender server is particularly appropriate when there are many child sites directly below a parent site. However, reproducing the activity of a production sender server in the lab is very difficult for the SMS Team, and therefore, they want to watch such a server in production to see if it really does help decrease the site server workload.

Placing SQL Server on a separate server is always an option, but when the SMS Team tested, they found that it never increased SMS throughput (or the rate at which work can be done). Putting SQL Server on a separate server always decreased SMS throughput by 2 to 60 percent, depending on the hardware configuration and workload mix, with the typical decrease being around 10 percent. Generally, the team found that the greatest advantage of having SMS and SQL Server on the same server was seen on the most powerful hardware, and with the most easily processed SMS objects (such as DDRs).

The advantage was less dramatic on less powerful hardware, or when processing complex SMS objects, such as full hardware inventory MIFs. SMS communicates with SQL Server extensively for all of its functions. There are natural advantages to having SQL Server on the same computer as SMS, so that communications between them are direct, as long as the SQL files and SMS files are on separate physical drives or RAID sets. Putting SMS and SQL Server on separate computers does lower CPU utilization by up to 50 percent on the SMS server, but if there are no other CPU-intensive applications ready to use that capacity, then the unused CPU capacity is wasted. The SMS Team observed that the average network traffic between the SMS server and SQL Server, when the two were separated, never exceeded 300 KB per second, which is about half of the practical capacity of a 10-Base-T Ethernet. This network utilization was the worst-case scenario for an extremely large site, so normal activity for a typical site would be very small.

Maintain SMS

The SMS Team recognizes that one of its roles after deployment will be to maintain SMS itself. Systems Management Server will do many tasks automatically, but oversight is important to ensure successful completion. For example, the company will decommission computers when they become obsolete, and the corresponding SMS records will need to be deleted. Similarly, packages become irrelevant as newer versions or better alternatives become available.

Minimize Other Loads

Often, organizations want to use a server for multiple purposes. This is true for CP, where they expect the SMS server at the smaller sites to be a domain controller and file and print server as well. With sufficient hardware, accommodating such multiple roles is reasonable. But performance testing becomes more complicated because it's necessary to simulate the loads of the other applications simultaneously with SMS loads.

However, at large sites or at sites high in the SMS hierarchy, it is not advisable to have multiple applications on the SMS servers. Not only is testing more complicated in these situations, with loads being somewhat unpredictable, but tuning a server for optimal performance is difficult with different kinds of loads on the system, requiring at best a reasonable compromise between load requirements.

Another consideration is that SMS servers at larger or more significant sites must be reliable, but when they are used for multiple applications there is greater potential for problems or changes. A good example of a load that doesn't have to be on an SMS site server is Windows NT domain controlling. Similarly, file and print serving can also be put on separate servers.

How SMS Uses Computer Resources

John Fortune and the SMS Team put a lot of work into testing server performance. After testing a wide variety of systems with different loads, the team found certain common trends based on the resources available.

Memory

The SMS Team found that SMS 2.0 itself didn't particularly benefit from additional memory. Some was needed for the operating system, some for SMS as a server, and some for SMS as a client, but these needs could be accommodated comfortably with 64 MB of memory. Large secondary sites benefited from additional memory for file caching. Otherwise, additional memory did not particularly improve SMS performance. SQL Server, on the other hand, did require a reasonable amount of memory, and when more memory was provided, SQL Server performed even better. Secondary site servers could get away with 64 MB of memory, but primary site servers always needed a minimum of 96 MB. The team found that the main trick with SQL Server was to maximize the cache hit ratio, so that most of the data could be found in the relatively fast cache.

CPU

The team discovered that many simultaneous SMS activities used significant amounts of the CPU, but generally it was rare for CPU activity to be the cause of an ongoing bottleneck in processing.

Disk

Disk speed and the number of disks did not prove particularly significant in themselves. As long as input and output operations were spread evenly over the disks and RAID disk controllers, and memory was used efficiently, the disk input/output rate was usually sufficient. The most important issue with disks was to ensure that the queue lengths did not average greater than one (or one per disk in a RAID volume).

Disk Controllers and RAID

John Fortune and his team found that RAID disk controllers greatly enhanced SMS performance. They even found that RAID implemented in software was very beneficial, although John had some concerns about recovering volumes in the event of a breakdown. With the hardware RAID disk controllers, read and write caches were also found to be quite important.

The Windows NT 4.0 Workstation Resource Guide, especially chapter 14, includes details about the advantages of using RAID controllers.

The team found that RAID disk controllers with a single channel were always sufficient to handle SMS file processing. When a bottleneck was suspected in the disk subsystem, it was most likely because of the disks.

The team got the best results when they placed SQL Server logs, SQL Server data, and SMS itself on separate RAID 0 volumes. They concluded that RAID 1 volumes were slightly less efficient than RAID 0 volumes, and RAID 5 volumes were less efficient than RAID 1 volumes. The higher RAID levels were desirable for their fault tolerance, and adding more disk space compensated for any decrease in efficiency. Combining SQL Server data, logs, or SMS on the same volume also decreased efficiency.

How SMS Software Metering Performs

The SMS Team's testing shows that software metering server response time for online mode requests is independent of the number of clients attached. Rather, the response time is dependent on the number of application run-time requests. In other words, 300 clients, recording the invocation of one application each, create the same workload as 100 clients recording the invocation of three applications each. Testing also indicated that faster servers did not respond to software metering requests any faster than slower servers (the same was true with servers with multiple CPUs versus single CPUs). The team found that generally, as long as requests came in no faster than a sustained rate of five application requests per second, or 18,000 per hour, the software metering server could keep up with the workload. Additional software metering servers could handle additional workload, although this then introduced the complication of license balancing between the servers.

The team's testing also indicated that software metering server response time for offline work did benefit from a faster server, but adding CPUs to the server didn't help at all. Because of the nature of offline software metering, poor response from the server was not apparent to the client, so it was important only to watch for a queue of offline software metering data files. If the queue became excessively long, then it would be appropriate to upgrade the server.

One of the most important factors of good software metering server performance involves using a comprehensive exclusion list and maintaining it to reflect new applications. This ensures that clients make requests to the software metering server only when appropriate. However, the team knows that there is an additional load on the server when clients download the exclusion list, which occurs whenever the clients boot up, and every four hours thereafter, by default.

How Network Issues Impact SMS Performance

John Fortune understands the modular nature of SMS and that this is partially achieved when SMS moves files from one server component to another for communication. Examples of such activities include creating offer files for advertisements, moving MIFs to transfer inventory details, and transferring status files to communicate status information. Between servers, these files must all be transferred through traditional network file copy techniques and will consume some network bandwidth.

On a local area network (LAN), which usually has a lot of capacity, this network activity should not be significant. On a wide area network (WAN) it could cause problems, although SMS has senders to handle this traffic in an acceptable fashion. Senders can be configured to send files only during off-hours, or to use only a fraction of the available bandwidth. Senders also recover efficiently if a file transfer fails, and they can use alternate routes to the same locations.

Site-to-site traffic includes the following file transfers:

• Site Control Files. These files are transferred when site settings are changed, and they are transferred, once a day, up the hierarchy as a site heartbeat control file.

• Status messages. By default, all client status messages are replicated up the hierarchy at low priority, and all other messages at medium priority. The status filter rules and status summarizers for each site can finely control the replication of messages.

• Hardware inventory MIFs. Typically, these cover only changed details and are relatively small. Hardware inventory sizes can also be adjusted by collecting fewer details, as specified in the SMS_DEF.MOF file.

• Software inventory MIFs and collected files. Typically, these cover only changed details, and are relatively small.

• Discovery Data Records. These are replicated when they are created at the clients. The discussion of DDRs elsewhere in this paper (when looking at site requirements) explains when they will be created for each of the discovery methods.

• Collections. Collection lists replicate down to child sites, but only to sites that include a resource in the collection. Replication is done when collections are evaluated, which by default is done once per hour.

• Users and User Group DDRs. These are sent from all sites that have user or user group discovery enabled, to all higher sites. Therefore, only one site should be enabled per domain, if possible, so that multiple sites do not discover the same resources.

• Packages. These are sent during package distributions, which can be refreshed automatically if the package has this option enabled.

• Advertisements. These behave much like collections for sending purposes, but only when the advertisement is changed.

The SMS Team is very familiar with how much networking activity various SMS activities create, because a detailed analysis of the networking activity is included in the Microsoft Official Curriculum Course, Deploying and Supporting SMS 2.0 (number 828a), which all the senior and intermediate members of the team have attended. For example, a delta hardware inventory MIF creates 5 KB of network traffic, and a complete software inventory MIF creates 60 KB. Using the same techniques outlined in that course, the team can determine how much traffic specific activities will create. Then, by multiplying network activity by the amount of activity they expect to see at any given time, they can determine the impact of that activity on the network, and whether it will be excessive for their environment. The team can also use Network Monitor to analyze the pre-SMS workload on their LAN segments to see how much bandwidth is currently in use, and how much might be available for the SMS system.

As an example, the SMS Team has previously determined that they expect to see 260 delta hardware inventory MIFs at the Paris site each day between 7:45 A.M. and 9:15 A.M. At 5 KB each, this creates a total load of 1.3 MB. Over this morning period, the team figures that the 10 Mbps Ethernet LAN can process 4,050 MB, so the 1.3 MB is well under one percent of LAN capacity. This load is more significant over the 1.3 Mbps T1 link, to get these hardware inventory MIFs to the central site, but still uses less than one percent of that capacity.

SMS Best Practices To Avoid Performance Issues

The SMS Team now understands SMS 2.0 thoroughly due to their performance testing. When performance was worse than expected, the team investigated to discover why so many resources were being consumed. This led them to the following insights, which they plan to remember when using SMS.

Minimize SQL Server 6.5 Statistics Updates

One of their findings was that SQL Server 6.5 maintains statistics so it can optimize its processing. Although this is a valuable feature, the SMS Team found that updating these statistics can be quite resource intensive when done for specific objects, especially when SMS has generated many objects. They found that if SMS updated 10,000 objects and SQL Server then updated the relevant statistics, the computer would be extremely busy for approximately 15 minutes. This was unacceptable to the team, because the statistics weren't that valuable to them. For this reason they scheduled the statistical updates for after the workday and also looked for ways to turn them off at the object level. The team found that using SQL Server 7.0 eliminated this issue.

Avoid Complex Queries in Collections

One of the great new features of Systems Management Server 2.0 is the dynamic nature of SMS collections. Any new or changed computers, users, or user groups are added to the appropriate collections automatically. This allows the SMS Team to ensure that the right people are getting the right advertisements and other SMS services, and the team doesn't have to initiate manual adjustments to make this happen. However, the SMS Team found that some complex queries used in their more sophisticated collection definitions could require considerable resources. For this reason, the team studied these collection definitions to see if they could optimize them or update them less often, and still adequately achieve their business goals.

Another issue that the SMS Team plans to always remember is the workload created when advertisements are sent out. A collection that an advertisement is directed at can have many clients. Therefore, many instruction files might need to be updated. Also, because clients could be at any site, the instructions are made available at all sites, making the workload felt at all sites. Furthermore, collections get reevaluated, and then advertisement instructions must be updated to reflect any changes. As a result, some of the work must be repeated, as often as the collection is reevaluated.

Don't Log SMS Activities

By default, SMS 2.0 does not keep logs of its activities on SMS servers. Such logs can be useful for troubleshooting if the System Status subsystem does not provide sufficient details. The logs are enabled using SMS Service Manager. However, significant system resources can be used writing to the logs. The SMS Team found that, with an SMS site server running on a single IDE drive, the decrease in performance was as high as 10 percent. With ordinary SCSI disks the decrease was only six percent.

Avoid Creating Peak Periods of SMS Activity

One SMS 2.0 feature that the team thought would help them avoid performance issues actually created an issue. They wanted to set hardware inventory to be collected at 3:00 A.M., but for this to work, the inventories had to run on a particular day. Computers that were turned on at that time, including servers, would have their hardware inventory collected and completed at a time when no one would be bothered by this system operation. However, the team found that if most computers weren't turned on at 3:00 A.M., then the workload would actually occur the next time the computers were turned on. This usually meant first thing the next morning as users came to work. This applied to all the computers, because this was a site-wide setting. Morning is actually a time of intense SMS activity as DDRs are uploaded and client configurations are verified and udpated. Running hardware inventory at this time is not a good use of system resources. The SMS Team kept such implications in mind when scheduling SMS activities.

SMS Server Sizing at Contoso Pharmaceuticals

Having completed their analysis and testing, the SMS Team is now ready to size the servers for their sites. They use the detailed information on each site, apply the results from the Microsoft scalability testing, and adjust the servers according to their own requirements and test results. Figure 12 shows on which CP sites the team will size servers.

Figure 12: Contoso Pharmaceutical Sites for which servers will be sized

This resulted in the following table:

Table 5 Results of the Server Sizing Analysis at Contoso Pharmaceuticals Central Site

Site	Special Considerations	Servers Sized
Central No local clients 14,000 total clients 3 Administrator consoles	Primarily for reporting and some SMS administration DDR and inventory processing throughout the day	300-MHz Pentium II, 5 disk drives in RAID, 256 MB of RAM
European Region 1,300 local clients 1,300 total clients 15 Administrator consoles	Daily Windows Networking Logon discovery, Heartbeat Discovery, and Network Discovery on weekends Weekly hardware and software inventory MIFs 1 or 2 advertisements per week per user Aggressive use of reporting	200-MHz Pentium II, 3 disk drives, 128 MB of RAM 3 CAP and distribution point servers
Japanese Region 650 local clients 650 total clients 5 Administrator consoles	Same as European Region	166-MHz Pentium, single disk, 128 MB of RAM 2 CAP and distribution point servers
U.S. Region 50 local clients 11,000 total clients 10 Administrator consoles	Same as European Region High profile clients locally	300-MHz Pentium II, 5 disk drives in RAID, 256 MB of RAM 2 CAP and distribution point servers
U.S. Midwest 300 local clients 3,600 total clients 8 Administrator consoles	Same as European Region Less aggressive reporting 200 sites reporting to it	200-MHz Pentium II, 3 disk drives, 192 MB of RAM 1 CAP and distribution point server, small 1 sender server
Duluth Testing Facility 20 local clients 20 total clients No Administrator consoles	Same as European Region No reporting Servers will also be domain controllers and file and print servers	166-MHz Pentium, 2 disk drives, 96 MB of RAM

Central Site

The CP Central site is a true SMS central site, with no direct clients of its own. The server resides in the same building as the U.S. Region site, which does support fpr all its local clients and the sites reporting to it. Therefore, the Central site is much like the U.S. Region site, except that there is additional load from the Japanese Region and European Region sites, and less load because it does not directly support clients.

The Central site will be used for two purposes:

• Reporting for the entire organization

• Occasionally managing the entire organization

Management will be done with at most three SMS Administrator consoles, operated by the most senior SMS Team members. The SMS Team will do its best to ensure that reporting is performed overnight, but recognizes that the SMS server will probably be busy all day receiving DDR and inventory data from child sites. This is true not only because of the large number of clients involved, but also because multiple time zones are included, which means that the morning rush will actually happen many times throughout the course of the day in New York.

Each region will do most of its own SMS work, just as it handles its own business functions. Therefore, the SMS administrators at the Central site will provide reports to company executives, monitor the administration of the SMS system itself, and help solve the company's most complex problems.

Because most CP sites will be set up much like the Paris site (discussed throughout this paper, and especially in the site requirements section), the Central site can expect to receive one DDR for each of the company's 14,000 employees every day. Similarly, 14,000 hardware and 14,000 software inventory MIFs will be received each week, but most will be deltas. On average, sites will receive two or three advertisements per week.

The Central site server will not have any other applications running on it, including domain controlling.

The fifth section of Table 2.5 of the SMS 2.0 Resource Guide shows a load similar to that expected at the Central site, indicating that a 300-MHz Pentium II, with five disk drives in RAID, and 256 MB of RAM will be required at the Central site. Reporting is the only significant load at this site beyond the processing of SMS data itself, and the team is confident that with the right reporting architecture they won't have any special requirements.

European Region

The European Region site has been discussed at length throughout this paper, and the sizing of its servers is included in the discussion of sizing based on the Microsoft test results.

Japanese Region

The Japanese Region site in Tokyo is very much like the European Region site, except that it is smaller, with 650 employees.

The SMS Team expects that the Tokyo workload will be very similar to that at the Paris site, for the same reasons. The hardware listed in Table 2.3 in the SMS 2.0 Resource Guide seems quite appropriate for this site. However, since the Tokyo site is a little larger, and given the team's testing experience, they will put 128 MB of memory on a 166-MHz Pentium, single disk system.

The SMS Team will also be providing two additional servers to serve as both CAPs and distribution points.

U.S. Region

The U.S. Region site is located in New York, with the Central site, but it only has 50 local employees. CP is organized essentially as a holding company, and each of the regions does most of the real work of the company. The senior executives want to ensure accountability and consistency throughout the organization, but they do not directly manage it.

Even the U.S. Region office is essentially a holding company for the three sites that report to it: the U.S. Midwest site; the U.S. East Coast site; and the West Africa site. Therefore, the U.S. Region site is essentially the same as the Central site, except that it has 2,000 fewer clients, and a small number of high profile, upper management clients locally. The U.S. Region site will not have client data coming in throughout the day, because most of its clients are within two adjacent time zones. It also won't have nearly as much reporting to do. Given these considerations, the SMS Team has decided to set up the U.S. Region site with the same equipment as the Central site.

Because of the high-profile local users, the SMS Team will also be providing two additional servers to serve as both CAPs and distribution points. The site server will not serve these roles. These servers will be the smallest servers the team can find and are only provided to ensure that the local clients always have a server available.

U.S. Midwest

The U.S. Midwest site, located in Chicago, has 300 clients locally and 3,600 reporting to it from 200 secondary sites. It does not have a huge amount of basic SMS activity, but it does have a disproportionate amount of SMS administration to do.

The Chicago site is very similar to the Paris site, except that it will have more than twice as many clients. The SMS Team is expecting that the management demands will be less aggressive than those at the Paris site, but the administrative efforts will be greater, and therefore the Pentium Pro server running at 200 MHz, with three disk drives and 192 MB of RAM, should be appropriate. With twice as many clients, the SMS Team wasn't certain whether any adjustments would be required, but their testing confirmed that this configuration would support this load.

Because a large number of secondary sites are directly below the Chicago site, the SMS Team will also put a dedicated sender component server at this site, and observe whether it decreases the workload on the site server.

With only 300 clients locally, the SMS Team would like to avoid providing additional CAPs and distribution points. However, because the site server will be busy processing a fair amount of data and supporting administrative functions, the team has decided to place one separate CAP and distribution point there.

Duluth Testing Facility

The Duluth Testing Facility is typical of many small CP sites. It has only 20 employees. Because they are at the end of a slow network link, a secondary site server is appropriate.

Table 2.2 of the SMS 2.0 Resource Guide indicates that a 166-MHz Pentium server with a single disk drive and 96 MB of RAM will be adequate for this site. Fortunately such computers are readily available, and even more powerful computers will be quite affordable when new servers are required.

CP plans to use the servers at the smaller sites both as domain controllers and file and print servers as well. For a large organization like CP, domain controlling can require quite a bit of memory, so the SMS Team will make sure they have an extra 32 MB of memory. The file and print serving function requires disk space more than any other system resource, so to minimize conflicts, the team will make sure they have an additional disk.

Conclusion

CP's IT director, Kim Hightower, is very pleased to see that the SMS Team has done a thorough job preparing to deploy Systems Management Server, including sizing the SMS servers properly. She can see that they have thoroughly analyzed the company's business goals and environment and have learned how SMS processes its information.

Microsoft's scalability test results allowed the team to select computers that would serve their needs well, and they were able to do their own testing to simulate expected workloads on the specific hardware they planned to use. The team carefully observed the test results, looking for opportunities to improve system performance and determining the maximum workload that each configuration could handle.

Their experience and knowledge of SMS 2.0 allowed them to review CP's SMS hierarchy design to ensure that it would be efficient and would accomplish their business goals. The SMS Team made adjustments as efficiently as possible when necessary. Both the team and the company management can now move forward on the SMS project, confident that the system will perform as expected and on budget.

Appendix A: Using Visual Basic Scripts to Get Performance Monitor Thread Information

Scripts written in Microsoft® Visual Basic®, Scripting Edition (VBScript), much like Microsoft® Visual Basic® (VB) itself, can readily access objects and their properties and methods. When they do so, the returned results can be scanned through (in FOR loops), tested (using IF statements) to find the results of interest, and manipulated and formatted to provide meaningful results. VB scripts are especially useful with Windows Script Host, which allows them to be run from the command line, in batch files, or from shortcuts.

Windows Script Host provides objects to use commonly required computer elements, such as the display. Windows Management Instrumentation (WMI), which is installed on all SMS 2.0 computers, provides objects to manage computer systems, including performance counters.

An easy way for VB scripts to get Performance Monitor thread information is to access the Performance Monitor counters through WMI. However, before this can be done, WMI must have its Performance Monitor counter provider enabled, and the specific counters that are required must be defined. The MOF file provided in Listing 1 does these tasks. You must save the file as SMS_Threads.mof on the SMS server and then execute the following command:

MOFCOMP SMS_Threads.MOF

As soon as this is done, the VB script given in Appendix B can be used.

#pragma namespace("\\\\.\\root")
instance of __Namespace
{
Name = "perfmon";
};


#pragma namespace("//./root/perfmon")
instance of __Win32Provider as $PMPInst
{
Name = "PerfProv";
ClsId = "{f00b4404-f8f1-11ce-a5b6-00aa00680c3f}";
};  


instance of __InstanceProviderRegistration
{
Provider = "__Win32Provider.Name=\"PerfProv\"";
SupportsPut = FALSE;
SupportsGet = TRUE;
SupportsDelete = FALSE;
SupportsEnumeration = TRUE;
};


[dynamic, provider("PerfProv"), ClassContext("local|Thread")]
class Threads
{
[key]
String ThreadNumber;
[PropertyContext("ID Thread")]
uint32 ThreadID;
[PropertyContext("ID Process")]
uint32 ProcessID;
};


[dynamic, provider("PerfProv"), ClassContext("local|Process")]
class Processes
{
[key]
String ProcessName;
[PropertyContext("ID Process")]
uint32 ProcessID;
};


[dynamic, provider("PerfProv"), ClassContext("local|SMS Executive Thread 
States")]
class SMSThreadStates
{
[key]
String ThreadIDnName;
[PropertyContext("Running Thread Count")]
uint32 RunningThreads;
};

Listing 1 SMS_Threads.MOF

Additional information about Visual Basic is available in many books. Some books are available about Windows Script Host and Visual Basic scripts, and a good starting point is the Microsoft Web site, at https://msdn.microsoft.com/scripting/.

Information about WMI is available at https://www.microsoft.com/ntserver/techresources/management/WMIandCIM.asp.

The WMI scripting object is well documented in the WMI Software Development Kit, and is available at https://msdn2.microsoft.com/en-us/library/Aa394582.aspx.

Appendix B: SMS_THREADS.VBS

'SMS_Threads.vbs
'totally unsupported by anyone
'SMS_Threads.MOF must be MOFCOMPed prior to running this Visual Basic Script (with 
CSCRIPT)


Dim ThreadArray(50,3)
For i=0 to 49: ThreadArray(50,0)=0: Next


'figure out the SMS Executive process ID
Set Processes = 
GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").InstancesOf( "Processes" )
For Each Process in Processes
If Process.ProcessName="smsexec" Then
SMSProcessID = Process.ProcessID
End If
Next


'get the thread numbers and ID's for all the SMS Executive threads, using NT counters
Set threads = 
GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").InstancesOf( "Threads" )
For Each Thread in Threads
If Thread.ProcessID = SMSProcessID Then
ThreadNumber = RIGHT(Thread.ThreadNumber,LEN(Thread.ThreadNumber)-
INSTR(1,Thread.ThreadNumber,"]"))
'WScript.Echo "  ", ThreadNumber, SPACE(4-LEN(ThreadNumber)), 
HEX(thread.ThreadID) 
ThreadArray( ThreadNumber, 0 ) = thread.ThreadID
ThreadArray( ThreadNumber, 1 ) = HEX(thread.ThreadID)
End If
Next


'report header
Wscript.Echo "SMS 2.0 Component Thread Numbers, ID's, and Names"
Wscript.Echo ""
WScript.Echo "     Hex"
WScript.Echo "#  ID  ID  Name"
WScript.Echo "-- --- --- -------------------------------"


'get the names for all the SMS Executive threads, using SMS counters
Set Threads = 
GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").InstancesOf( "SMSThreadStates" )
For Each Thread in Threads
If Thread.ThreadIDnName <> "_Total" Then
ThreadID = 
LEFT(Thread.ThreadIDnName,INSTR(1,Thread.ThreadIDnName,":")-1)
ThreadID = RIGHT( ThreadID, LEN( ThreadID )-2 )
ThreadName = 
RIGHT(Thread.ThreadIDnName,LEN(Thread.ThreadIDnName)-INSTR(1,Thread.ThreadIDnName,":"))
ThreadNumber="n/a"
For i=0 To 49
If ThreadArray( i, 1 ) = ThreadID Then
ThreadNumber = i
ThreadArray( i, 2 ) = ThreadName
End If
Next
WScript.Echo ThreadNumber, SPACE(2-LEN(ThreadNumber)), ThreadArray
( ThreadNumber, 0 ), SPACE(3-LEN(ThreadArray( ThreadNumber,0))), ThreadID, SPACE(3-
LEN(ThreadID)), ThreadName
' Thread.RunningThreads 
End If
Next


'give whatever info we can on the threads that aren't listed in the SMS counters
Wscript.Echo ""
For i=0 To 49
If ThreadArray( i, 0 )<>0 AND ThreadArray( i, 2 )="" Then
WScript.Echo i, SPACE(2-LEN(i)), ThreadArray( i, 0 ), SPACE(3-LEN(ThreadArray
( i,0))), ThreadArray( i, 1 ), SPACE(3-LEN(ThreadArray( i,1)))
End If
Next
Wscript.Echo "Note, threads 0 and 1 do not have Execute Thread State counters and "
Wscript.Echo " therefore we don't have names for them"

Appendix C: An Alternate Method for Relating Thread Numbers to SMS Components

There might be times when SMS_Threads.vbs does not work. This will occur if WMI cannot access the SMS performance counters. In that case you can use the following script to relate thread numbers to thread IDs.

'SMS_Threads_Simple.vbs
'totally unsupported by anyone
'SMS_Threads.MOF must be MOFCOMPed prior to running this Visual Basic 
Script (with CSCRIPT)


'figure out the SMS Executive process ID
Set Processes = 
GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").Insta
ncesOf( "Processes" )
For Each Process in Processes
If Process.ProcessName="smsexec" Then
SMSProcessID = Process.ProcessID
End If
Next


'list the thread numbers and ID's for all the SMS Executive threads 
Set threads = 
GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").Insta
ncesOf( "Threads" )
Wscript.Echo " SMS Component Thread Numbers and Thread ID's"
Wscript.Echo ""
WScript.Echo "Thread # Thread ID"
WScript.Echo "-------- ---------"
For Each Thread in Threads
If Thread.ProcessID = SMSProcessID Then
ThreadNumber 
RIGHT(Thread.ThreadNumber,LEN(Thread.ThreadNumber)-
INSTR(1,Thread.ThreadNumber,"]"))
WScript.Echo " ", ThreadNumber, SPACE(4-
LEN(ThreadNumber)), HEX(thread.ThreadID) 
End If
Next

Listing 2 SMS_Threads_Simple.vbs

You can then use Performance Monitor to relate thread IDs to SMS components. To do this, start to add a counter to a chart, select SMS Executive Thread States as the object, and, for any of its counters, there will be an Instancelist that includes both the thread ID and component name.

A similar but more readable list of SMS components and thread IDs is available by using the Showperf.exe file from the Windows NT Resource Kit, as shown in Figure 13, and then by looking at the Instance list for the SMS Executive Thread States object.

Figure 13: Showperf.exe, from the Windows NT Resource Kit

Additional Resources About SMS

For more information about SMS 2.0 concepts, planning, and administration details, see Microsoft® Systems Management Server Administrator's Guide (referred to in this paper as the SMS 2.0 Administrator's Guide).

For more information about specific hardware sizing recommendations, some planning issues, and scalability tools, see the Microsoft® Systems Management Server Resource Guide (referred to in this paper as the SMS 2.0 Resource Guide), which is part of the Microsoft® BackOffice® 4.5 Resource Kit.

For more information about the network activity created by various SMS 2.0 activities, see the student lab manual of the Microsoft Official Curriculum Course, Deploying and Supporting SMS 2.0 (number 828a).

For more information about how to extract SMS data, see the SMS Software Development Kit, available as part of the Platform SDK through the Microsoft Developer Network (MSDN) at https://msdn.microsoft.com.

Additional Resources About Related Topics

For more information about Windows NT performance issues and the general process of performance monitoring and analysis, see the Microsoft® Windows NT® Workstation 4.0 Resource Kit.

For more information about SQL Server performance issues, see the Microsoft® BackOffice® 4.5 Resource Kit, which also includes the Microsoft® SQL Server® 7.0 Resource Guide.

For more information about Visual Basic, see most bookstores.

For more information about Windows Script Host and Visual Basic scripts, see the Microsoft Web site, at https://msdn.microsoft.com/scripting/.

For more information about WMI, see the Microsoft Web site, at https://www.microsoft.com/ntserver/techresources/management/WMIandCIM.asp.

For more information about WMI scripting objects, see the WMI Software Development Kit, available at https://www.microsoft.com/technet/sms/20/downloads/tools/sdk.mspx.