Microsoft SMS 1.2 Management: Best Practices

Introduction

Microsoft SMS is a systems management solution that provides an array of tools for LAN administrators to monitor and manage their network. From remote control to software distribution, SMS has satisfied a niche that has long been a problem for administrators – control over the hundreds or thousands of machines under their responsibility.

Microsoft SMS is a systems management solution that provides an array of tools for LAN administrators to monitor and manage their network. From remote control to software distribution, SMS has satisfied a niche that has long been a problem for administrators – control over the hundreds or thousands of machines under their responsibility.

With the increased use of SMS for LAN management and business-critical application packaging and deployment, it is important to develop a plan for ongoing systems monitoring, management and troubleshooting. The type of management plan needed depends on many factors including size, criticality and usage of the system. Both the firm’s support organization as well as the LAN administrators can determine this need. Since Microsoft SQL server operates as the engine of SMS, it is important to monitor and manage both systems, regardless of whether or not they are on the same machine or different boxes.

I developed these monitoring requirements because of both the business criticality of deployment services as well as some problems that were encountered when it was too late to prevent them, such as a failed software distribution. With some monitors in place, problems and, more importantly, outages can be prevented and operations can be notified at a stage when they have enough time to proactively react with enough time to fix the problems. The resulting document, excerpted below, covers systems management of the distribution systems.

Prerequisites and Assumptions

There are several prerequisites and assumptions that should be met in order to proceed with the monitoring.

1. The SNMP service must be installed and configured on each server. The SNMP trap destination must be configured to point to a network management console where traps can be viewed, sort or acted upon by the support organization.
2. To track any disk performance monitors, be sure that disk monitoring is enabled by executing “diskperf -y” on the target machine.
3. The SQL specific counters should be installed on all SQL Servers. This is normally done through product installation. If SQL counters are not available, notify the SQL Administrator of that machine to ensure counters are visible.
4. Each server must be installed with the SMS client component. This provides the event-log-to-trap translation e.g. all events added through the event-log-to-trap via the SMSADMIN console will send traps to the Network/Systems Management Console.
5. The SMS specific counters should be installed on the SMS Site Servers using the fiperf.bat file and other associated files from the BackOffice Resource Kit. This will add the “SMS-Files” counter to the performance monitor. See more details in Appendix A.
6. The SQL server is configured to send email when it has completed certain predefined tasks or if predefined alerts are triggered.
7. This document assumes the use of SMS version 1.2 with service pack 3 or later and SQL Server 6.5 with Service Pack 3 or later on Windows NT 4.0 with Service Pack 3 or later.

SMS Management

Severity Legend:

1 = High priority, notify immediately

2 = Medium priority, notify within 1 hour

3 = Low priority, notify within 24 hours.

SQL Server Systems Monitoring

The following information is for SMS-specific SQL Server problems.

Appendix A: FIPERF.BAT: Add File Counters to Performance Monitor

FIPERF adds counters to Performance Monitor that monitor the number, size, and age of files in various directories. This ability is particularly useful in SMS to monitor directories such as SMSSITE.SRVDATALOAD.BOXDELTAMIF.COL.

The name of the new Performance Monitor object is SMS Files. Look at the Explain text in Performance Monitor for definitions of the counters. FIPERF must be run on the computer running the SMS site services.

Usage Notes:

• Do not run these counters with too small a polling interval, which adversely affects server performance because the server continuously scans directories. A reasonable minimum polling interval is one minute, but one hour is recommended.
• The directories that are monitored are stored in the Registry in hkey local machinesystemcurrentcontrolsetSMS FilesLinkage. Add or remove items from this list if you wish (see next note).
• Due to the nature of Performance Monitor, whenever you bring up a list of counters, the counter DLLs are called to return data. This means that a scan of all the directories is performed. If these directories have many files, this could take from a few seconds to a few minutes. If you find that there is a large delay and that there are directories that you do not want to monitor, remove them from the Linkage key.

Removing FIPERF

To remove this software, run the following command (unlodctr is provided with Windows NT):

unlodctr SMS Files

Do not simply delete the Registry keys; you could lose other Performance Monitor counters.

Files required for FIPERF

FIPERF.DLL

SMSPERF.DLL

The following files are required for installing the SMS Files counter, but can be removed after installation:

FIPERF.BAT

FICTRNM.H

FI.INI

Appendix B: Regular SMS Database Maintenance

In order to keep a Systems Management Server site server and it interactions with SQL server operating at peak efficiency, it is necessary to perform periodic maintenance on the SMS database. This is especially important for central site databases that store large volumes of data.

The following maintenance items should be performed approximately every 4 weeks.

PERFORMING MAINTENANCE ON THE SMS DATABASE

Stop the following SMS services on the SMS Site server in the following order:

1. SMS Executive
2. SMS Site Config Manager
3. SMS Hierarchy Manager
4. All other SMS services running on the site server.

1. Close all utilities that make a connection to the SMS database (i.e. SMS Administrator, SMS Database Manager, etc.)
2. (Optional) If a backup of the site has not been made recently, do so with the following steps:

1. Locally, at the Site Server, run REGEDT32.EXE. Highlight the SMS registry key and choose Save Key from the Registry menu: HKEY LOCAL MACHINE SOFTWARE Microsoft SMS
2. Use SQL Enterprise manager to dump (or backup) the SMS database and the master database. Select Tools, Database Backup/Restore.
3. Make a file backup of the SMS directory structure on the SMS site server.

NOTE: Before and after major database operations, always consider running these database consistency checker commands from ISQLW:

• dbcc checkdb
• dbcc newalloc
• dbcc checkcatalog

This will help insure that the operations will go smoothly, and that no damage occurred during the operation. This is especially important in providing intact database backups. This will help cleanup unused allocations, and detect errors in the database. These queries can take a long time to complete on very large databases. System performance and the size of the SMS database determine the actual time required.

1. First from ISQLW run

1. “use sms” – this will select the sms database
2. “dbcc updateusage(0)” – this is done so that sp spaceused will report the current numbers correctly. Normally this only needs to be run after rebuilding the indexes. If not run after rebuilding the indexes, sp spaceused will just report the old numbers as they were before rebuilding the indexes.
3. “sp spaceused” – this will display the current database size, unallocated space, data size, index size and unused space. Save the results for comparison. By analyzing the results of these cleanup procedures an SMS administrator will be able to determine how frequently a specific site should be cleaned up. If the database size is reduced by less than 10%, then the administrator should probably wait longer the next time before taking the time to do these cleanup procedures.

1. Use the SMS Administrator utility to Delete Machine History older than 60 days. (In SMS Administrator, with the Sites window active, choose Edit, Delete Special, and then choose Machine History from the pop down menu.)
2. IMPORTANT NOTE: It is possible to delete too much history information at one time (the amount that can be deleted at one time is determined by the size of the transaction log on the SMS database). Therefore, when deleting large amounts of history records, delete them in increments. For example, if you wanted to delete history records older than 60 days and you know that you have history information extending well past that point (i.e. 260 days), you would begin by deleting machine history older than 240 days, then 210 days, 180 days, 150 days, etc. until the desired 60 days of history is reached.

If you try to delete too much information at one time, you might get the “Couldn’t complete the specified query” error in SMS Admin. This means that the transaction log did not have enough free space to process this mass delete. You can either dump the transaction log by right clicking on SMS database in SQL Enterprise Manager, select Edit, in the Edit Database window, select “Truncate” under Transaction Log. Alternatively, you can expand the size of the transaction log by selecting Expand.

1. Again from isqlw run

1. “dbcc updateusage(0)” and
2. “sp spaceused” with the SMS database selected as default and save the results for comparison.

1. Delete inactive machines in SMS Administrator. If inventory is reported regularly, it also a good idea to delete inactive machines from the database. In SMS Administrator, with the Sites window active, choose Edit, Delete Special, and then ensure that ‘Machines with last activity‘ is the option selected. Be careful not to enter a date or period that is too recent. For example, For both Tier I and Tier II you should delete systems that have been inactive for 60 days. Close the SMS Administrator utility.
2. Again from isqlw run

1. “dbcc updateusage(0)” and
2. “sp spaceused” with the SMS database selected as default and save the results for comparison.

1. Delete duplicate machines in SMS Database Manager. If the SMS client is reinstalled on the same system, this can result in duplicate inventory records in the SMS database. Since only one record in the database can be active for a specific machine, the previous step to delete inactive machines would eventually delete duplicates as they aged in the database. Duplicate machines can also be viewed and deleted from the SMS Database Manager utility. Open the SMS Database Manager utility, select Machines, Display Duplicate Computers, click on Name, and delete all but the most recent entry for each machine listed. You can also highlight the duplicate machine records and select “Merge history for selected PCs” from the Edit option to merge duplicates. This would delete all the old inventory records and only keep the newest machine record. If necessary, repeat these steps for the systems listed under NetCardID.
2. Again from isqlw run

1. “dbcc updateusage(0)” and
2. “sp spaceused” with the SMS database selected as default and save the results for comparison.

1. From the SMS Database Manager utility, select Tools, then Delete Unused Common/Specific Records. This actually purges the deleted records in SQL and will reclaim space in the SMS database so that SQL server can reuse it. This procedure can take a long time as well. The amount of time required depends on how often the procedure is performed and how much space is going to be reclaimed. This procedure should be performed every 90 days .Close the SMS Database Manager utility.
2. Again from isqlw run

1. “dbcc updateusage(0)” and
2. “sp spaceused” with the SMS database selected as default and save the results for comparison.

If any machines or records were removed, the indexes need to be rebuilt to remove the old index entries. You can skip steps 13 and 14 if many machines or records were not deleted from your site.

1. Reducing the index space used by an SMS database: On a large central site that had been in use for several months, rebuilding the indexes reduced the space used by indexes by 50%, and total space used by the database went from 305megs to 225megs. The actual amount of reduction will depend on how many records have been deleted since the last time the indexes were rebuilt, and how fragmented the indexes have become. This will reduce paging, which will help avoid a disk bottleneck and reduce the disk space used by the SMS database and its backups. This procedure should be performed every 90 days.
2. Use the SQLMAINT.EXE utility to rebuild the SQL indexes on the SMS database. This utility is supplied with SQL Server 6.5 and is located in the MSSQLBINN directory. With mssqlbinnsqlmaint.exe in the path; from the NT CMD command line run:

   SQLMAINT.EXE -S h1grsvr -D smsdb -RebldIdx 10 -Rpt c:dbmaint.rpt

   Where h1grsvr is the name of the server that SQL is on, smsdb is the name of the SMS database on which all indexes for all tables will be rebuilt, 10 is the percent of free space that will be left in the indexes, and C:dbmaint.rpt is the location for the log reporting results. The procedure builds a table of all index information for the database, and then walks through rebuilding each index individually.

3. Then with the SMS database selected as default, from isqlw run
4. “dbcc updateusage(0)”

   This is done so that sp spaceused will report the current numbers correctly. If not run, sp spaceused will just report the old numbers as they were before rebuilding the indexes. Then again from isqlw run “sp spaceused” with the SMS database selected as default, and see the results. There should be large savings in index space used (unless this was recently done).

   (Optional) If all of the maintenance tasks have completed without errors, this is another good point to create a backup of the SMS system. Refer to step 3 to accomplish this if desired.

   NOTE: Before and after major database operations, always run these database consistency checker commands from ISQLW:

   dbcc checkdb

   dbcc newalloc

   dbcc checkcatalog

   This will help insure that the operations will go smoothly, and that no damage occurred during the operation. This is especially important in providing intact database backups. This will help cleanup unused allocations, and detect errors in the database. These queries can take a long time to complete on very large databases. System performance and the size of the SMS database determine the actual time required.

5. Restart the SMS Services in the following order:

1. SMS Hierarchy Manager
2. SMS Site Config Manager
3. SMS Executive
4. d. Restart all other SMS services on the site server.

Appendix C :How to delete client history files:

To ensure accurate data reporting, it is recommended that you first delete the client’s history file. This file is used to reduce network traffic and processing load on the server. Deleting this file will not have any negative effects on the Systems Management Server system.

To delete the history file:

1. Determine the client’s SMSID by examining its Sms.ini file (a hidden file located in the root of the client’s SMS installation drive). The SMSID is stored within the [SMS] section as “SMS Unique ID.”
2. On the site server, go to the SmsSite.srvInventry.boxHistory directory, and delete the client’s history file. It is named SMSID.hms (for example, Abc00001.hms).

Appendix D: Troubleshooting Inventory MIF Backlog Problems

NOTE: Before you begin troubleshooting, dump the Systems Management Server and Master databases and then back up the Systems Management Server directory structure and the HKEY LOCAL MACHINESOFTWAREMicrosoftSMS registry key.

Site Speed

The site speed (set in Site Properties on the Services tab) should never be set to Very Fast. A setting of Medium or Fast will process MIFs faster because the Site Configuration Manager does not have to continually perform watchdog cycles which gives the Dataloader utility a chance to run uninterrupted for a longer period of time.

SQL Server Configuration

If Open Objects is set to less than 5,000, Dataloader can get backed up. Tempdb should be 20 to 30 percent of the largest database on the SQL Server. User connections must be set appropriately. Currently they are set at 100.

For additional information about important tuning parameters, see the following article in the Microsoft Knowledge Base:

ARTICLE-ID: Q166244

TITLE : SMS: SQL Server Tuning Parameters for Systems Management

Server

Use Performance Monitor to check the Cache Hit Ratio and make sure that the database is in cache (it should be above 99 percent), not paging out. Add RAM and/or dedicated memory to SQL Server if necessary.

Database and Transaction Log Size

Make sure that the Systems Management Server database and its transaction log are not full, and that the transaction log is 20 percent of the Systems Management Server database size. If the database is less than 20 percent free, failures may occur.

Services

Make sure that the Systems Management Server Executive Service is running on the site server.

Client Resynchronizations

Check the Windows NT event log for a high number of client resynchronizations (Event 186). If there are several resyncs, they may occur because duplicate SMSIDs are assigned. For additional information, please see the following articles in the Microsoft Knowledge Base:

ARTICLE-ID: Q127052

TITLE : SMS Unique ID (SMSID) Allocation

ARTICLE-ID: Q138021

TITLE : How Inventory Dataloader Finds Matching Computers in SMS

SQL Server Service Pack

Apply (or re-apply) the latest SQL Server Service Pack.

SQL Server Tracing

You can enable SQL statement input and output in the Dataloder.log by setting the

HKEY LOCAL MACHINESoftwareMicrosoftSMSTracingSQL Enabled

registry parameter to 1. To disable SQL tracing, set the value to 0.

The Systems Management Server Executive service must be stopped and restarted for the change to take effect.

NOTE: SQL Tracing should be disabled when you are not performing troubleshooting steps. Leaving it enabled causes the Dataloader to slow down and the log to fill up more quickly.

DBCC Checks

Run SQL Server DBCC CHECKDB and DBCC NEWALLOC statements on the Systems Management Server database in Single User Mode.

Site Reporter

Check the ..SMSSite.srvSiterep.box to see if files are present. If there are, and the site is a child primary site, ensure that site-to-site communication is functioning properly. To determine this, do the following:

Look in the appropriate sender log.

Check the addresses.

Check the Windows NT Application Event Log.

Check the Outbox scheduling.

If files are present in the Siterep.box subdirectory, temporarily move them to another subdirectory to see if the MIF processing improves.

User Group MIFS

Check the SMSSite.srvDataloder.boxDeltamif.col directory for UMF files. If there are several UMF files, and they are large, you probably have a large number of users, groups, or a complicated trust matrix in your environment.

You may want to change the default polling interval for user and group enumeration using the Setgug.exe utility. For additional information about the utility, please see the following articles in the Microsoft Knowledge Base:

ARTICLE-ID: Q168724

TITLE : SMS: List of Tools Available on the SMS 1.2 Compact Disc

ARTICLE-ID: Q171005

TITLE : SMS: Site Config Manager Service Locks Trusted Service

Account

MIF Size

Check the SMSSite.srvDataloder.boxDeltamif.col and SMSSite.srvDataloder.boxDeltamif.colProcess directories and note the MIF size. Larger MIFs (that is, MIFs that contain custom information or extensive software inventory) will be processed more slowly.

I/O Errors

• If SQL Server devices and Systems Management Server directories are on the same drive or the drive is mirrored with a single disk controller, check for I/O disk errors reported in the SQL Server log file and/or Performance Monitor.
• If disk I/O appears to be a bottleneck, you may need to move SQL Server devices to another physical disk drive, install a second controller, and so forth.

SMSMaint Script

Run the SMSMaint.sql script from the BackOffice Resource Kit.

SPID Performance

Monitor the SQL Server spid performance by using SQL WHO and Performance Monitor to correlate this to the Dataloader thread. For additional information, see the following article in the Microsoft Knowledge Base: