Site System Planning

Article
12/08/2008

The next step is to determine which site system roles you need to enable, and which servers within your site you should assign those site system roles to. An SMS site system is a server that provides SMS functionality to the site. The functionality contributed by a site system is indicated by its assigned site system roles, which are tasks that a site system performs in an SMS site.

For example:

The management point role provides a communication point between the SMS site and Advanced Clients. A computer hosting the management point is a site system. The SMS administrator can assign site system roles to the primary site server or distribute them among several different site systems. You can assign some site system roles during installation, and other site system roles through the SMS Administrator console.

The Site System Planning worksheet in the Deployment Planning workbook can help you identify what site systems you must enable for each site and identify the planning considerations for each site system. You should also refer to Appendix F: "Appendix F - Capacity Planning for SMS Component Servers" later in this book to help you make decisions about performance and capacity issues related to each site system.

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.

You can use the following capacity planning scenario as a baseline to help you extrapolate capacity and performance values that are appropriate to your organization’s infrastructure. The values cited here are based on specific hardware configurations and specific feature parameters.

Capacity Planning Scenario - Assumptions

In testing SMS 2003 for performance and capacity, various load simulations were generated to determine the maximum numbers of clients that could be supported by an SMS site and the optimal performance that could be achieved with a specific hardware configuration operating under a consistent load to support 100,000 total client systems on a site server and 25,000 clients on a management point. These results are provided for you to use as a baseline for determining performance expectations within your organization with your network infrastructure. It is essential that you use this information with the tools outlined in Appendix F: "Appendix F - Capacity Planning for SMS Component Servers" to extrapolate performance criteria that are relevant to your environment.

Primary site server activity

Dedicated quad processor server (1.4 GHz processors)
4 GB memory
RAID 5 disk array
All processes configured for default frequencies
Performance expectations based on a simultaneous load of all objects
Assumption of 100,000 SMS clients on the primary site

Table 1.3 Object Performance Expectations on Primary Site Server

Objects generated	Results per minute	Expected daily load
Heartbeat discovery data records	389	100,000 files (one from each client daily)
Hardware inventory - full (88 KB, using default SMS_Def.mof)	50	Occurs during SMS_Def.mof update only
Hardware inventory - delta (7 KB)	375	100,000 files (one from each client daily)
Software inventory - full (500 KB)	18	100,000 files (one from each client daily); occurs during site attach or site configuration changes, Legacy Client only
Software inventory - delta (10 KB)	295	20,000 files (100,000 files generated once a week per client as defined by the default software inventory schedule)
Status messages	2082	1 advertisement to each client (600,000 files)
Software metering usage files (14 products run 10 times each)	41	20,000 files

Software distribution

Deployment of a 9 MB software package to 100,000 clients on a well-connected network.
Assumption of 100 MB network bandwidth fully available.

Table 1.4 Software Distribution Performance for a Single Site

Task	Time to complete
Creation of advertisement for 100,000 clients	~28 minutes
Creation of package and distribution to one distribution point	~20 minutes (can occur concurrent with creation of advertisement)
Polling of advertisement by clients	~63 minutes (assuming client online, worst case scenario)
Download and execution of package by clients	~7 minutes (average download time)
Total optimal time for this package	~1 hour, 38 minutes
Related status messages	Can range from 2 to 4 hours depending on hierarchy design, client volumes, message forwarding performance, and network speed.

Management point performance

Dedicated quad processor server (1.4 GHz processors)
4 GB memory
RAID 5 disk array
Performance expectations based on a simultaneous load of all objects

Table 1.5 Object Processing Performance on Management Point

Objects generated	Results per minute	Clients per hour
Discovery data record	360	21,600
Hardware inventory - full (88 KB, using default SMS_Def.mof)	360	21,600
Hardware inventory - delta (7 KB)	660	39,600
Software inventory - full (500 KB)	30	1800 (during a full resync)
Software inventory - delta (10 KB)	600	36,000
Status messages	2100	21,000 (during software distribution)
Policy requests	1038	62,280
Policy content requests	990	59,400
Distribution point location requests	972	58,320

Network traffic generated

Site server installation
Client agent activity
Server locator point requests
Active Directory server locator point requests

Table 1.6 Network Traffic Generated

Object type	Network traffic in bytes (includes header content)
Site server installation
Schema update to Active Directory domain controller	140,186
Schema replication	5920
Management point installation with Active Directory schema extension	27,030
Server locator point installation with Active Directory schema extension	26,153
Client agent object	Legacy Client/Advanced Client
DDR	5442/4976
Hardware inventory - full (115 KB/125 KB received)	164,543/20,127
Hardware inventory - delta (3.5 KB/5 KB received)	4110/5215
Software inventory - full (149 KB/184 KB received)	188,966/91,903
Software inventory - delta (139 KB/139 KB received - no changes)	261/261
Software metering (14 products run 10 times each; 30 KB/34 KB received)	49,306/16,358
Server locator point requests from client	Advanced Client and Legacy Client
Server locator point IP boundary request	259
Server locator point Active Directory boundary request	260
Server locator point IP and Active Directory boundary request	273
Active Directory Server locator point requests from clients
Advanced Client	5657
Legacy Client	5347
Advanced Client machine policy request	4966
Advanced Client user/user group policy request	8064
Advanced Client policy request reply	200 (if no policy changes; otherwise depends on number of policies)
Advanced Client policy body	Up to 50 KB for regular policies; with software metering, depends on number of software metering rules

Capacity Planning Scenario - Recommendations

Based on the assumptions outlined earlier, you can reasonably expect the following:

Maintain up to 25,000 Advanced Clients per management point per site, including clients at attached secondary sites
Maintain up to 100,000 Advanced Clients per site (reporting directly to the site) if using Windows Network Load Balancing

Other practical recommendations include:

Client Access Points (CAPs)

When considering the number and placement of CAPs:

Maintain no more than 2000 Legacy Clients per CAP
Maintain no more than six CAPs per site

Distribution Points

When determining the number and placement of distribution points:

Consider the kinds of packages you will be distributing and which clients must receive those packages.
Consider the number of clients that must receive the packages and where they are located in your network.
Determine the total available bandwidth between the proposed location of the distribution point and the site server, including when the bandwidth is available and how much can be used for package distribution.
Identify any line of business applications that might be affected when packages are sent to a distribution point and to what extent those applications can be affected.
Identify any line of business applications that might be affected when packages are downloaded from a distribution point and to what extent those applications can be affected.
If you must control how and when bandwidth is used during package distribution, consider deploying a site rather than a distribution point to take advantage of bandwidth controls between sites.
If you must configure more than 20 distribution points, consider deploying sites in remote locations rather than deploying distribution points. Communications between the site server and its distribution points is single-threaded. If communication to any distribution point fails, it could cause distribution to remaining distribution points to fail.

*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.

Configure how may packages that SMS processes 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 that has the correct package contents and version 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

Proxy Management Point

As a best practice, it is recommended that you not install a proxy management point at a secondary site. However, you might need to do so in some very specific circumstances. Consider the following if you are planning for a proxy management point:

Advanced Clients that roam to a secondary site use the proxy management point to obtain their policy.
The proxy management point must contact the SMS site database at the parent site to obtain client policies unless a replicated SMS site database is maintained at the secondary site. This can generate significant network traffic depending on the size of the policy and the number of clients. If there is no new policy assignment from the management point at the parent site, a 200 byte reply message is still generated for every policy request.
If you maintain a replicated SMS site database at the secondary site for the proxy management point to use, you might be able to reduce the amount of traffic related to client policies. However, you then need to maintain another instance of SQL Server, and configure SQL replication of the relevant 35 tables to occur on an appropriately frequent schedule. This generates a different kind of traffic that is potentially significant, and it generates potential security risks that must be addressed. For more information, see “Security Planning” earlier in this book. In this case, the amount of traffic generated might not be any different than if you installed a primary site server instead of a secondary site.

In general, there should be only a few scenarios that support the configuration of a proxy management point in a secondary site. One possible scenario might include the following conditions:

You have a large number of Advanced Clients located at the secondary site,
You need to strictly manage the bandwidth usage between the secondary site and the primary site, and
You need to stage inventory reporting to the primary site server.

In any scenario, it is recommended that you establish baselines for acceptable network utilization, monitor the connection between the secondary site and the primary site, and determine whether you can meet your SLAs for performance through the placement of a proxy management point.

Table 1.7 outlines the network traffic that you can control or throttle between Advanced Clients located at a secondary site and their assigned primary site by using different proxy management point scenarios at the secondary site. If the clients are located at a remote location without benefit of a secondary site, policy requests and replies, inventory and discovery files, and package files are sent across the network with no network bandwidth management.

Table 1.7 Network Traffic Bandwidth Management

Object Type (avg. size)	No secondary site	Secondary site	Secondary site with proxy management point	Secondary site and proxy management point with replicated SMS site database	Primary site instead of secondary site
Policy request (5 KB - 8 KB)	N/A	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Policy body request reply (up to 50 KB for most policies except for software metering rules, which depend on the number of rules that are cached after the first request for the same policy)	N/A	N/A	Data cached on proxy management point	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Discovery Data Record (5 KB)	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Hardware inventory - full (115 KB/125 KB received)	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Hardware inventory - delta (3.5 KB/5 KB received)	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Software inventory - full (149 KB/184 KB received)	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Software inventory - delta (139 KB/139 KB received - no changes)	N/A	N/A	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled
Packages (size depends on package)	N/A; per client	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled	Data transfer between sites can be scheduled

When the clients are located at a secondary site with no proxy management point, only network traffic associated with packages can be managed. If you enable a proxy management point at the secondary site, policy request replies are cached at the proxy management point, and traffic associated with inventory, discovery, and package files can be managed. If you include a replicated SMS site database at the secondary site with the proxy management point, then you can manage traffic associated with policy requests and replies, inventory and discovery files, and package files. However, notice that you can accomplish the same network bandwidth management by deploying a primary site rather than a secondary site.