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 Chapter 17, "Discovering Resources and Deploying Clients," and Chapter 10, "Planning Your SMS Deployment and Configuration."
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.
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 Chapter 10, "Maintaining and Monitoring SMS Systems," in the Microsoft Systems Management Server 2003 Operations Guide 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 Chapter 15, "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.
For More Information
Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.