SMS Tuning Tips

Although Systems Management Server (SMS) is a useful tool, it is also a complex product that requires regular care and attention. To use SMS to its full potential, you must understand the distribution process, which I describe in "SMS Software Distribution ," page 98. Here's an assortment of tips and suggestions for improving the efficiency of your SMS installation.

Use Care Sending Packages
In a large SMS installation with a large number of child sites, sending packages to sites lower in the SMS hierarchy can cause delays. During distribution of a workstation package that is targeted to a large number of workstations that span two or more child sites, SMS performs a great deal of processing to create jobs for each site and to track the status of the job. If the target workstation population is more than a few hundred, this delay can be almost 20 minutes. Rather than take the easy way out and send the package directly to the workstations in all sites, target the sites where the package is needed and use a manual fan-out method to reduce the delay.

In a manual fan-out, create a job in the SMS central site and use the Send Phase option on the Job Details window to instruct SMS to distribute the package to the child sites only. In each child site, create a job to distribute the package to the distribution servers and workstations: Use one of the Distribution Phase options on the Job Details window and select Run Command on Workstation. Each child site will perform distribution to the distribution servers and workstations in parallel with the other child sites. This method creates more manual work than just going to the highest level of the hierarchy and sending to everything but will reduce the amount of processing and reduce the total time to distribute a package to many workstations at several child sites.

When you send a package that you've already sent to another workstation in that site, remember to clear both check boxes under Distribute Phase in the Job Details window. The first time you send a package to a workstation in a site, SMS copies the package to the distribution servers in the site. But once you've sent the package, unless it changes, you don't need to resend it to the distribution servers. The default option in the SMS Administrator user interface (UI) recopies the package to all distribution servers within the site before updating the package command manager for the workstations. Be sure to change this option when doing a distribution.

Use separate jobs to distribute packages to child sites and different jobs to distribute packages to the distribution servers and to instruct workstations to run the packages. Although SMS can do both in one job, you'll avoid accidentally resending the package to the distribution server when you use separate jobs. To send packages to the distribution servers but not the workstation, ensure that the Run Phase check box on the Job Details window is not selected. Screen 1 shows the SMS Job Details window with the Send Phase, Distribute Phase, and Run Phase set to create a Run Phase only, Run Workstation Command and to not resend packages to target servers or resend the package to the distribution servers.

Put SQL on a Separate Box
SMS heavily uses SQL Server--particularly for processing inventory Management Information Format (MIF) files and creating jobs to send packages to workstations--because of the large number of queries SMS performs. (For more information on SMS and MIF files, see Mark Eddins, "Customizing Systems Management Server," January 1997.) Ideally, put SQL on a dedicated server, particularly for the central or most heavily used site. This way, you can dedicate the memory to SQL and not share it with SMS.

If you can't dedicate a server for the SQL Server that SMS uses, ensure that enough memory is available to support all processes active on the shared server. SQL Server and SMS make heavy demands for storage. Allocate at least 32MB of RAM for SQL, 18MB for SMS, and 32MB for Windows NT. For a larger site, additional memory lets SQL cache the database and ensure that the active processes in SMS are not causing page faults fighting over the same memory. Microsoft makes these minimum recommendations in the SMS concepts and planning guide. Monitor the Performance Monitor Memory Object, Committed Bytes, regularly to determine memory requirements: The higher this value, the greater the demand for storage. If the value is consistently greater than the total physical memory in the server, the program is paging and you might need more memory.

Don't Delete Active Jobs To remove active jobs, don't just delete them from the SMSADMIN UI. Although this method eliminates the file from the database, it leaves orphan instruction files. When SMS creates a job, the SMS Scheduler creates instruction files (INS files), which are simple text files copied from directory to directory with a store-and-forward approach. These files remain until the job completes or you cancel it. Deleting the job via the UI deletes only the records in the SQL database; it doesn't clean up the orphan instruction files that may have been already sent out.

The system will continue to attempt processing these orphan instruction files, creating unnecessary overhead. Instead, cancel the job first using the SMSADMIN. After the job confirms a canceled status, delete it.

If you worry about orphan jobs, look in the \sms\site.srv\sender.box\request\lan.def.000 directory on each SMS primary site. Using Notepad, edit each INS file and note each job's SMS ID number. Check job status in the SMSADMIN Jobs window. If a job's status isn't Pending or Active for one of these SMS IDs, the job is an orphan. Delete the INS file to halt further processing.

Get Rid of Old Retrying Jobs
SMS will retry jobs when it is unable to complete them. For example, SMS will retry a system job if SMS is trying to send to a site that is no longer in operation. Retrying jobs takes a large amount of overhead, particularly if the job's target was several hundred workstations. Even if all the workstations but one have successfully completed processing, SMS will requery the status of all target workstations each time it retries the job.

Issue the Cancel job command in SMSADMIN to cancel any job that has retried for more than 48 hours. Resend the job, avoiding those sites or workstations where the job has successfully completed. On a large distribution to thousands of workstations, you can have a hundred or more workstations with jobs that can take several days to complete distribution. When SMS retries a job, it needs to check the entire original target to determine which workstations haven't completed, even if 900 out of 1000 have completed successfully. Cancel the retrying job and redistribute the load, targeting only the workstations that didn't get the package the first time, to avoid checking the 900 that did receive the package.

SMS creates system jobs automatically. Although system jobs are sometimes in a retry state, you can't cancel them via SMSADMIN. To eliminate the bottleneck, get rid of old system jobs: Use WISQL to issue a SQL Statement DELETE * FROM JOBS WHERE JOBID = (the ID of the system job you want to delete). You must follow up and delete the INS files from the sender.box just as you do for nonsystem jobs.

Or, you can search the SMS log in Notepad for a retrying job ID and read the name of the INS file and the target site to learn why the job is retrying (e.g., the site is no longer in operation.) Cancel these jobs only if they're not going to complete because of site problems.

Remember that Microsoft doesn't support the procedure for accessing the SQL database directly and deleting data. But in a large installation when a lot of system jobs are retrying, you might need to use this procedure. Be sure that you have up-to-date backups of the SMS SQL database in case of problems.

Add SMS Senders and SQL Connections
Adjust the number of simultaneous distributions that SMS can support, particularly if you have a large number of child sites. You can tune many default values in SMS and SQL Server to your installation's particular needs.

Use the Sender Manager tool (sndrmgr.exe) to increase the number of Total Concurrent Sessions and Maximum Sessions Per Destination Site for each site that has secondary sites. The total must be one greater than the number of child sites connected.

SQL Server can also control the number of simultaneous connections; the default is 10. If you have more than two child sites, use the SQL Enterprise administration tool to increase the User Connections system parameter to 5 * (number of child sites + number of SMSADMIN users).

Screen 2 shows the SQL Enterprise Manager Server Configuration window. To increase User Connections, change the value on this screen, shut down, and restart SQL Server.

Adjust Size and Location of Database
Pay close attention to the size of the SMS database and TEMPDB in SQL Server. Allocate a separate SQL data device for the SMS database and log; otherwise you can't issue a SQL DUMP DATABASE command while the database is open. (Don't confuse a SQL device with a disk drive or volume set. A SQL device is a file allocated on an NT file system, inside which SQL Server can allocate one or more databases or log files.)

Size the SMS data device and database at least as large as the following calculation: 35KB * number of workstations + packages + groups + icons = size of site data device and database. For the SMS database log device and log, allocate 15 percent of the size of the SMS database.

The default installation of SQL Server creates a 2MB TEMPDB, which is far too small. With SMS, TEMPDB must be large enough to handle results sets from SMS internal queries and sorts for machine groups or sites. Define TEMP DB as at least 25 percent of the size of the SMS database. Unlike the SMS database and log, each of which has a separate SQL device, you must allocate TEMPDB so that the database and log use the same SQL device. Allocating TEMPDB in RAM improves the performance of some applications that do sorts or outer joins of tables. Because SMS uses TEMPDB only for a subset of its operation, allocating TEMPDB in RAM doesn't really help SMS. This rule is particularly true if allocating TEMPDB in RAM takes memory away from the pool of available memory for SQL to do database caching and reduces the amount available for SMS or general file system cache.

When you do a large number of workstation installations or package distributions, running out of space in the database logs is common. Review the allocation, and monitor the space utilization. If any database utilization exceeds 60 percent, expand the database. Back up the SMS database daily with the SQL DUMP DATABASE command, which will also clear the log. If you start getting SMS Database Full messages in the SMS log, you can also issue DUMP TRAN (databasename) WITH NO_LOG to clear the log.

Set the Truncate log on checkpoint for TEMPDB. This global parameter affects any application using this SQL Server. Setting this option is sometimes not possible if applications that require greater recoverability share the SQL Server.

Reduce SMS Logging
Reduce logging overhead to improve SMS efficiency. Turn off as many SMS logs as you can, and put the SMS log on a separate physical disk. For example, you seldom need the ALERTER and INVPROC logs.

SMS sets tracing to automatically start when SMS services start. You can disable tracing via the SMS Service Manager, but the next time you start SMS, it will enable tracing again. To disable tracing for individual services, use the Registry editor (regedt32.exe) to open HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\SMS\TRACING on the SMS site server system. For each service, open the Registry key (for example, SMS_ALERTER or SMS_INVENTORY_DATA_LOADER) and change the subkey value to 0 to disable tracing.

Placing the SMS logs on a separate physical disk device also reduces logging overhead. SMS uses a forced write, which flushes the disk cache and forces an I/O. This procedure ensures that SMS writes all logs to disk to help determine problems. But this procedure will seriously affect the performance of other system components, such as the SQL log, if the SMS logs are on the same device.

Reduce Duplication
Don't distribute the same DLLs with every package: If you use SMS to distribute several applications written with tools such as Visual Basic or Powerbuilder, you can distribute several megabytes of duplicate files with each package. But this process takes unnecessary time and wastes disk space on the client workstation and the distribution servers.

Move the runtime DLLs from the application package, and create a package for the shared elements only. Put these DLLs in the Windows System or System32 directory, and you won't need an addition to the path.

Use Server Shares
Share off Server Share Packages distributes faster than Run Command on Workstation Packages. The ability to share server packages makes the distribution quicker. When an update occurs, SMS must query all workstations that a package resides on. The server share helps the space on the client machines and allows quicker distribution. However, a Share off Server Share Package can increase network traffic and reduce response time. Consider both factors when deciding which way to distribute a package.

Updating a server share package is difficult because SMS typically can't replace files on the distribution server for an application that is in use. With SMS 1.2, you can make an NT Server Registry change to force a release of the open files and let SMS update the files. To enable this feature, on the SMS site server, change the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_Despooler and set the Forced Disconnect Key to 1. Be aware that this procedure can abnormally exit a user from an application. To get around this problem, distribute a new package for the update. Once you've successfully distributed the package, update the icon in the program group to point to the new package.

Reduce Inventory Frequency
Using frequent inventory collection intervals can swamp a system in no time. SMS needs to take inventory once a week or less often, if possible.

To see how busy your system is when it processes inventory, look at the timestamp on the MIF files in the \site.srv\inventry.box\ subdirectory. If you have more than 30 minutes to an hour backlog at the hours of peak login, you can overload your SMS server.

Clean Up Database
Run the DBClean utility monthly to clean old history records, collected files, and deleted and duplicate systems. Unnecessary rows in the database slow the system.

Make SMSADMIN Load Faster
When you launch SMSADMIN, by default it opens the sites window and runs a background query against all computers in the site hierarchy. This process can be time consuming in a large installation when you log on to the central site, particularly if you're using Remote Access Service (RAS) or some other slower link back to the SQL Server.

Open the PREFERENCES dialog in the SMSADMIN, and disable the background query. SMSADMIN will load 20 seconds to 30 seconds faster.

Upgrade
Many people postpone maintenance for months for fear of disrupting a stable environment. With SMS, get to the latest software levels fast. Upgrade to SMS 1.2 Service Pack 1 and SQL 6.5 Service Pack 2 on all your SMS sites. Download the upgrades from Microsoft's Web site at http://www.microsoft.com/kb/softlib. These levels fix many bugs that have plagued SMS since its introduction. Microsoft has concentrated on stability-enhancing bug fixes for the past nine months instead of adding sexy new features. Do yourself a favor and implement the fruits of Microsoft's hard work.

SMS Tuning Tips RELATED ARTICLES IN WINDOWS NT MAGAZINE
Nathaniel Bowman,
- "SMS Server and Client Setup," June 1996
- "SMS Server and Client Setup, Part 2," July 1996
Mark Eddins,
- "Customizing Systems Management Server," January 1997
- "Customizing Graphics for SMS Custom Inventory Objects," March 1997
Spyros Sakellariadis,
- "SMS: Inventory Your Desktop Systems, Part 1," May 1996
- "SMS: Inventory Your Desktop Systems, Part 2," June 1996
- "SMS: Inventory Your Desktop Systems, Part 3," July 1996

To properly use SMS as a software distribution tool, you must understand how SMS performs distribution. Distribution to a workstation is a three-phase operation.