Microsoft's Systems Management Server (SMS) is a product of power and flexibility that can greatly enhance a company's ability to manage its distributed computer environment. But with this power comes responsibility. Not only must you plan, design, configure, and maintain SMS's components but also optimize their performance. Here are seven tips on how to optimize some of SMS's components, including Service Pack 3 (SP3), SQL Server, software distribution, history files, inventory, Remote Access Service (RAS) clients, and SMS Administrator machines. (For more information about SMS, see "Related Articles in Windows NT Magazine," page 147.)
TIP 1: Install SMS SP3
The most recent addition to the optimization arsenal is SMS SP3, which offers several important performance enhancements for SMS client processing. For example, suppose you want to add a Windows 95 client to an SMS site. You can either run smsls.bat from a logon script or connect to an SMS logon server and execute runsms.bat manually. In either case, the SMS batch file first calls the appropriate client setup program (cli_dos.exe for a Win95 client), which copies SMS files to the client and configures SMS client and inventory components. The client setup program then reads the appropriate copy list file (cl_w95.txt for a Win95 machine) from the SMS logon server to determine which files to copy to the client. Listing 1, page 146, shows the STANDARD NETWORK FILES section of the cl_w95.txt file with SP2. Listing 2, page 146, shows the same section with SP3.
Before SMS 1.2 SP3, many of the client configuration and inventory programs were executed from the logon server and run over the network. As a result, users often had to wait a long time for the logon process to complete, especially over slow links. With SP3 installed, the copy list file instructs SMS to copy many of these configuration and inventory programs directly to the client's local hard disk. Although this setup results in a slightly larger disk space requirement, it yields faster logon times and reduces network traffic between the logon server and client. In tests, we found that an SMS Win95 client with SP2 used about 2MB of disk space. The same client with SP3 installed used about 3.2MB of disk space. More important, SP3 reduced the amount of data transferred over the network between the client and logon server by about 60 percent. We achieved these values with all client options turned on and hardware inventory being taken with each logon. The extra 1.2MB of disk space on each client is a small price to pay for a 60 percent reduction in network traffic between the client and server with each logon.
TIP 2: Tune SQL Server
SMS uses SQL Server in many of its operations. Thus, to optimize SMS's performance, you must optimize SQL Server's performance. Opportunities for performance improvement include dedicating specific processors to SQL Server, using NTFS, and taking advantage of two SQL Server scripts (smsmaint.sql and chksms.sql).
Dedicate processors to SQL Server. When Windows NT runs a process on a multiprocessor system, you can't be sure which processor will run which thread or even that the same processor will run the same thread. A process thread can migrate from processor to processor, causing reloading of the processor cache. This reloading of the processor cache can cause a decline in performance. By dedicating specific processors to SQL Server, you can reduce the reloading of processor caches, thereby increasing performance.
Processor affinity is the association between a processor and a thread. You can set processor affinity in SQL Server 6.5 with the Affinity Mask advanced configuration option. By default, this option isn't visible on the Configuration tab of SQL Server. You first must configure SQL Server to show the advanced options by right-clicking the SQL Server you are administering and clicking the Configure option. When you see Server Configuration/Options with four tabs across the top, click the Configuration tab and scroll down until you see Show Advanced Options. By default, this value is 0. Set this value to 1, and click Apply Now, OK.
Follow the same procedure to get back to the Configuration tab in the Server Configuration/Options screen. The first option will now be Affinity Mask. By default, this value is 0, which specifies that SQL Server will apply normal NT scheduling algorithms. SQL Server interprets any other value as a bit mask that specifies which processors are available for selection. For example, the value of 3, which has the binary equivalent 00000011, allows SQL Server threads on processors 0 and 1. (Bit 1 is processor 0, bit 2 is processor 1, and so on.) A value of 254, which is 11110000, allows SQL Server threads on processors 5, 6, 7, and 8.
The Affinity Mask option offers the best prospects for a performance increase on multiprocessor systems with more than four processors operating under heavy load. You can use NT's Performance Monitor to analyze each processor to determine the optimal settings for your environment.
Use NTFS for SQL Server. SQL Server spends most of its time reading from the SMS database rather than writing to it. Because SQL Server reads faster from an NTFS partition and writes faster to a FAT partition, you can increase performance by making sure that SQL Server is on an NTFS partition.
Take advantage of two SQL Server scripts. SMS spends much time writing to and reading from the SQL Server database. If you properly tune and maintain this database, you can ensure efficient performance and data integrity. You can use two SQL Server scripts, smsmaint.sql and chksms.sql, in Microsoft's BackOffice Resource Kit to tune and maintain the database. You will find these scripts in the sms\bins\i386 and sms\bins\alpha directories on the BackOffice Resource Kit CD-ROM. You can use ISQL/w to view and execute them. These scripts let you check database consistency, change database and SQL Server options, clean out old machine data from the database, and reduce index space.
TIP 3: Optimize Software Distribution
One of SMS's most powerful features is software distribution. You can optimize this feature by maximizing distribution performance over slow network links and tailoring package compression to meet your environment's needs.
Maximize distribution performance over slow network links. If you have users that always communicate through RAS, you can still take advantage of SMS to distribute standardized and automated software installations to them. You can use two methods, the first of which is to create a dummy SMS package and manually copy it to the distribution share. This method involves six steps:
- Create your installation source directory as usual.
- Copy it to a CD-ROM.
- Mail the CD-ROM to the remote user.
- Use SMS to send a dummy package with a small file as a placeholder.
- Copy the contents of the CD-ROM into the dummy package directory after you have distributed the dummy package.
- Execute the installation routine from Package Command Manager (PCM) on the remote client.
The second method is similar to the first, except that you use the CD-ROM to install the software. This method also involves six steps:
- Create your installation source directory as usual.
- Copy it to a CD-ROM.
- Mail the CD-ROM to the remote user.
- Create an SMS package that executes the installation routine from the CD-ROM.
- Distribute the SMS package to the remote sites.
- Execute the installation routine from PCM on the remote client.
Microsoft's Web site (http://www.microsoft.com/smsmgmt/support/out_of_band.asp) contains a white paper, "Distributing Software Over Slow Links," that discusses these two methods in detail.
Tailor package compression for your environment. When SMS distributes a package, it compresses the data before it sends the package. This compression process intensely uses the CPU. If your Site Server and distribution servers have adequate disk space, you can disable the compression process to speed up package distribution.
By default, the Enable Compression value in Registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Compression is set to yes. If you set this value to no, you will disable compression and increase your package distribution performance. However, you will also increase disk space requirements and, more important, increase network bandwidth utilization when SMS distributes these packages.
If you are more concerned about bandwidth usage than speed in your environment, you can increase the level of package compression. You can choose from seven levels of compression, 1 being the lowest level and 7 being the highest level. The default is level 1. To change the Compression Level value, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Compression. By increasing compression, you will use less network bandwidth and disk space on your servers. However, package distribution performance will decrease.
TIP 4: Delete Unused History Files
When SMS deletes machine records from its database, it does not delete the associated history files in the sms\site.srv\inventry.box\history directory. Because many SMS processes scan all the files in this directory, unused files can slow some SMS services. Unused files also waste disk space. Thus, to improve SMS's performance and increase disk space, you can determine whether the history files in this directory correspond to current inventory records.
SMS updates history files every time it updates an inventory record, so if a file is more than a few months old, SMS probably doesn't use it anymore. You can delete such unused files. Each file in this directory corresponds to a unique machine record and will have that machine's unique SMSID as its name. To be certain that the file is not unused, look for this SMSID in the inventory and, if you don't find it, delete the file. Be sure to stop the SMS services on the Site Server before removing the files.
TIP 5: Adjust Scheduled Inventories
When you set SMS's inventory frequency, you need to consider your hardware and software configurations. In most companies, a machine's hardware configuration is relatively stable. Setting SMS to conduct a hardware inventory every logon will yield few changes and, hence, little benefit. But you can benefit from periodic hardware inventories to account for hardware upgrades or replacements and IP address changes. Periodic hardware inventories can also help you prepare monthly reports. Having SMS conduct a hardware inventory every 11 days is a good starting point because that setting is longer than one week and shorter than two weeks. You can then make adjustments as necessary. For hardware inventories, you might want a shorter interval immediately before, during, and after a hardware or software upgrade project and a longer interval when you are between projects.
Software configurations change more frequently than hardware configurations. The rate of change depends on many factors, including type of business, type of users, and whether you lock down the desktop. A software inventory can add significant time to the logon process if you configure the inventory to search for many different packages. Once again, having SMS conduct a software inventory every 11 days is a good starting point. As with hardware inventories, you can adjust the software inventory frequency to accommodate your needs. You can find the hardware and software inventory settings on the Inventory page of the Site Properties dialog box, as Screen 1 shows.
In large sites, you must consider the combined effect of the hardware and software inventories on the network. For example, if you set both inventories to run every Monday morning, you will have a lot of inventory traffic slowing your network's performance. You can minimize negative effects by staggering the hardware and software inventories. For example, when you initially schedule the inventories, you can start the hardware inventory cycle on a Tuesday and start the software inventory cycle on a Thursday.
You can use the SKIPINV program in BORK, Part Two to determine when to take inventory. The SKIPINV program returns an error-level code that specifies one of three situations: you need to take hardware or software inventory, you don't need to take hardware or software inventory, or you have a problem with the sms.ini file.
When the SKIPINV results specify that you don't need to take inventory, you can improve user logon times by skipping any or all parts of the SMS client script (smsls.bat or runsms.bat). This script has two functions: installing and maintaining the SMS client--depending on the client operating system (OS), CLI_DOS, CLI_NT, or CLI_OS2 executes this function--and taking and reporting client inventory--depending on the client OS, either INVDOS, INVWIN32, or INVOS2 executes this function.
If you place skipinv.exe before the client configuration program, you can stop SMS from executing the entire SMS client script. Listing 3, page 150, shows an excerpt from an smsls.bat file modified to skip the script completely. If you bypass the entire file, the client upgrades required by an SMS service pack or upgrade will not occur.
If you place skipinv.exe between the configuration and inventory programs, SMS will run the script, except for the script's inventory program. Listing 4, page 150, shows an excerpt from an smsls.bat file modified to skip the inventory program. The highlighted lines in Listing 3, Listing 4, and Listing 5, page 151, are from the standard smsls.bat file. The other lines are from SKIPINV or CHECKRAS.
For maximum benefit, copy skipinv.exe to the client computer. You can use the logon script, send an SMS job, or modify the CL_x.MOD files (on new computers) to copy this program.
TIP 6: Detect RAS Clients
Different companies have different requirements for SMS and RAS. In many companies, users connect to the LAN most of the time, dialing in occasionally. If you have infrequent RAS users, the best solution is to bypass the SMS client script completely when they are dialing in.
How can you determine when users are connecting to the network with RAS so that you can bypass the SMS client script? You can use another BORK program, CHECKRAS, to determine whether the client is using RAS to communicate. The CHECKRAS program returns an error-level code of 1 if the client is using RAS and a code of 0 if not. If the client is using RAS, you can use checkras.exe to bypass the entire SMS client script. Listing 5 shows an excerpt from smsls.bat that uses checkras.exe to bypass the SMS client script when the client is using a RAS connection.
Some companies have users that often use Dial-Up Networking (DUN), so bypassing RAS might not be an option. Yet, limited bandwidth can make running the SMS client script painful for these users. If you have frequent RAS users, you can combine checkras.exe and skipinv.exe to skip parts of the script.
Occasionally, some companies custom install NT or Win95 without RAS components. If you choose this alternative, checkras.exe will return an error message, even though the error-level code will be set to the proper value (0). For this reason, you need to redirect CHECKRAS to NUL (CHECKRAS > NUL).
The CHECKRAS program isn't the only method you can use to detect DUN users. If you have configured your RAS server to provide an address from a dedicated IP address range, you can detect the client IP address and determine whether it is from the dial-up address range. Or you can run a batch file in the Startup group to create a marker file that you can detect in the logon script. For RAS users, the batch file creates the marker file before the logon script executes. For LAN users, the logon script executes before the batch file creates the marker file. (Be sure to delete the marker file in autoexec.bat.)
TIP 7: Optimize SMS Administrator
The SMS Administrator carries out SMS management, Help Desk, and other functions. Here are two ways to ensure that the SMS Administrator performs effectively and efficiently.
Give the SMS Administrator machines lots of RAM. The machines running SMS Administrator need a lot of memory. The SMS Administrator software requires 2MB of RAM. In addition, each machine record returned requires 726 bytes of RAM. So, for a site with 5000 inventoried computers, you need about 5.5MB of RAM.
By default, SMS Administrator queries the SQL Server database for all machines in the hierarchy. This query happens in the background, so you can perform other tasks while the query is running. SMS Administrator caches the returned information and uses it to populate the contents of the right pane of the Sites window.
If you refresh the data, SMS Administrator executes the query again. Both the original query and the refresh use the full 5.5MB of RAM. If you perform an ad hoc query while the original query or the refresh is running in the background, the memory requirement will double.
If SMS Administrator workstation memory is an issue, you can disable the Background Query in Sites option in Preferences under the Options menu. If you disable this option, SMS Administrator performs a foreground query for the machines in the domain selected. Because the query takes place in the foreground, you must wait for the query to complete before you can perform another task.
Place the SMS Administrator machines close to the SQL Server machine. From SMS's perspective, the SMS Administrator and various SMS services are the only SQL Server users. Most SMS Administrator tasks query SQL Server for information. Sometimes SQL Server returns a large amount of data across the network. Thus, to improve performance, you need to use fast connections between the SMS Administrator machines and the SQL Server machine and keep them as close together as possible to avoid flooding other segments of the network with this data.
Roll Up Your Sleeves
If you properly set up, maintain, and optimize the various SMS components, SMS can provide tremendous advantages in the battle to control total cost of ownership (TCO). By following these seven tips, you can make sure that your current installation performs effectively. So roll up your sleeves and start optimizing your SMS system.