SMS Tuning Tips

IMPROVE THE EFFICIENCY OF YOUR INSTALLATION

Although Systems Management Server (SMS) is a useful tool, it is also acomplex product that requires regular care and attention. To use SMS to its fullpotential, 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, sendingpackages to sites lower in the SMS hierarchy can cause delays. Duringdistribution of a workstation package that is targeted to a large number ofworkstations that span two or more child sites, SMS performs a great deal ofprocessing to create jobs for each site and to track the status of the job. Ifthe target workstation population is more than a few hundred, this delay can bealmost 20 minutes. Rather than take the easy way out and send the packagedirectly to the workstations in all sites, target the sites where the package isneeded 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 SendPhase option on the Job Details window to instruct SMS to distribute the packageto the child sites only. In each child site, create a job to distribute thepackage to the distribution servers and workstations: Use one of theDistribution Phase options on the Job Details window and select Run Commandon Workstation. Each child site will perform distribution to thedistribution servers and workstations in parallel with the other child sites.This method creates more manual work than just going to the highest level of thehierarchy and sending to everything but will reduce the amount of processing andreduce the total time to distribute a package to many workstations at severalchild sites.

When you send a package that you've already sent to another workstation inthat site, remember to clear both check boxes under Distribute Phase in the JobDetails 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'vesent the package, unless it changes, you don't need to resend it to thedistribution servers. The default option in the SMS Administrator user interface(UI) recopies the package to all distribution servers within the site beforeupdating the package command manager for the workstations. Be sure to changethis option when doing a distribution.

Use separate jobs to distribute packages to child sites and different jobsto distribute packages to the distribution servers and to instruct workstationsto run the packages. Although SMS can do both in one job, you'll avoidaccidentally resending the package to the distribution server when you useseparate jobs. To send packages to the distribution servers but not theworkstation, ensure that the Run Phase check box on the Job Details window isnot 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 WorkstationCommand and to not resend packages to target servers or resend the package tothe distribution servers.

Put SQL on a Separate Box
SMS heavily uses SQL Server--particularly for processing inventoryManagement Information Format (MIF) files and creating jobs to send packages toworkstations--because of the large number of queries SMS performs. (For moreinformation on SMS and MIF files, see Mark Eddins, "Customizing SystemsManagement Server," January 1997.) Ideally, put SQL on a dedicated server,particularly for the central or most heavily used site. This way, you candedicate 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 thatenough 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 RAMfor SQL, 18MB for SMS, and 32MB for Windows NT. For a larger site, additionalmemory lets SQL cache the database and ensure that the active processes in SMSare not causing page faults fighting over the same memory. Microsoft makes theseminimum recommendations in the SMS concepts and planning guide. Monitor thePerformance Monitor Memory Object, Committed Bytes, regularly to determinememory requirements: The higher this value, the greater the demand for storage.If the value is consistently greater than the total physical memory in theserver, 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. Althoughthis method eliminates the file from the database, it leaves orphan instructionfiles. When SMS creates a job, the SMS Scheduler creates instruction files (INSfiles), which are simple text files copied from directory to directory with astore-and-forward approach. These files remain until the job completes or youcancel it. Deleting the job via the UI deletes only the records in the SQLdatabase; it doesn't clean up the orphan instruction files that may have beenalready sent out.

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

If you worry about orphan jobs, look in thesmssite.srvsender.boxrequestlan.def.000 directory on each SMS primarysite. Using Notepad, edit each INS file and note each job's SMS ID number. Checkjob status in the SMSADMIN Jobs window. If a job's status isn't Pending orActive for one of these SMS IDs, the job is an orphan. Delete the INS file tohalt further processing.

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

Issue the Cancel job command in SMSADMIN to cancel any job that has retriedfor more than 48 hours. Resend the job, avoiding those sites or workstationswhere the job has successfully completed. On a large distribution to thousandsof workstations, you can have a hundred or more workstations with jobs that cantake several days to complete distribution. When SMS retries a job, it needs tocheck the entire original target to determine which workstations haven'tcompleted, even if 900 out of 1000 have completed successfully. Cancel theretrying job and redistribute the load, targeting only the workstations thatdidn't get the package the first time, to avoid checking the 900 that didreceive the package.

SMS creates system jobs automatically. Although system jobs are sometimes ina 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 * FROMJOBS WHERE JOBID = (the ID of the system job you want to delete). You mustfollow up and delete the INS files from the sender.box just as you do fornonsystem jobs.

Or, you can search the SMS log in Notepad for a retrying job ID and read thename 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 goingto complete because of site problems.

Remember that Microsoft doesn't support the procedure for accessing the SQLdatabase directly and deleting data. But in a large installation when a lot ofsystem jobs are retrying, you might need to use this procedure. Be sure that youhave 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 manydefault values in SMS and SQL Server to your installation's particular needs.

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

SQL Server can also control the number of simultaneous connections; thedefault is 10. If you have more than two child sites, use the SQL Enterpriseadministration 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. Toincrease User Connections, change the value on this screen, shut down, andrestart SQL Server.

Adjust Size and Location of Database
Pay close attention to the size of the SMS database and TEMPDB in SQLServer. 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 isopen. (Don't confuse a SQL device with a disk drive or volume set. A SQL deviceis a file allocated on an NT file system, inside which SQL Server can allocateone or more databases or log files.)

Size the SMS data device and database at least as large as the followingcalculation: 35KB * number of workstations + packages + groups + icons = size ofsite data device and database. For the SMS database log device and log, allocate15 percent of the size of the SMS database.

The default installation of SQL Server creates a 2MB TEMPDB, which is fartoo small. With SMS, TEMPDB must be large enough to handle results sets from SMSinternal queries and sorts for machine groups or sites. Define TEMP DB asat least 25 percent of the size of the SMS database. Unlike the SMS database andlog, each of which has a separate SQL device, you must allocate TEMPDB so thatthe database and log use the same SQL device. Allocating TEMPDB in RAM improvesthe 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 inRAM doesn't really help SMS. This rule is particularly true if allocating TEMPDBin RAM takes memory away from the pool of available memory for SQL to dodatabase caching and reduces the amount available for SMS or general file systemcache.

When you do a large number of workstation installations or packagedistributions, running out of space in the database logs is common. Review theallocation, and monitor the space utilization. If any database utilizationexceeds 60 percent, expand the database. Back up the SMS database daily with theSQL DUMP DATABASE command, which will also clear the log. If you start gettingSMS 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 affectsany application using this SQL Server. Setting this option is sometimes notpossible if applications that require greater recoverability share the SQLServer.

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

SMS sets tracing to automatically start when SMS services start. You candisable tracing via the SMS Service Manager, but the next time you start SMS, itwill enable tracing again. To disable tracing for individual services, use theRegistry editor (regedt32.exe) to openHKEY_LOCAL_MACHINESOFTWAREMICROSOFTSMSTRACING on the SMS site server system.For each service, open the Registry key (for example, SMS_ALERTER orSMS_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 loggingoverhead. SMS uses a forced write, which flushes the disk cache and forces anI/O. This procedure ensures that SMS writes all logs to disk to help determineproblems. But this procedure will seriously affect the performance of othersystem 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 todistribute several applications written with tools such as Visual Basic orPowerbuilder, you can distribute several megabytes of duplicate files with eachpackage. But this process takes unnecessary time and wastes disk space on theclient workstation and the distribution servers.

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

Use Server Shares
Share off Server Share Packages distributes faster than RunCommand on Workstation Packages. The ability to share server packages makesthe distribution quicker. When an update occurs, SMS must query all workstationsthat a package resides on. The server share helps the space on the clientmachines and allows quicker distribution. However, a Share off Server SharePackage can increase network traffic and reduce response time. Consider bothfactors when deciding which way to distribute a package.

Updating a server share package is difficult because SMS typically can'treplace files on the distribution server for an application that is in use. WithSMS 1.2, you can make an NT Server Registry change to force a release of theopen files and let SMS update the files. To enable this feature, on the SMS siteserver, change theHKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSComponentsSMS_Despooler and set theForced Disconnect Key to 1. Be aware that this procedure can abnormally exit auser from an application. To get around this problem, distribute a new packagefor the update. Once you've successfully distributed the package, update theicon 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 thetimestamp on the MIF files in the site.srvinventry.box subdirectory. If youhave more than 30 minutes to an hour backlog at the hours of peak login, you canoverload your SMS server.

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

Make SMSADMIN Load Faster
When you launch SMSADMIN, by default it opens the sites window and runs abackground query against all computers in the site hierarchy. This process canbe 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 slowerlink back to the SQL Server.

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

Upgrade
Many people postpone maintenance for months for fear of disrupting a stableenvironment. With SMS, get to the latest software levels fast. Upgrade to SMS1.2 Service Pack 1 and SQL 6.5 Service Pack 2 on all your SMS sites. Downloadthe 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 ninemonths instead of adding sexy new features. Do yourself a favor and implementthe fruits of Microsoft's hard work.

SMS Tuning Tips RELATED ARTICLES IN WINDOWS NTMAGAZINE
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," March1997
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 mustunderstand how SMS performs distribution. Distribution to a workstation is athree-phase operation.