Appendix F - Capacity Planning for SMS Component Servers

After you have completed the preplanning phase, by using the methods described earlier in “Preplanning Phase” and after you have designed your SMS 2003 sites and hierarchy, your next planning step is to develop a model for server sizing, performance, and capacity planning. Many of the performance issues described about in this appendix apply to various components of your overall network configuration, including server performance, network performance, overall SMS performance, and operating system performance. Performance issues that relate to a specific component of your network configuration refer to that component directly, for example, server performance instead of just performance. You perform the tasks that are described in this appendix before you deploy your SMS site so that you can avoid performance issues in production. However, you should also consider these tasks to be ongoing administrative responsibilities that can keep your SMS implementation running optimally.

This appendix covers the following topics:

• Introduction to Modeling for Sizing and Capacity Planning

• Performance and Capacity Planning

• SMS Activities That Affect SMS Server Performance

• Sizing SMS Component Servers

This appendix includes an overview of SMS server sizing, capacity planning, and performance issues that you should be aware of, and it provides you with some tools that can assist you when you plan for server performance and capacity. Sizing and capacity planning guidelines include:

• Being aware of how data flows in the SMS hierarchy.

• Ensuring that the actual performance load that SMS generates is effectively managed by the hardware that is in use.

• Building SMS component servers with as much fault-tolerant hardware as economically possible.

• Ensuring that your capacity plan can adapt when your organization grows and changes.

This appendix represents one integral part of the planning process that begins with, “Preplanning Phase.” Understanding the basic concepts of SMS sites, features, and clients helps you generate a successful sizing plan. To benefit most from this appendix, you should be familiar with the following chapters in the .

• Chapter 2: “Understanding SMS Sites”

• Chapter 3: “Understanding SMS Features”

• Chapter 4: “Understanding SMS Clients”

It is also recommended that you use the Microsoft® Systems Management Server 2003 Capacity Planner available for download from the SMS 2003 Product Documentation Web page at https://www.microsoft.com/smserver/techinfo/productdoc. The Microsoft® Systems Management Server 2003 Capacity Planner is a tool that helps consultants, SMS administrators, and IT professionals perform scenario analysis on their existing and proposed SMS 2003 hierarchy. The Capacity Planner Tool User Guide included with the tool describes how to use the Capacity Planner. The Capacity Planner analyzes the input you provide and suggests SMS site topology configurations and corresponding hardware configurations for site servers and site systems.

Introduction to Modeling for Sizing and Capacity Planning

Every network implementation is unique. The same thing is true of every implementation of SMS. Like many server-based applications, SMS does not perform the same way in every environment. Many hardware factors contribute to the performance of SMS on your server, including processor speed, disk access, and available memory. The configuration of the SMS deployment — the number of SMS component servers and SMS clients you install, and the features you enable — also affects server performance. Nevertheless, with some basic information about transaction types, file sizes, and network use, and with some useful formulas, you can develop an effective capacity planning and server sizing model.

There are two strategies you can use to develop a capacity plan:

• Develop a planning model that determines the number and hardware configuration of SMS component servers, based on the number of clients that must be managed and the SMS features that are enabled.

• Develop a planning model that determines the available capacity of existing SMS component servers, based on the number of clients that must be managed and the SMS features that are enabled.

Include the following steps in any planning model you develop:

• Create a test lab to gather server and network performance data.

• Determine the number and configuration of site servers that are required for the site hierarchy and the number and configuration of site systems that are required for each SMS site.

• Generate measurement standards for server performance that you can use to evaluate and identify peak performance periods and potential performance bottlenecks.

• Generate service level agreements that define acceptable levels of server performance.

• Use the measurement standard and service level agreements that you develop to help you plan for optimum hardware configurations for your SMS servers.

• Plan for capacity before you deploy the SMS site, and then make that plan an ongoing process after deployment.

To avoid or rectify performance issues before they become serious, monitor server performance throughout the lifetime of the site, and make this part of your capacity plan for the SMS site. Modeling formulas can help you develop site capacity plans.

The following three sections can help you develop a capacity planning and server sizing model:

• Capacity Planning Terms and Definitions

• Capacity Planning Tools

• Modeling Principles for Sizing and Capacity Planning

Capacity Planning Terms and Definitions

Before continuing, it is helpful for you to understand some of the terms that are used in this appendix to describe the capacity planning process.

A model is a mathematical construct or formula that helps you understand how a physical system works within a defined set of parameters. Modeling typically uses a set of formulas that define performance characteristics, such as CPU utilization, transaction throughput, and transaction capacity. Because SMS server performance is affected by the type and number of transactions that SMS generates, these types of formulas are particularly useful. You can create a capacity planning model and use it to understand how SMS site servers and site systems perform, based on the design and configuration of the SMS site.

Server sizing means determining the appropriate kinds of hardware that are required to process a specific amount of data in a specific amount of time. Hardware considerations include CPU, memory, disk array, and disk space. For example, if you have 50,000 SMS clients processing one hardware inventory delta file every five days, how does that affect SMS site server and SMS site database server performance? How is the CPU, memory, and disk usage affected by that task?

When you are sizing servers and planning for current and future capacity, it can be difficult to define the service level agreement (SLA). The SLA represents the conditions of operation that all interested parties in a process agree upon. For example, the SLA might indicate that the SMS site server must experience no more than 85 percent utilization of server memory and must maintain a minimum of 15 percent available free disk space.

A service request represents a task that is processed by the server, such as reading or writing a file to disk, or adding a record to a database.

A queue length represents the number of service requests that are waiting to be processed by the server. In general, a small number — one or two — indicates that service requests are being handled in a timely and efficient manner.

A service chain represents all the hardware resources that are used when a transaction or a service request is processed. This is sometimes referred to as a process flow. The total response time for the service chain is the sum of the response times for each service, resource, and transaction in the service chain.

A load signature is the set of the performance metrics of installed server components on a specific computer hardware configuration. Load signature on SMS component servers is affected by a variety of factors, including SMS hierarchy design, SMS site configuration, enabled SMS features, maintenance task frequency, and numbers of clients. The load signature for each site server is unique and is determined by measuring the usage of the SMS site components and their impact on hardware resources throughout daily, weekly, and monthly business cycles. The software in use, its level of usage, and its impact on hardware resources determine the load signature.

Capacity Planning Tools

It is important to have the appropriate tools available to help you understand how the SMS component servers perform in different scenarios. It is equally important to know how to use those tools effectively.

The main tools that assist you in gathering server performance and network performance data are Windows System Monitor and Network Monitor, respectively. System Monitor is the recommended resource that is used for creating a server sizing model for SMS component servers. Use System Monitor to identify standards for acceptable server performance and to recognize periods of peak performance. The data that is collected is instrumental in both establishing and maintaining SLAs. Achieving this kind of analysis is a two-step process of baseline creation and real-time tracking. You create a baseline chart or log of acceptable server performance in accordance with the SLAs. You create real-time charts by using the same objects and counters that are used for the baseline chart, and then you compare them to the baseline charts to determine how server performance has been affected. Recommended System Monitor objects and counters are described later in this appendix.

Network Monitor 2.1, included with SMS 2003, makes it easier to monitor and analyze network traffic that is generated among computers in the network. You use Network Monitor to identify heavily used subnets, routers, and WAN connections, to recognize where network bottlenecks occur, and to develop trends to optimize the network infrastructure and placement of SMS site servers and SMS site systems. For more information about how to install and use Network Monitor, see Chapter 10, “Maintaining and Monitoring the Network,” in the Microsoft Systems Management Server 2003 Operations Guide.

It is also recommended that you use the Microsoft® Systems Management Server 2003 Capacity Planner available for download from the SMS 2003 Product Documentation Web page at https://www.microsoft.com/smserver/techinfo/productdoc. The Microsoft® Systems Management Server 2003 Capacity Planner is a tool that helps consultants, SMS administrators, and IT professionals perform scenario analysis on their existing and proposed SMS 2003 hierarchy. The Capacity Planner Tool User Guide included with the tool describes how to use the Capacity Planner. The Capacity Planner analyzes the input you provide and suggests SMS site topology configurations and corresponding hardware configurations for site servers and site systems.

As outlined in Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy,” reviewing and testing the SMS site design in a lab environment is an essential task to determine sizing and capacity parameters within the network environment. Running a pilot project within the boundaries of the production environment, affected by the many external factors that can affect that performance, helps you identify how the network and servers perform within that environment.

Modeling Principles for Sizing and Capacity Planning

The first principle to consider when modeling for size or capacity is that you cannot determine appropriate hardware resource requirements without first creating a measurement standard for use of that hardware resource. Another way to look at it is that you cannot determine when the server is not performing optimally — or within the bounds of the SLAs — if you do not know how to measure optimal performance. The measurement standard is the baseline chart or log of acceptable server performance described in the last section of this appendix.

There are several books that describe modeling principles and formulas in great detail. Because the SMS site database is a SQL Server database, it is not unreasonable for you to consider applying many of the same principles and techniques that are used to determine appropriate hardware requirements for computers running SQL Server to your SMS component servers. For more information about modeling principles and server sizing formulas that are effectively applied to your SMS component servers, see Chapters 8-11 in the Microsoft SQL Server 2000 Performance Tuning Technical Reference, available from Microsoft Press.

Among the many performance objects that you can track, there are three primary performance objects that you can track to determine server size and capacity. These are:

• CPU utilization

• Disk utilization

• Memory (RAM) utilization

The key principle in achieving realistic and acceptable server performance is to avoid running the server at maximum hardware resource utilization on a regular basis. You must establish acceptable thresholds for hardware resource utilization to provide a reserve capacity for peak utilization periods.

CPU Utilization Thresholds

The relationship among CPU utilization, queue lengths, and response time is an important consideration when you are developing a sizing model for SMS component servers. There is a direct correlation between CPU utilization and queue lengths that affects the performance of a system. Generally, smaller queue lengths indicate better CPU performance. For most server configurations, queue lengths grow linearly until the processor reaches about 75 percent utilization as illustrated in Figure F.1.

Figure F.1   Graph of exponential queue length versus CPU utilization growth

At that point, queue length growth becomes exponential and rises quickly. This is referred to in some books as the asymptotic point. Whether your SLA stipulates 75 percent as a reasonable threshold between acceptable CPU utilization and a problem zone is up to you. As administrator, you are in the best position to understand the nuances of your own networking and server environment.

Assume that your threshold for acceptable CPU utilization is 75 percent. You should expect that, on occasion, CPU utilization greater than 75 percent probably occurs for short periods of time. Nevertheless, the longer or more often such periods occur, the more likely queue lengths and response time are adversely affected.

Disk Utilization Thresholds

Similarly, disk utilization tends to take an exponential turn at about 85 percent. For example, a 9 GB disk should not store more than 7.6 GB of data at any given time. This allows for growth and helps keep response times at a reasonable level. By the same principle, if a disk has a read/write capability of 70 requests per second, a constant read/write arrival rate of more than 60 requests (70×.85) per second in a steady state of operation indicates that the read/write capability of the disk is inadequate.

Memory Utilization Thresholds

Page faults occur when data cannot be found in memory and needs to be retrieved from disk. An operating system issues a page fault interrupt when a needed page of code cannot be found in its working set in main memory. The page fault interrupt prevents further processing until the required data has been retrieved from disk. Response time in memory is measured in microseconds (millionths of a second), whereas response time for disks is measured in milliseconds (thousandths of a second). This means that pages are retrieved from memory approximately 1,000 times faster than from disk. Consequently, to reduce the number of page faults that occur, you should increase the amount of memory in the computer.

Performance and Capacity Planning

Capacity refers to how well a server can adapt to increased demands, based on performance testing. Lab testing can identify capacity issues, such as network congestion that is encountered when the load on the SMS hierarchy increases. Capacity planning ensures that the actual load encountered by SMS is effectively managed by the hardware already in use.

It is critical that you plan for capacity and performance not only before you deploy SMS, but also as part of your post-configuration capacity planning. You cannot accurately determine what hardware is required to successfully deploy SMS, or whether the current hardware is functioning optimally (in accordance with existing SLAs) without tracking the performance of key server hardware resources — minimally CPU, disk, and memory. When you are planning for capacity and performance, ensure that the SMS component server hardware can handle increased capacity while your organization grows and changes.

You should be aware of how data flows in the SMS hierarchy — which data flows up from client to site system to site server to parent site (DDRs, inventory files, status messages, customized MIF information, and software metering data), and which data flows down from site server to site system and child site, and from site system to client (software packages, client installation components, and Advanced Client policy). See Chapter 2: “Understanding SMS Sites,” in the for a detailed description of data flow between sites.

You calibrate performance by measuring throughput as load changes on fixed hardware configurations or by measuring throughput with a fixed load on differing hardware configurations. You gather performance data when you do lab testing, and then you review the data when you create and modify your SMS site design.

Monitoring Performance

An important step in troubleshooting backlogs and spotting load problems is to regularly observe key System Monitor counters and compare their values against the measurement standard and SLA values you recorded. The System Monitor (Perfmon.msc), is a snap-in control for Microsoft Management Console (MMC). It reads software counters that are built into SMS, SQL Server, Internet Information Services (IIS) 5.0, and Windows 2000 Server. You can also use it to log counter activity and set alerts.

In addition to displaying information in a live chart view, System Monitor can log information to a file so that you can find load problems that occur at times when you are not monitoring the system. For more information about System Monitor, see the Microsoft Windows 2000 Server Resource Kit.

Key Objects and Counters

Table F.1 lists the key system objects and counters to monitor. Keep in mind that the percentages outlined in the table represent recommended values only. You should determine optimum values for your own servers.

Table F.1   System Monitor Objects and Counters

Object	Counter	Instance	Comment
Processor	% Processor Time	_total	Less than 80% means the level of processor performance is acceptable. Constant measurements above 95% mean there is cause for concern.
System	Processor Queue Length	Not applicable	Two or fewer means the level of processor performance is acceptable.
Thread	Context Switches/sec	_total	Lower is better. You measure the thread counter to enable the processor queue length counter.
Physical disk	% Disk Time	Each disk	Less than 80% means the level of physical disk performance is acceptable.
Physical disk	Current Disk Queue Length	Each disk	The count minus the number of spindles on the disks should average less than two. (A RAID device would have more than one spindle.)
Memory	Committed Bytes	Not applicable	If this value is smaller than the available amount of RAM, you have enough memory to support the running processes without excessive paging. If this value is consistently larger than available RAM, the computer is experiencing an unacceptable level of paging, and you must add more physical RAM.
Memory	Page Reads/sec	Not applicable	Constant measurements greater than five indicate a requirement for more memory.
SQL Server	Cache Hit Ratio	Not applicable	98% or greater is good because SQL Server queries are not delayed by paging off disk.

Disk counters are disabled by default, because on x86-based computers, counters use five percent of CPU time. On faster computers, the impact of disk counters on system performance is insignificant. Because you cannot monitor disk performance with the counters disabled, you should either run only the disk counters locally, or run all of the counters remotely. Until you enable the disk counters, they always report zero. You can enable the counters by running “DISKPERF -Y” from the command line and then rebooting.

Important

Disk counter values are not exact on servers using hardware-based RAID because the disk controller hides the disk queue length data.

Note

It is recommended that you run performance counters remotely to minimize the effect on the SMS component servers’ performance.

SMS Performance Counters

Table F.2 lists some of the pre-defined performance counters that are enabled when you install the SMS site server. Use these to track and log information about processes and tasks performed by SMS component servers and to help you determine load signatures.

Table F.2   System Monitor Objects and Counters for the SMS Site Server

Object	Counter	Description
SMS Discovery Data Manager	DDRs Processed/minute	The number of discovery data records (DDRs) that Discovery Data Manager processed during its most recent minute.
SMS Discovery Data Manager	Total DDRs Enqueued	The number of DDRs waiting in Discovery Data Manager’s input queue (the last time Discovery Data Manager scanned the queue), minus each DDR processed. When a large number of DDRs are being copied to the input queue, this count can lag behind the actual number waiting to be processed.
SMS Discovery Data Manager	Total DDRs Processed	The total number of DDRs that Discovery Data Manager processed during its current session.
SMS Executive Thread States	Running Thread Count	The number of running threads. These are threads that are not blocked inside the Yield() functions. When this counter is associated with a single thread, instead of an entire process, its value will be zero or one.
SMS In-Memory Queues	Total Objects Dequeued	The total number of objects that the source component has added to the queue since the source and destination components were last started.
SMS In-Memory Queues	Total Objects Enqueued	The total number of objects that the destination component has removed from the queue since the source and destination components were last started.
SMS Inventory Data Loader	MIFs Processed/minute	The number of inventory records (Management Information Format (MIF) files) that Inventory Data Loader processed during its last minute.
SMS Inventory Data Loader	Total MIFs enqueued	The number of inventory records (MIF files) waiting in Inventory Data Loader’s input queue (the last time Inventory Data Loader scanned the queue), minus each MIF file processed. When many MIF files are being copied to the input queue, this count can lag behind the actual number waiting to be processed.
SMS Inventory Data Loader	Total MIFs Processed	The total number of inventory records (MIF files) that Inventory Data Loader processed during its current session.
SMS Software Inventory Processor	SINVs Processed/minute	The number of software inventory records (SINVs) that Software Inventory Processor processed during its most recent minute.
SMS Software Inventory Processor	Total SINVs Enqueued	The number of SINVs waiting in Software Inventory Processor’s input queue (the last time Software Inventory Processor scanned the queue), minus each SINV processed.
SMS Software Inventory Processor	Total SINVs Processed	The total number of SINVs that Software Inventory Processor processed during its current session.
SMS Software Metering Processor	SWM Usage Records Processed/minute	The number of software metering records that Software Metering Processor processed during its most recent minute.
SMS Software Metering Processor	Total SWM Usage Files Enqueued	The number of software metering usage files waiting in Software Metering Processor’s input queue since the last time the Software Metering Processor scanned the input queue.
SMS Software Metering Processor	Total SWM Usage Records Processed	The total number of software metering usage files that Software Metering Processor processed during its current session.
SMS Status Messages	Processed/sec	The number of status messages SMS_STATUS_MANAGER processed in the most recent second.

When you install a management point in your site, a set of System Monitor counters specific to the management point are installed and enabled. Use those counters to help you track and log information about processes and tasks that run on the management point. Table F.3 lists some of the management point counters that are enabled.

Table F.3    System Monitor Objects and Counters for a Management Point

Object	Counter	Description
SMS management point DAL	Connections Created	The total number of database connections created by the management point.
SMS management point DAL	Connections created/sec	The number of database connections created by the management point per second.
SMS management point Get Policy	Cache hits/sec	The number of policy requests resolved from cache on the management point.
SMS management point Get Policy	Requests/sec	The number of policy requests generated per second on the management point.
SMS management point PolicyMgr	PA Requests/sec	The number of policy assignment requests generated per second.
SMS management point HINV Mgr	Delta Reports	The total number of delta hardware inventory reports generated.
SMS management point HINV Mgr	Report Size (Kb)	The average size of the hardware inventory reports generated during its current session.
SMS management point HINV Mgr	Total Reports	The total number of hardware inventory reports generated.
SMS management point HINV Mgr	Total Reports/sec	The total number of hardware inventory reports generated per second.
SMS management point SINV Mgr	Delta Reports	The total number of delta software inventory reports generated.
SMS management point SINV Mgr	Report Size (Kb)	The average size of the software inventory reports generated during its current session.
SMS management point SINV Mgr	Total Reports	The total number of software inventory reports generated.
SMS management point SINV Mgr	Total Reports/sec	The total number of software inventory reports generated per second.
SMS management point Status Mgr	Total Events	The total number of status messages generated during the current session.
SMS management point Status Mgr	Total Events/sec	The total number of status messages generated per second during the current session.

SMS Activities That Affect SMS Server Performance

When you monitor the performance of hardware resources on SMS component servers, you gain insight into the way the server processes information under different conditions. It is important to spot potential problem sources, and to develop and analyze performance trends under different conditions, before problems materialize. Achieving this kind of analysis is a two-step process of baseline creation and real-time tracking. It is useful to examine different SMS server activities and how those activities alone and in combination can affect server performance. You should familiarize yourself with the activities that occur at site servers and at each site system, and you should understand how network communications among SMS servers and SMS clients within and between sites can affect server performance. For more information, see Chapter 3: “Understanding SMS Features.” Next, compose a list of SMS activities that might particularly influence SMS server performance in your SMS site. SMS activities fall into two categories:

• SMS server activities

• SMS-related network activities

Server Activities

SMS server activities that can affect overall server performance minimally include the following.

Active Directory discovery

Running Active Directory discovery on Active Directory domains that contain a large number of objects can create heavy throughput when the SMS site server needs to connect to an Active Directory domain controller and enumerate objects from Active Directory. Also, a backlog of DDR processing can occur on the SMS site server. Consider the potential effects of the following factors on the server performance before you run Active Directory discovery in large domains. All of the following can increase performance load on SMS servers:

• Running Active Directory discovery from the root of the domain or forest

• Maintaining very large domains with many systems and users

• Maintaining a large number of deeply nested groups (more than four to five tiers deep)

• Running Active Directory discovery from many SMS sites located within the same domain

• Running Active Directory discovery frequently

• Running Active Directory discovery during user working hours

Prior to running Active Directory discovery on a large domain, consider which systems, users, and groups you want to discover. You might choose to run discovery on selected containers, rather than on the whole domain. For more information see Appendix C: “Appendix C - Client Deployment Planning,” and Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

Note

By default, Active Directory discovery methods run by SMS 2003 RTM automatically include the discovery of members of groups when run recursively, which often results in the creation of duplicate objects when an account is a member of more than one group. When you upgrade to SMS 2003 SP1, the Active Directory discovery methods no longer discover objects within groups. If you need to discover objects within groups, you can enable the Include groups search option available on the Active Directory container properties in the Active Directory discovery method’s properties dialog box.

The Include Groups Option

The Include Groups option determines whether Active Directory discovery should use the group membership of a discovered user or computer to find additional users or computers in that group. This option initiates a more extensive search outside the initial search context, for example including externally trusted domains, or organizational units or domains that are not contiguous with the selected LDAP path that could otherwise be searched with recursion.

The cost of the more extensive search is the additional load on domain controllers and the network, as well as additional performance lod on the SMS site server since this method of discovery is more likely to find the same users more than once creating duplicate records which SMS has to process and discard.

Administrators might see no difference in performance when enabling the Include Groups option, depending on the following factors:

• Active Directory design and location of users

• Group membership

• Search location selected for Active Directory discovery

• Whether recursion is also enabled

Many organizations implement cross group membership in which a user belongs to many groups. If Active Directory discovery uses the group membership information of a discovered user to find new users, it will likely find the same user multiple times. This can result in unnecessary performance overhead. So, the default is not to use that group information to find new users or computers. For the majority of SMS 2003 deployments this will result in more efficient processing, still with successful discovery.

However, some administrators might not be able to discover all users and computers without enabling this option or this option may offer them a more efficient method of discovery because of their particular Active Directory design. When this is the case, they should enable this option.

Propagating 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 primary site servers — and secondary site servers if Advanced Clients roam to secondary sites — and client access points (CAPs) and management points. Various discovery methods are available. Activity level depends on the combination of methods used, the frequency at which they are used, and the number of clients involved.

Propagating inventory

A full hardware or software inventory can produce a large amount of inventory data. This data must be propagated throughout the SMS hierarchy. When many clients send this data to CAPs or management points at the same time, the load can be significant.

The first time that hardware or software inventory is collected on the client, the appropriate SMS inventory agent on the client generates a complete inventory record. For subsequent inventory collections, the inventory agent 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. This greatly reduces the amount of data that must propagate throughout the SMS hierarchy.

Inventory collection frequency is set on a site-wide basis. The timing and frequency of the inventory also directly affect server performance and network performance. For example, if you have 10,000 clients and set a start time for inventory collection at 11:00, then all 10,000 clients collect and send inventory — either full or delta — at 11:00. If no start time is specified, then the time when the Advanced Client policy for hardware inventory is received and processed by the client is the time the inventory is collected and sent. Because Advanced Client policies are polled on a configured cycle whenever the client computer is restarted , some randomization is introduced if no time is specified. However, you should plan the hardware requirements for the SMS component servers assuming that no randomization occurs.

You can control the load on the clients, network, SMS site systems, and SMS site servers by:

• Reducing the frequency of software and hardware inventory.

• Balancing inventory reporting requirements with acceptable server load.

• Testing the effects of different inventory frequencies in the test lab and during the pilot project.

Also, by phasing the rollout to clients, you can reduce the impact of processing inventory data. SMS inventories computers the day that they are installed as SMS clients. By default, SMS schedules these computers to conduct another inventory seven days later. By staggering the number of clients installed over a few days, you are also staggering the number of clients taking and reporting inventory information about subsequent inventory collections.

Propagating files between CAPs or management points and site servers

SMS moves files such as DDRs, inventory records, and status messages that reflect configuration changes, software distributions, and other client activities between CAPs or management points and SMS site servers. The activity pattern is often quite complex because of the interaction of many different components. The number of CAPs and management points within the site hierarchy can 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. At the time that you distribute a package through the SMS Administrator console, the package source files are sent to the targeted distribution points. For large packages, this can place a significant load on the servers and network. However, you can control the load by managing the times when you distribute packages to distribution points. For example, you might choose to distribute packages during periods of lower network utilization such as at night or during the weekend. Delta replication for updates and refreshes of packages can also reduce the load. For more information about delta replication, see Chapter 5: “Distributing Software,” in the Systems Management Server 2003 Operations Guide.

*SPBefore SMS 2003 SP1, in an SMS hierarchy with three or more tiers, a source package was resent from the central site, even when a site closer to the target site had a copy of the package. SMS 2003 SP1 includes improvements to fan-out distribution that can help reduce the workload on the SMS site initiating the distribution of a package, as well as reducing the network load on the link between the initiating site and the target sites. When you select the Send package from the nearest site in the hierarchy option on the Distribution Point tab in the Software Distribution component properties dialog box, the site where the package is originally created identifies which parent site has the correct package contents and version that is closest to the target site. This action affects package distribution in the following ways:

• When compressed package source files with the correct version are available at a parent site that is near the requesting site, the source site instructs the closest parent site to send content to the requesting site.

• When a site’s distribution point is targeted to receive a new package, the source files are retrieved from the closest higher-level parent site in the hierarchy.

• When a new distribution point is created, the site where the package was originally created identifies the parent site that has the correct package contents and version that is closest to the target site. That parent site then updates the newly created distribution point.

SMS 2.0 child sites are updated by the closest parent SMS 2003 site that contains the updated package source files. *SP

Polling CAPs and management points for new advertisements

Legacy Clients poll the CAPs and Advanced Clients management points on a regular basis to determine if any new advertisements are available. The polling frequency is set on a site-wide basis. Each SMS Legacy Client accesses a small number of small files from a CAP, but depending on how often this occurs and the potential number of clients involved, this activity might be substantial.

Downloading software from distribution points to clients

When clients run advertisements, there is considerable activity when the package source files are downloaded from the distribution point. When a lot of software is distributed in a short period of time, there is also considerable activity from status files being sent to CAPs and management points.

Updating client configurations

Legacy Client computers compare their SMS configuration to the settings at the CAP every time they are rebooted, or every 25 hours, whichever comes first. This action consumes some hardware resources, but if configuration changes are required, there is more substantial activity. Advanced Clients check management points for these configuration settings (called Advanced Client policy) at the same time that they check for advertisements based on the policy polling period configured by the SMS administrator.

Maintaining databases

SMS site database maintenance tasks run on a routine basis to ensure that SMS runs efficiently. These tasks include:

• Rebuilding database indexes

• Monitoring keys

• Deleting aged inventory history

• Deleting aged status messages

• Deleting aged discovery data

• Deleting aged collected files

• Summarizing software metering data

Because these tasks use CPU, memory and disk resources proportionate to the size of the SMS site database, it is important that you consider the effect that these tasks have on SMS site server performance. SMS performs these tasks automatically to maintain the SMS site database, but their frequency can be adjusted, and other tasks can be added. See see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery for a discussion of maintenance tasks.

Collecting status messages

SMS components report their status on a routine basis and as required, so that SMS administrators are aware of their status. SMS reports status about package distributions, advertisements, collection updates, site configuration changes, inventory updates, and all client activities.

The status subsystem summarizes the collected status information to make it more useful to the SMS administrator. This summarizing process requires some processing time, and it results in queries and updates to the SMS site database. The summarizing process is highly configurable. Although you can significantly reduce the load on the site server by configuring how status messages are summarized and reported, it is important that you balance the appropriate server load with the appropriate number of status messages generated and reported.

Communicating between sites

Data sent between sites in an SMS hierarchy include status messages, site control information, collection data, package data, and advertisement data. You can significantly control site-to-site communications through the configuration 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 data to multiple sites simultaneously. Because the SMS administrator is able to schedule when this data is sent, and how much bandwidth to use, the load can be balanced appropriately.

Software metering, server-side functions

How often software usage data is reported to the SMS site server and the amount of software metering data that is retained in the SMS site database determine how much processing power is utilized. Generally, running a larger report once per week is more efficient than running several smaller reports on a daily basis. You can choose when and whether to enable the summarizing task, and when summarization should take place. Nevertheless, the amount or type of summarized data that is transferred between sites is not configurable. Keep in mind that software metering summarization tasks run daily on SQL Server computers and are not configurable. In general, setting the software metering summarization interval to once every 7 days is sufficient. However, you should not set this interval any lower than once every 24 hours.

Polling CAPs and management points for software metering rules

On the Legacy Client, the polling schedule for software metering rules is configurable. On the Advanced Client, the software metering rules download with the Advanced Client policy.

Remote tools and network monitoring

Remote tools and network monitoring contact the SMS site server only when they are establishing the remote control session with the client and when they are verifying security in the remote control session. Otherwise, only the network, the SMS Administrator console, and SMS client computers carry the load for these activities.

With network monitoring, the computer running the network monitoring agent carries the load. There is no load on the monitored client. The computer that is actually running the network monitor console experiences additional load.

Client communication with server locator points

When SMS clients request information from the server locator point, the server locator point queries the SMS site database. For example, the Server Locator Point–based Client Installation program (Capinst.exe) runs a query to find CAPs each time an SMS client logs on. If the server locator point supports thousands of clients, this can add a significant load on the site server if the SMS site database is located on it. To reduce the load on the SMS site server, consider using SQL Server database replication for server locator points. For more information, see Appendix G: “Appendix G - Deploying and Configuring SMS Sites.”

Many of these activities depend on how you choose to use SMS 2003. These activities are also configurable, often with a tradeoff between timeliness and performance.

Network Considerations

The same activities that affect server performance can also affect network bandwidth utilization. Network Monitor is an effective tool to use to determine how SMS — and other network-related — processes affect network bandwidth utilization. All of the activities outlined in the preceding section can affect network bandwidth whenever those activities require communication between the SMS client and the SMS site server or between one site server and another site server. Additional SMS activities that affect the network are:

Polling intervals for client agents

The Advanced Client policy polling interval on clients is configurable on a site-wide basis. It determines the amount of load placed on the management point. It also determines the number of queries made by the management point to the SQL Server computer.

The more clients you have in a site, and the more frequently you configure client agent polling intervals, the more traffic polling generates on the network. The following client agents have configurable polling intervals:

• Hardware Inventory Client Agent

• Software Inventory Client Agent

• Advertised Programs Client Agent

• Software Metering Client Agent

The Advanced Client polling intervals are based on those scheduled for software distribution in the Advertised Programs Client Agent. This includes requests for:

• Site assignment

• New Advanced Client policy

• Location requests

Polling intervals for discovery methods

The process of discovering objects involves the request for an object, and a response containing basic information about the object such as its name or IP address. DDRs are relatively small (1 K on average). Nevertheless, the type and frequency of discovery that you configure can result in a large number of DDRs that are generated for specific periods of time.

• Windows User Account Discovery

• Windows User Group Discovery

If you enable Windows User Account Discovery or Windows User Group Discovery, you specify when the discovery method polls each domain. Discovery generates a new DDR for all user accounts or group accounts in each domain.

• Heartbeat Discovery

• Network Discovery

If you enable Heartbeat Discovery or Network Discovery, you specify the schedule when you want the discovery to occur. With Network Discovery you also configure how long you want discovery to run. To reduce network traffic, run Network Discovery from different servers, using a different configuration and schedule on each server.

• Active Directory System Discovery

• Active Directory User Discovery

• Active Directory System Group Discovery

• *SPActive Directory Security Group Discovery *SP

With the Active Directory discovery methods, SMS polls the closest Active Directory server to discover computers, users, or system groups in the containers specified. This process can cause significant network traffic, so you should plan to schedule it accordingly.

File sizes

The size of these files affects the load on the network when they propagate up the SMS hierarchy:

• MIF

• Collected files

• Site control file

• Status summarizers

• Software metering summarization files

The size of these files affects the load on the network when they propagate down the SMS hierarchy:

• Software metering rules (Meterrules.xml)

• SMS_def.mof

• Files related to software distribution

Client component installation

Every network-based client installation method that you choose to install the SMS client software on a computer consumes network bandwidth. SMS clients receive their component files from either a CAP for Legacy Clients or a management point for Advanced Clients. The number of files that are downloaded and the amount of bandwidth that is used depends on the client agents you configure. The method you choose can have some marginal effect on the amount of bandwidth. Installation methods include the following:

• Logon Script–based Client Installation

• Server Locator Point–based Client Installation

The logon script–based client installation method uses a logon script to run Capinst.exe or a manual client installation. Capinst.exe finds a server locator point that provides the SMS client with a list of CAPs (for Legacy Client installation) or management points (for Advanced Client installation). A manual client installation can specify a CAP or management point to use for client installation. In either scenario, you have the added server and network performance overhead associated with running a logon script.

• Software Distribution–based Client Installation

Using SMS software distribution to install the SMS client software adds the additional network bandwidth and server performance loads associated with the SMS software distribution process.

• Manual Client Installation

Because you or the user initiates manual installation, you can control when and from what network location the SMS client software is installed. You can avoid periods of heavy network bandwidth utilization and the use of WAN connections.

• Client Push Installation

• Client Push Installation Wizard (resource-based and collection-based)

  Client Push Installation finds newly discovered computers, initiates a remote connection to the computer, and installs the SMS client software. This method does not have the additional server performance load and network bandwidth load associated with the logon script installation method or manual installation method.

  The Client Push Installation Wizard controls installation of SMS client software by targeting collection membership or the results of an SMS query reducing the number of clients that are installed.

Note

When you deploy the Advanced Client by using the Client Push Installation Wizard to target a specific computer, or by using logon initiated client installation, the client always copies the client.msi file from the management point of the primary site that the client is assigned to. This is true even if the target computer is within the boundaries of a secondary site that is configured with a proxy management point. This can affect how the network bandwidth is used during installation or repair the Advanced Client on the target computer.

When you deploy the Advanced Client site-wide using Client Push Installation to target computers that have been discovered by using a discovery method at the secondary site, the client can use the client.msi file from a proxy management point at the secondary site for a new installation. However, the client uses the copy at the management point of the primary site that it is assigned to when a repair is required.

• Advanced Client Installer

The Advanced Client Installer is the manual method of installing the Advanced Client software. This method uses CCMSetup.exe to download the Advanced Client software to the computer before initiating the client installation. Because you or the user runs the Advanced Client Installer, you can control when and from what network location the Advanced Client software is installed. Similar to the manual installation method, in this scenario you can avoid periods of heavy network bandwidth utilization and the use of WAN connections.

For more information about installation methods, see Chapter 4: “Understanding SMS Clients” in the .

Status messages and status filter rules

Most SMS components produce status messages. Its default settings are reasonable for most environments. However, how you configure the following three aspects of the SMS status system determines how much bandwidth status messages consume:

• Status reporting

• Status filter rules

• Status summarizers

Filtering unnecessary status messages, and controlling how status messages are replicated from site to site can significantly reduce the amount of network traffic that status messages generate.

Remote secondary site installations

If you install the secondary site from the primary site server (by using the SMS Administrator console), then you potentially consume a great deal of bandwidth because all necessary installation files are downloaded from the primary site across the network connection, and because the network connection can include a WAN connection. Installing from a mapped network drive also produces significant network traffic. Alternatively, you can insert the SMS 2003 disc in a CD drive on the secondary site server and have SMS install all files from the local disc. The latter produces less network traffic than installing a secondary site from the primary site server.

Remote SQL Server

SMS and SQL Server communicate constantly. It is not recommended that you install your SMS site database SQL Server on a computer other than the SMS site server computer. If you must have SQL Server installed on a remote computer, then analyze the intervening network connection to ensure that it is well-connected. You might consider installing a second network adapter in both the SMS site server and the SMS site database server, and then dedicating this second card for communications between the site server and the computer running SQL Server.

You can significantly increase the performance of SMS if the SMS site database and the SMS site server are both on the same computer, provided that computer has sufficient processing power to accommodate both roles.

Server locator point queries

SMS clients access server locator points when Capinst.exe is run to resolve site assignment and to provide a list of CAPs to the Legacy Client and a list of management points to the Advanced Client. Advanced Clients access a server locator point under the following conditions:

• The Advanced Client is not yet assigned to a site and is in auto-assign mode.

• Active Directory is not yet extended with SMS extensions, and SMS is not publishing its component servers to Active Directory.

• The server locator point has been registered in WINs.

In this scenario, the Advanced Client accesses the server locator point at every auto-assignment cycle until the client is assigned to an SMS site.

The network bandwidth utilization for a single client is insignificant. As more clients access the server locator point, network bandwidth utilization grows proportionately.

Package download for software distribution

Within an SMS site, package source files are sent when the SMS administrator designates a distribution point. In this scenario, SMS copies all package source files to the distribution point without compressing the files. This can place a significant load on network bandwidth utilization.

When SMS sends package source files to a distribution point at an SMS child site, those files are compressed first. When they are received at the SMS child site, they are uncompressed and sent to the designated distribution point. In this second scenario, you can control how network bandwidth is utilized during site-to-site communications.

SQL Server database replication

Server locator points and management points can be configured to perform SQL Server database replication. This adds a new path for network traffic from the management point or server locator point to another SQL Server database. When you configure a site system to use a different database, the data is replicated from the SMS site database to the replicated database. Replication occurs thereafter each time a related setting is changed on the site server. This reduces the performance load on the SMS site database and reduces network bandwidth utilization if the replicated database is on the same server as the server locator point or management point.

Active Directory authentication

SMS activities authenticate in various ways, some more frequently than others. Authentication by SMS processes can affect network bandwidth, although the impact is minimal. Keep in mind that a large site with a lot of clients must respond to a greater number of authentication requests from those clients. Try to avoid client authentication over a WAN link.

Software metering

Be aware that, as the number of software programs monitored by software metering increases, the load on the network increases. Network traffic also depends on how you configure the software metering data collection schedule and the software metering rules download schedule.

Proxy management point

Advanced Clients can be assigned only to a primary site. Advanced Clients that roam to a secondary site across a WAN link can produce a significant load on network bandwidth utilization because client status and hardware or software inventory data is sent to the parent primary site. Advanced Client policy requests from the Advanced Client also reduce the available bandwidth between the two sites.

Installing a proxy management point at the secondary site can significantly reduce the effect on available network bandwidth created by Advanced Clients located within that site’s roaming or site boundaries. Advanced Clients send inventory and status data to the proxy management point. The proxy management point uses the SMS site’s sender functionality to transfer the data to the primary site. The SMS administrator can control how the sender utilizes bandwidth. Because proxy management point also caches some policy information, Advanced Clients can obtain this policy information from the proxy management point, rather than from the management point at the primary site.

For more information about implementing management points and proxy management points, see Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

Sizing SMS Component Servers

System Monitor is an effective tool for determining server performance. Remember that the process of sizing servers is not a one-time task. Server sizing is initially done to determine the appropriate server hardware given a specific operating scenario, such as supporting 50,000 clients running hardware and software inventory, and running five packages a day. However, you should continue to monitor the server’s performance after you deploy SMS to ensure that that server continues to perform within acceptable thresholds. Ultimately, it is the server performance that determines the appropriate server hardware configuration and the need for future modifications, perhaps in the form of upgrades or replacement of equipment. This section covers the following topics:

• Setting Expectations and Service Level Agreements

• Methods and Formulas Used to Determine Server Capacity

• Determining Primary and Secondary Site Server requirements

Setting Expectations and Service Level Agreements

Setting expectations for server and network performance and agreeing on acceptable levels of service is perhaps one of the hardest tasks to perform, yet a very necessary task when you are determining a sizing and capacity strategy for your SMS deployment.

SLAs are the most common ways to establish conditions of operation agreed upon by all parties involved in the operation and performance of the system. One SLA might specify that the workload item or transaction in question should process within a certain span of time, for example, five seconds. Another SLA might specify that no more than 85 percent of memory can be used to ensure that page faults are kept to a minimum. If a violation of an SLA occurs, it generally indicates a hardware resource failure or overload that might require an upgrade or replacement of equipment.

Consequently, performance tracking is an integral part of creating realistic SLAs.

Methods and Formulas Used to Determine Server Capacity

You can understand a server’s workload and capacity when you determine the kinds of tasks carried out on that server. The performance statistics that are calculated by System Monitor reveal the effects of those tasks. You can use these statistics with a number of standard mathematical formulas to help determine server size and plan for capacity and growth.

Basic Model of System Capacity

There are three variables that form the basic model of system capacity. These variables are

• Observation time (T), the amount of time that the server is monitored for activity

• Busy time (B), the amount of time that the server was active during the observation time

• Completions (C), the number of transactions completed during the observation period

With these three variables, you can calculate the six significant values, described in Table F.4, that are used to develop a capacity planning model.

Table F.4   Capacity Planning Data Formulas

Data	Description	Formula
CPU Utilization	The percentage of CPU capacity used during a specific period of time.	U = B/T
Transaction throughout of the system	The average number of transactions completed during a specified period of time.	X = C/T
Average service time	The average time to complete a transaction.	S = B/C
Transaction capacity of the system	The number of transactions the server handles.	Cp = 1/S
Average queue length	The average number of transactions in queue.	Q = U/(1-U)
Average response time	The average time to respond to a transaction.	R = (Q×S)+S

Here is an example of how to use these formulas to size a server. Suppose that you observe the server for 60 seconds (T), during which time there are 90 completed transactions (C), and the server is actually busy processing that workload for 48 seconds (B). Table F.5 shows the resulting data values using this information.

Table F.5   Capacity Planning Resource Formula Results

Resource	Formula	Result
CPU Utilization	U = B/T	48/60 = 80 percent utilization
Average transaction throughput of the system	X = C/T	90/60 = 1.5 transactions/sec
Average service time	S = B/C	48/90 = .53 seconds
Transaction capacity of the server	Cp = 1/S	1/.53 = 1.875 transactions/sec
Average queue length	Q = U/(1-U)	.8/(1 - .8) = 4 transactions
Average response time	R = (Q×S)+S	(3 × .53)+.53 = 2.12 seconds

The CPU utilization was at 80 percent, and handled an average of 1.5 transactions per second. The average service time for these transactions was .53 seconds, and transactions were completed in an average time of 2.12 seconds. On average, there were four transactions waiting to be processed at any given point in time during the observation period, and the server had the capacity to process 1.875 transactions per second.

If the SLA states that during any given 60 second period, the server should not utilize more than 85 percent of the processor and should be capable of handling at least 100 transactions, the calculated values shown in Table F.5 indicate that the SLA is being met. If the SLA stated that during any 60 second period, the server should not utilize more that 75 percent of the processor or should not have more than three transactions waiting in queue, then the calculated values shown in Table F.5 indicate that the server cannot perform within the limits of the SLA and probably must be upgraded.

Use these formulas as tools to help you to determine current server performance levels, to develop acceptable and reasonable SLAs given current and expected server hardware configurations, and to identify where upgrades or new equipment is necessary.

End-to-End Response Time

When you consider response time, you should not think only in terms of a single server’s response time and performance, but instead you should think of all the data components that make up the service chain for that transaction. So, the first step in determining end-to-end response time is identifying the data components that make up the service chain.

For example, consider that information flows from an SMS client to a CAP or management point, and then to the site server. The service chain that emerges from this flow has five data components associated with it as shown in Figure F.2:

• Client Q, R, and S values

• Network connection between client and CAP or management point Q, R, and S values

• CAP or management point Q, R, and S values

• Network connection between CAP or management point and site server Q, R, and S values

• Site server Q, R, and S values

Figure F.2   A service chain and the computation of end-to-end response time

The end-to-end response time, then, is the sum of each of the R values for each component in the service chain. Use this information to develop SLAs for service chain performance, and to determine when there are performance aberrations.

There are no standard metrics for SMS performance. Your organization might want to consult its SLAs and perform a cost-to-benefit analysis to determine how fast the SMS site servers must run. Your organization might have time requirements. For example, mission-critical applications might require updating on 95 percent of desktops in an eight-hour period. Another SLA might state that critical virus signature update files must be distributed to all desktops within a two-hour period.

After running a pilot project and discovering the cost to distribute the package to all desktops on the network in four hours, you might compromise on a reduced hardware configuration and accept a window of five hours to complete the distribution. In general, faster response times require more expensive hardware, and lower acceptable response times require less expensive hardware.

Because many SMS service requests come in surges, most SMS sites have service request backlogs that last for at least a few minutes. The two most common surges occur during the user logon cycle and when you send package advertisements.

While you experiment to find the least expensive hardware configuration to meet your needs, consider future growth requirements and the potential for change, and monitor the SMS site for backlogs. If a site is backlogged most of the day and catches up between 3:00 A.M. and 4:00 A.M., then there is a risk that the site cannot catch up if the weekly load increases. Plan for extra capacity so that you can quickly meet unexpected software distribution or other feature demands. Also, when SMS users and administrators become familiar with SMS, their usage levels increase.

Determining Load Signatures

The combination of business objectives and operational styles in every organization creates unique load signatures. However, if an organization has ten remote offices with the same number of workers, the same software, and the same hardware, and you manage them all similarly, then they all might have a similar load signature. Grouping computers with similar load signatures can reduce planning time.

By determining the load signature of servers in the SMS site, you can plan for an appropriate hardware component capacity. Then, by changing hardware capacity, you can increase or decrease the responsiveness of SMS and the time required to accomplish specific tasks. The load signature is determined by several factors, including:

• Number of optional SMS features installed and in use on the computer

• Location of site server in the SMS hierarchy (whether it communicates with parent or child sites)

• Number of objects in the site

• Size of objects being processed

• Frequency of scheduled events

• Frequency of feature use

To successfully determine server sizes for an SMS hierarchy:

• Define the load signature for each site component server.

• Determine throughput requirements using the formulas documented in this section.

• Use the throughput requirements to estimate hardware requirements.

• Use the hardware requirements to construct sample SMS configurations to test in your isolated test lab and later in the pilot project.

Testing your hardware configuration and conducting a successful pilot project helps ensure that your organization’s deployment progresses smoothly, because the deployment itself is based on site designs customized for your organization’s data and tested in your environment.

Determining Site Server Hardware Requirements

The hardware required for SMS site servers largely depends on the SMS features that you choose. When your business grows and changes, the SMS site server hardware requirements change accordingly. For the initial SMS deployment, you must develop initial hardware requirements that you can use to start the pilot project. To estimate hardware requirements for each SMS site server, determine the following:

• The number of clients you plan to install and the number of SMS objects you expect to have at the site.

• The load signature of installed SMS components.

It is important to build SMS site servers with as much fault-tolerant hardware as economically possible. Determine the load signatures of primary and secondary site servers, in addition to all other servers that are assigned SMS roles. After you have determined the load signature for the site component servers, you can establish initial hardware requirements.

The recommendations in this section are based on a number of factors, such as the number of clients and the number, size, and frequency of objects processed by SMS. Regardless of these recommendations, performance results might vary. Consider all the factors and carefully select server hardware based on all potential variables in your environment. Important factors include:

• SMS features enabled:

  • Number of collections and their refresh schedule

  • Software distribution (frequency and size)

  • Software metering

  • Discovery methods used

  • Hardware and software inventory frequencies

  • Hardware and software inventory sizes

  • Reporting

  • Software Update Management

• Available network capacity

• Other applications sharing SMS server hardware

• Number of clients in the SMS site

• User community and acceptable performance through service level agreements

• Budget constraints

Use the following guidelines when you develop your SMS site server sizing plan:

• At small SMS sites, processor, memory, and disk resources are generally not big issues and are easier to track and maintain.

• At medium SMS sites:

  • Memory must grow proportionately to the number of clients.

  • Disk I/O becomes a potential performance bottleneck; consider a RAID configuration.

  • Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider dual processor servers.

• At large SMS sites:

  • Memory must grow proportionately to the number of clients.

  • Disk I/O becomes a likely performance bottleneck; consider a RAID configuration such as RAID 1+0, and separate hardware volumes and channels for increased performance.

  • Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider quad processor servers.

The hardware requirements you develop after reading these sections are for production purposes only. For the test lab and pilot project, these numbers might require adjustment, based on the fraction of the production environment included in the pilot deployment. For more information, see Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

Consider using SCSI RAID disk controllers

Hardware-based SCSI RAID controllers provide redundancy in the event of disk failure. Also, they can improve system performance when they are implemented. Many SCSI controllers provide read/write caches that can greatly reduce CPU usage during times of increased load. SCSI RAID controllers also spread read/write operations across multiple disks, and improve disk access times.

The following is a sample SCSI implementation plan for a site server:

Channel 1 — 4 volume RAID5 array for the SMS site database

Channel 1 — 2 volume RAID1 array for the Windows system files, the SQL Server master database, and the system’s virtual memory paging file

Channel 2 — 6 volume RAID5 array for SMS

Channel 2 — 2 volume RAID1 array for the SMS SQL Server transaction log (write caching disabled)

Depending on a number of configuration factors, medium-sized primary sites (1,000–5,000 clients) and large primary sites (20,000–50,000 clients) might determine disk input/output (I/O) to be a bottleneck. For this reason, consider separating hardware volumes and channels for performance with a SCSI RAID controller.

The use of high-end SCSI controllers and disks is recommended for SMS site servers that are servicing a large number of clients and using many SMS features. However, budget limitations might prevent the feasibility of this. SMS works well on current integrated device electronic (IDE) disks. IDE disk subsystems are not as recoverable, but they can perform adequately.

In general, if you are in a medium to large organization, you should consider the following tips when you are building SMS site system hardware:

• Place the SMS site server and SMS site database on different channels (if you are using SCSI hardware).

• Neither the SMS site nor the SMS site database share their disks with other applications.

Configure the SQL Server transaction log to run on a different disk than the disk where the SMS site database is located.

Estimating the Number of Clients and Objects

The hardware requirements of SMS site systems depend on the number of objects that the site servers must process. Objects are items that are processed and stored in the SMS site database. SMS uses objects to move and store client and server data. Each SMS feature creates different types of objects. The following are the most common objects:

• Discovery data records (DDRs), which are produced by discovery methods

• Hardware inventory files: hardware inventory complete (.hid), hardware inventory delta (.hid), and Management Information Format (MIF) files

• Software inventory files: software inventory complete (.sic) and software inventory delta (.sid)

• Status variable files (.svf)

You can configure many SMS components to control the number of objects they produce. Table F.6 lists common objects generated by SMS components.

Table F.6   Objects Generated by SMS Components

Component	Objects generated per interval
Heartbeat Discovery	1 DDR per heartbeat interval
All other discovery methods	1 DDR per object found
Hardware inventory	1 status message and 1 MIF file per inventory interval
Software inventory	1 status message and 1 .sic or .sid file per inventory interval
Software distribution	6 status messages (.svf) per new advertisement 2 status messages (.svf) per existing advertisement
Software metering - Legacy Client	1 rule file (.mux) and 1 status message for each cycle 1 status message for each usage report upload
Software Metering - Advanced Client	1 status message each time a software metering rule is added or deleted from its policy 1 status message for each usage report upload

The initial hardware and software inventory on clients is a complete inventory. Subsequent inventories produce delta inventory files that contain only changes to configuration , are smaller, and process faster than a complete inventory. When you perform sizing tests, however, be sure to consider that SMS occasionally requests an inventory resynchronization. When this happens, all the clients in the site report full inventories during their next inventory collection cycle. The site can become overwhelmed in this peak situation if you are using network connections, or server hardware that can only maintain the flow of the smaller delta inventory. For more information about the resynchronization process, see Chapter 3: “Understanding SMS Features” in the Microsoft Systems Management Sevrer 2003 Concepts, Planning, and Deployment Guide.

Table F.7 offers another way to look at objects that are generated given a specific site configuration. The numbers in this table are based on the following configuration:

• SQL Server 2000, installed on the same computer as SMS

• A five-day work week

• Three new advertised programs sent to all clients every week

• All SMS site systems running Windows 2000 Server SP2 or later

• Heartbeat Discovery run once per week

• Hardware inventory run once per week (MIF generation)

• Software inventory run once per week (.sic and .sid generation)

• Status messages enabled (.svf generation)

Table F.7   Number of Objects per Client per Week

Object type	Number of objects per client per week produced with the specified configuration
DDR	1
MIF	1
.sic or .sid	1
.mux	1 (Legacy Client only)
.svf	22

The values represented in Table F.5 and Table F.6 are starting points. Use the values to facilitate the evaluation of your own site. Performance can vary considerably between organizations because of numerous variables, such as the number of clients, type of hardware, and available network bandwidth.

The data is also based on the assumption that the SMS Administrator console is run remotely most of the time, instead of being run directly on the site server. If you plan to use the SMS Administrator console heavily on the site servers, consider a faster CPU and more RAM for the site servers to improve the performance of the console.

Note

The total number of clients in a site is actually the number of clients that physically belong to that site plus the number of clients that belong to the site’s lower level sites. In addition, if you enable discovery of users and groups, the total number of manageable objects can increase significantly.

Developing Initial Hardware Requirements

Using the performance metrics derived from monitoring the system, from the capacity models and values you generated, and from the system load signatures you identified, you can plan initial hardware requirements for the SMS site servers. Document these requirements in your SMS 2003 project plan. Ideally the hardware recommendation should meet the following requirements:

• Zero processing backlog

• Responsive help desk operations from remote consoles

• Additional processing capacity to ensure timely recovery and minimal hardware cost

However, these numbers might require adjustments when you perform testing in your own lab environment and run the pilot project as described in Appendix D: “Appendix D - The Pilot Project.”

For small remote secondary sites that service the organization by managing only a small number of clients, you might need only very basically equipped computers. By using basically equipped computers in these cases, you can save a substantial amount of money.

For SMS 2003 sites that manage more than 100,000 clients — for example, a central site with no clients assigned to it — you should use quad-processor high-end computers with high-performance disk subsystems and plenty of memory. Because the performance variables become unpredictable at this size, it is especially critical that you run a pilot project to properly estimate the site server hardware.

Determining Site System Hardware Requirements

The CAP, distribution point, server locator point, management point, and reporting point roles require special consideration when you plan hardware requirements. This section describes these considerations.

Client access point

A CAP is primarily responsible for relaying the majority of the objects sent from Legacy Clients to the site server. It provides clients with the SMS 2003 client components during Legacy Client installation. The following items affect the load on a CAP:

• The number of features that are enabled

  • Inventory collection

  • Software distribution

  • Software metering

  • Status messaging

• The number of Legacy Clients in the site

• The number of CAPs in the site

• The number of total users in the site if you are targeting users for software distribution.

The CAP is also responsible for providing the files the client requires to perform software installations. The Legacy Client connects to this computer on a regular basis to check for new packages to install. In addition, the SMS Executive service and Inbox Manager Assistant run on this site system.

Note

All the CAPs in an SMS site contain all the files required for all the clients in the site regardless of which CAP a client actually uses.

You should also consider the data sent from clients to CAPs when you consider the appropriate hardware configuration for CAPs. This data includes discovery files, inventory, and status messages.

You should be aware that the load on a CAP increases at the following times:

• During discovery

• During SMS Legacy Client deployment

• During software inventory (including file collection) on the Legacy Client

• During hardware inventory on the Legacy Client

• When a new advertisement is sent to the Legacy Client

• When status information is sent up from the Legacy Client

• When a large number of users log on to Legacy Client computers simultaneously

When you distribute greater amounts of software, you increase the amount of status that is propagated up the SMS hierarchy. The more inventory requirements you add to the SMS_def.mof file for hardware inventory, the larger the inventory becomes. The more files you collect with software inventory, the greater the amount of space required on the CAP. The shorter you configure the CCIM cycle, the higher the peak load on the CAP.

You can reduce the load on CAPs by:

• Increasing the number of CAPs in the site

• Lengthening the polling intervals for Legacy Client agents

  • Inventory collection

  • Software distribution

  • Software metering

• Scheduling advertisements for non-peak periods

Note   One of the issues to consider with large sites is that some Legacy Client software distribution files become very large as the number of clients increases. In some cases, each client within the site must read the same client lookup file on the CAP. By increasing the number of CAPs in the site, you decrease the load across all CAPs in the site. The more CAPs deployed within the site, the better the performance is for the client. However, the more CAPs in the site, the more replication of files between the CAPs and the site server. Consequently, the load increases on the site server. Testing in your isolated test lab is the only way to determine the optimum solution of this balance for your environment. Start by deploying a minimum number of CAPs within this test environment. Then gradually scale up the number of clients in the site until you’ve reached optimum performance for the configuration.

The main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Legacy Clients communicate with CAPs, see Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

Management point

You should size the management point server similarly to how you sized the CAP, because their roles are very similar. When you document the hardware requirements, remember that the management point also requires IIS. CAPs are simple file shares. Files are copied to them and forwarded to the SMS site server. Management points do additional processing of the files. CAPs use more disk space than management points, but management points use more processing time. Management points cache Advanced Client policy assignments for clients and as a result, memory is more of a concern than it is for CAPs.

The following items affect the load on a management point:

• The number of features that are enabled

  • Inventory collection

  • Software distribution

  • Software metering

  • Status messaging

• The number of Advanced Clients in the site

• The number of proxy management points (placed in a secondary site) in the site.

The management point relies on the SMS site database for its client responses. One sizing consideration is the performance of SQL Server. If performance is slow, plan to implement an additional SQL Server for replication purposes.

You can reduce the load on management points by:

• Lengthening the Advanced Client policy polling interval.

• Scheduling advertisements for non-peak periods.

• Implementing an additional SQL Server to replicate the SMS site database.

• Deploying multiple management points using Windows Network Load Balancing Service.

As with the CAP, the main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Advanced Clients communicate with management points, Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

Note

Advanced Clients are managed by Advanced Client policy. This architecture is more scalable than CAP architecture. The replication issues mentioned for CAPs do not exist for management points. Each management point is able to support many more clients than a CAP can support. For sites consisting of a large number of Advanced Clients, the capacity planning strategy consists of deploying multiple management points using Windows Network Load Balancing Service and SQL Server database replication.

Ensure that there is always at least 100 MB of free disk space on the management point installation drive. If the drive on which a remote management point is installed has insufficient free disk space, the File Dispatch Manager component performance can be greatly reduced. This situation can occur if the Client Configuration Manager (CCM) queue on a management point has a large number of files to be processed because, for example, the management point was offline for some time. If this situation does occur, manually move files from MPDrive\SMS\MP\Outboxes on the management point, to the corresponding \\SiteServer\SMS_SiteCode\Inboxes on the site server to which the management point belongs.

Distribution point

SMS 2003 clients access a distribution point to retrieve the package source files that are required to run advertised programs. Determine hardware configuration requirements for distribution points just as you would for any other file servers in the organization. For example, a large organization might have tens or hundreds of clients requesting 100 MB files from a distribution point. Software packages vary in size, so plan accordingly.

The following items affect the load on a distribution point:

• The number of packages you distribute

• The number of clients in the site

• The number of distribution points in the site.

You can reduce the load on distribution points by:

• Deploying one distribution point for each network segment within a site.

• Deploying protected distribution points for network segments where bandwidth utilization causes a bottleneck.

• Scheduling software distribution for non-peak periods.

• Scheduling advertisements for non-peak periods.

• Keeping target collections small.

You can control the load on distribution points by carefully scheduling software distribution. For example, if you are distributing Microsoft Office to the organization, you might want to spread out the load by creating several small advertisements targeted to different collections at measured intervals throughout the night. Alternatively, you can roll out Microsoft Office to every client at one time, but spread the load across multiple distribution points. Also, you can limit the load on the distribution point by limiting the number of simultaneous connections allowed.

Note

When you are distributing packages to child sites, you can also reduce the workload on the initiating site by using the fan-out feature. The fan-out feature allows sites to distribute package content to lower sites, through child sites rather than distributing the package directly. Fan-out distribution occurs automatically if the initiating site does not have an SMS address for the destination site. For more information, see Chapter 3: “Understanding SMS Features” in the .

The main performance objects to track for sizing and capacity are those related to disk utilization, particularly read/write activity, and CPU utilization when read/write requests queue up quickly.

*SPBefore SMS 2003 SP1, SMS 2003 was designed to process a single thread per package. This resulted in SMS copying content to one particular distribution point, and when successful, moving to the next distribution point when multiple distribution points were targeted to receive the package. The failure of any one distribution point to receive the package could cause the package distribution process to stop.

In SMS 2003 SP1, the package distribution process is multi-threaded. SMS copies content to multiple distribution points in parallel. Because of this change, failure of a single distribution point does not stop the distribution of the package to other distribution points. This change improves both reliability and response time for package deployment, and effectively allows a single site to support a much larger number of distribution points. The following benefits can result:

• Reduced elapsed time for package distribution to all distribution points of the site.

• Simplified site hierarchy, because in some cases a secondary site can be replaced by a distribution point.

• Faster software deployment, which is key for patch deployment.

• Lower hierarchy deployment costs, which results in fewer required site servers.

• Faster hierarchy deployment, because it is faster and easier to deploy a distribution point than a site server.

• Lower maintenance costs, because it is easier to manage a distribution point than a site.

Configure how may packages SMS processess concurrently per SMS 2003 SP1 site, on the Distribution Point tab in the Software Distribution component properties dialog box in the SMS Administrator console. When your site hierarchy includes previous versions of SMS (SMS 2.0 or SMS 2003), this setting is not configurable from an SMS 2003 SP1 Administrator console.

Before SMS 2003 SP1, in an SMS hierarchy with three or more tiers, a source package was resent from the central site even when a site closer to the target site had a copy of the package. SMS 2003 SP1 includes improvements to fan-out distribution that can help reduce the workload on the SMS site initiating the distribution of a package, as well as reducing the network load on the link between the initiating site and the target sites. When you select the Send package from the nearest site in the hierarchy option on the Distribution Point tab in the Software Distribution component properties dialog box, the site where the package is originally created identifies which parent site has the correct package contents and version that is closest to the target site. This action affects package distribution in the following ways:

• When compressed package source files with the correct version are available at a parent site that is near the requesting site, the source site instructs the closest parent site to send content to the requesting site.

• When a site’s distribution point is targeted to receive a new package, the source files are retrieved from the closest higher-level parent site in the hierarchy.

• When a new distribution point is created, the site where the package was originally created identifies the parent site that has the correct package contents and version that is closest to the target site. That parent site then updates the newly created distribution point.

• SMS 2.0 child sites are updated by the closest parent SMS 2003 site that contains the updated package source files. *SP

Server locator point

A server locator point is used primarily in client installation and is generally implemented in the SMS central site because the central site has information about the SMS hierarchy and the structure of the SMS sites in that hierarchy. It provides site assignment information and locates a CAP for Legacy Clients, or a management point for Advanced Clients, and directs the client there to complete installation. When you document the hardware requirements, remember that the server locator point also requires IIS.

The following item affects load on a server locator point:

• Client access for site assignment and installation

If you have enabled the logon script-based installation method, the Legacy Client accesses a server locator point at client logon time and produces minimal network traffic — approximately a 1 K upload and a 1 K download to the client. Similarly, the Advanced Client accesses the server locator point at client logon time for auto-assignment at its initial logon time, and generates the same amount of traffic as the Legacy Client.

However, server locator points do rely on accessing the SMS site database to obtain information about CAPs and management points, so it is necessary to monitor the network traffic generated between a server locator point and the SMS site database server. For more information, see Appendix E: “Appendix E - Designing Your SMS Sites and Hierarchy.”

You can reduce load on server locator points by:

• Creating a phased roll-out of SMS client software

• Implementing an additional SQL Server to replicate the SMS site database

Reporting point

A reporting point provides read-only access to SMS reports using IIS. The reporting point can be installed on any computer running IIS, including the SMS site server.

The following items affect load on a reporting point:

• The number of custom reports you create

• The number of SMS users that require access to the reports

Because people require SMS information in many different forms, the requirements for SMS reports can vary widely. Depending on the amount of data and the complexity of the reports, SMS reporting can use considerable system hardware resources.

You can reduce load on reporting points by:

• Deploying the reporting point on a server other than the SMS site server.

• Scheduling large reports to run at non peak times.

• Creating multiple reporting points for a site and assigning groups with similar reporting needs to a specific reporting point.

Note

Depending on the load that is generated during your lab test, you might consider deploying the reporting point on a dedicated server.

Determining SMS Site Database Server Requirements

SMS 2003 depends on SQL Server as its database engine. The database device configuration of SQL Server and the hardware resource needs of SMS 2003 are linked and have hardware interdependencies. It is recommended that the SMS site database be installed on the SMS site server. The performance of SMS 2003 is directly related to the performance of SQL Server. You must be sure to provide adequate hardware resources for both applications. To do so, you need a clear understanding of how these two applications work together.

Should SQL Server be installed remotely or locally?

SMS 2003 performs best when SQL Server is dedicated to SMS 2003 only. You can also significantly increase the performance of SMS if the SMS site database is installed on the same computer that performs the SMS site server role if the server has been sized to accommodate both applications. Running SQL Server on the site server computer reduces network load. If you are using SQL Server for other applications within your organization, you must decide whether to use a remote installation of SQL Server for those applications. Running the SMS site database on the SMS site server is considered a best practice. Running SQL Server on a computer that is not the site server only benefits the site if you are using SQL Server for other applications within your organization.

Disk input/output is the most important factor in deciding where to locate the computer running SQL Server. Installing the data devices and log devices onto separate physical disks or RAID arrays improves the disk performance of SQL Server and indirectly benefits the performance of SMS.

How much data is written to the SMS site database on a daily, weekly, and monthly basis?

You can determine the amount of data written to the SMS site database by reviewing the number of clients that are reporting to the site and by reviewing the overall usage patterns, such as the flow of status messages, hardware and software inventory records, and DDRs, into the SMS site database. The total amount of data that SMS writes to the SMS site database can dramatically change the hardware that is required to optimize SQL Server performance. Often, if a large amount of data is written to the SMS site database only once per month, you require less processor power and disk space for SQL Server. Similarly, if a large amount of data is written to the SMS site database only during a particular part of the day, and you are not enabling many SMS features that require SQL Server processing, the server running SQL Server requires less processing power and disk space.

SQL Server uses memory for extensive caching. If it is given more memory, it uses it and runs more efficiently. Limiting SQL Server memory to a specific maximum amount reduces page faults and improves server performance. For more information about tuning the SQL Server memory cache, see the SQL Server documentation.

Another issue to consider when you are determining the hardware requirements for SQL Server and SMS component servers is the total amount of data that is likely to accumulate in the SMS site database. If you have an accurate and complete picture of the network before you run the pilot project, you can begin to estimate the amount of data that can accumulate and the size of the database required to store it.

To estimate the required SMS site database size for a single site, use the following formula as a baseline:

50-100 MB + (x ∝ 1-2 MB) (where x is the number of clients in the site)

This formula is based on the following site settings:

• Weekly hardware inventory, default SMS_def.mof

• Weekly software inventory

• Delete aged discovery records after 90 days

• Delete aged inventory history after 90 days

• Delete aged status messages after seven days

• Weekly software metering summarization

The formula also allows for as many as 20 status messages per client, per week.

Note

This value must be adjusted if these settings change. For example, if the default SMS_def.mof is modified to include additional inventory items being reported, the value might increase significantly.

After you have sized the database, then use the formulas and System Monitor counters suggested earlier in this appendix to generate a complete size and capacity plan for the SMS site database server.