IMPROVE THE EFFICIENCY OF YOUR INSTALLATION
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.
Previous
Register
