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.