The following optimization guidelines will aid in the optimization of Systems Management Server as part of a Microsoft BackOffice solution. Optimal application of these guidelines are unique to each environment. Thus, you may wish to experiment with different configurations and values, in order to arrive at the best combination of settings for your particular Microsoft BackOffice environment.
Plan for the appropriate disk space required for package installation and distribution. On a site server, package files associated with a single package will exist in four locations. Hence, the overhead associated with the storage can be substantial.
Delete packages when no longer needed in order to save disk space.
If Systems Management Server is to share the Microsoft BackOffice hardware platform with other Microsoft BackOffice applications, then consider installing the Systems Management Server system software on a dedicated disk subsystem. This may comprise a dedicated intelligent disk controller and dedicated disk drive units, which may be configured as a RAID array.
Appropriately set Systems Management Server service polling and scan intervals to values consistent with the system work load and resource usage. In other words, some interval values may be set to run services at off-peak hours, thus conserving precious system resources during heavy work load periods.
As polling intervals are shortened, Systems Management Server places greater stress on the Microsoft BackOffice server. As interval values increase, information flow throughout the Systems Management Server environment is slowed and therefore may not be as timely.
Due to potential resource limitations on a single Microsoft BackOffice hardware platform the following Systems Management Server Executive service components may be moved to Systems Management Server Helper servers. Accordingly, work load may be balanced across several Microsoft BackOffice hardware platforms:
Scheduler
Despooler
Inventory Data Loader
Inventory Processor
Sender(s)
Systems Management Server conducts compression of job packages. This compression activity may often be a factor in CPU saturation, especially if other Microsoft BackOffice processes require CPU resources. Thus, the level of compression may be set by adjusting the Windows NT Server registry value for compression. The registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Systems Management Server\Compression, may be set to a value of 1 to 7. 7 being the highest level of compression and thus most resource intensive.
To keep the SMS_Site_Config_Manager service from overwriting manual modifications to the registry, set <SMS Root>\Sites\<Site code>\Properties\Service Responcs\data = FFFFFFFF.
There will be no visual feedback to the Systems Management Server administrator that the Systems Management Server feature has been disabled, nor will there be any visual feedback to the Systems Management Server administrator that future changes to the response controls in the service control dialog will not have any effect.
The SMS_Inventory_Agent_NT service wakes up on a configurable interval to perform a scan on Windows NT–based computers on which it is installed. The default value is to perform a scan once a day. If you want to have this scan performed more or less often the set the value of <SMS Root>\Components\SMS_MAINTENANCE_MANAGER\Inventory Agent Service Interval. This value represents the number of minutes that the inventory agent will wait between performing scans.
The application manager thread in the Systems Management Server executive monitors the database to create program group and software inventory control files. There is a queueing period from when a change is detected to when the new files are sent out. (The assumption being that another program group change or inventory rule change may occur shortly if one change has just occurred.) To change this queueing time, set the value of <SMS Root>\COmponents\SMS_Applications Manager\Processing Delay. This is the number of minutes the service waits before creating the jobs to send this information to child sites.
Each sender has a number of parameters that can be set to control how long to wait to try to reestablish a connection to a remote site, how many times to try to reestablish a dropped sessions, and how many concurrent outbound channels to start.
These settings can be changed by modifying values under <SMS Root>\Components\<Sender name>.
For the LAN sender, maximum concurrent sendings controls how many threads will be allocated at one time to service send request files.