Adding Value to SMS

Today, managers are asking systems administrators to provide greater security, superior client control, and enhanced Web reporting with fewer resources than ever before. By enhancing your Microsoft Systems Management Server (SMS) 2.0 infrastructure, you can extend those precious resources.

In mid-November 2002, Microsoft released the first two of several scheduled SMS 2.0 Feature Packs: the SMS Software Update Services (SUS) Feature Pack and the SMS Administration Feature Pack. Both feature packs contain SMS administration tools, but the Administration Feature Pack contains particularly beneficial administration tools that help you use SMS 2.0 in distributed, multi-site environments.

But before you dive into the Administration Feature Pack, you might want to take the time to revisit SMS's current feature set. To understand the benefits of the Administration Feature Pack's new Web reports, for example, you would do well to examine SMS's existing Web-reporting functionality. To get the most out of the other new features, you should know how to use Windows Management Instrumentation (WMI) on the SMS client to edit default SMS site files, which will help you gather additional hardware and software information and will provide additional reporting functionality. (For information about WMI, see "Extend Sms_def.mod by Using WMI Registry Providers" at http://www.microsoft.com/smserver/techinfo/administration/20/using/extenddefmof.asp.) You also need to know how to read information from the SMS client's Add/Remove Programs feature so that you can easily use the Windows registry for granular reporting. In the Administration Feature Pack, Microsoft has added a wealth of information to the SMS database, providing more capabilities and greater detail for customized SMS reports.

Setting Up a Test Site
For the purposes of this article, I use an SMS 2.0 test infrastructure to add Web reporting, edit SMS files, and install and use the Administration Feature Pack. The techniques I use work in deployments ranging from small to large SMS enterprises. The SMS configuration that Figure 1 shows demonstrates how information flows through the enterprise and includes a new repository server that stores security patches. AA1, the primary SMS site, manages all SMS information—site configuration, package deployment, and client reporting. Clients in the secondary SMS sites BB1 and BB2 receive information from the client access points and software from the SMS distribution points.

This configuration provides additional security because the download server acts as the security-patch repository and is behind a corporate firewall. If this server is built with robust hardware, you could later add the SUS Feature Pack to this server to further update SMS clients with standard security patches. The download server could also publish SMS Web reports for partner companies behind the security of the firewall.

Most systems administrators use Windows XP Workstation or Windows 2000 Workstation to manage SMS sites. The SMS test site that I use for this article simulates a production environment. The standard corporate build uses SMS 2.0 Service Pack 4 (SP4), and each server and client should be up-to-date with the necessary security patches. SMS test sites help you understand how to use the new tools, evaluate and identify possible conflicts, and produce a plan to migrate the tools into production after you're comfortable with their functionality.

Downloading the Feature Packs
You can download the SMS 2.0 Feature Packs from the Microsoft Web site at http://www.microsoft.com/smserver. You can install some of the tools to run from the workstation that contains the SMS Administration Console. (After you finish installing and testing the Feature Packs on all SMS administration workstations, I recommend that you install the SMS Administration Console extension on all your servers to maintain consistent configurations.) The Administration Feature Pack includes four sets of tools: the Transfer Site Settings tool, the Elevated-Rights Deployment tool, the Manage Site Accounts tool, and the SMS Web Reporting tool.

The Transfer Site Settings Tool
The Transfer Site Settings tool is installed by default on the primary SMS site server. You can also use the administration workstation's SMS Console to manually install the tool. The Transfer Site Settings tool contains the replstcfg.exe command-line utility, which lets you schedule times to copy SMS site settings or package and collection configurations into an XML file. Regular use of this tool lets you save SMS Site settings for your revision history or as part of your disaster-recovery process. To use the tool's GUI interface, start the Transfer Site Settings Wizard, select the Transfer Site Settings option, and ignore the option to migrate package and collection settings. The settings migration process lets you granularly select the settings you want to transfer from one site to another. The migration process can involve extensive detail, which helps ensure site-to-site consistency.

The Transfer Site Settings Wizard also lets you transfer all the collection and package settings or individual collection and package settings from one site to another. For example, an SMS administrator can create an SMS collection for the client group site BB1, then advertise (i.e., install the same programs on every client in that SMS collection) a necessary SMS package to this collection. He or she can then use the Transfer Site Settings Wizard to migrate the collection and package criteria to the primary site BB2. This process lets the SMS administrator determine which information (e.g., Preferred Sender, Refresh Schedule, Sending Priority, Disconnect Users) he or she wants to transfer from one secondary site to another secondary site. The site configurations will then be identical.

The Elevated-Rights Deployment Tool
The Administration Feature Pack requires that you install and run the Elevated Rights-Deployment tool from the primary SMS site. This tool helps SMS administrators deploy applications that require administrator rights on the local system. In many Windows networks, client machines are locked down because the average user doesn't need administrative privileges.

The Elevated-Rights Deployment tool lets you easily install application packages on XP, Win2K, and Windows NT. This tool uses encapsulation to distribute an SMS package for deployment. Using the Elevated Rights-Deployment tool to encapsulate a package is a two-step process.

First, to prepare the application, you use the executable with all the switches required for your deployment. For example, to install a security patch, the command line would look like

q300845_w2k_sp3_x86_en.exe -m -z

Second, using the Elevated Rights-Deployment tool, enter the network share for the package above to create a new installation file. This tool provides a new SMS package and advertisement for elevated-rights deployment to SMS clients. The Elevated Rights-Deployment tool creates a new SMS package that encapsulates the program with all the command-line switches. This new package, which can be advertised to SMS collections, should process like any other SMS package.

The Manage Site Accounts Tool
The Manage Site Accounts tool provides an easy method for managing all SMS site accounts across the SMS infrastructure. The SMS site account is a member of the Domain Administrators Group and, if compromised, could pose the highest level of a security risk. Many administrators have written scripting solutions to change the accounts that SMS uses. The Manage Site Accounts tool provides an easier management process to control accounts and passwords that SMS 2.0 requires in the hierarchy. If you're tired of making up secure passwords for the SMS service, you'll appreciate additional features such as command-line and scripting interfaces that let you create random passwords.

You can install this tool from any workstation that has SMS SP4 and any post-installation patches installed. The Manage Site Accounts tool installs the msac.exe command-line executable file, with which you can add, set, delete, and verify SMS accounts. You can create accounts and password updates for one site or multiple sites by using one command with switches.

The SMS Web Reporting Tool
The SMS Web Reporting tool has been available for more than a year and comes in both feature packs. You can install the tool from the primary SMS servers or other SMS support servers such as a Microsoft IIS server. Incidentally, if you have a Microsoft Premier Online Support account, you might have received the feature packs while they were in beta. If so, you might need to back up the SMS SQL Server database before installing the released versions of the SMS Web Reporting tools.

As Figure 1 shows, the SMS Web Reporting server for site AA1 is simply a Web server running Internet Information Services (IIS) 5.0; the latest security patches have been applied, and the server is running an earlier installation of the SMS Web Reporting tool that needs to be updated. Let's run through the process of using the new SMS Web Reporting installation wizard to update this site and verify the installation.

The SMS Web Reporting Tool
The SMS Web Reporting tool has been available for more than a year and comes in both feature packs. You can install the tool from the primary SMS servers or other SMS support servers such as a Microsoft IIS server. Incidentally, if you have a Microsoft Premier Online Support account, you might have received the feature packs while they were in beta. If so, you might need to back up the SMS SQL Server database before installing the released versions of the SMS Web Reporting tools.

As Figure 1 shows, the SMS Web Reporting server for site AA1 is simply a Web server running Internet Information Services (IIS) 5.0; the latest security patches have been applied, and the server is running an earlier installation of the SMS Web Reporting tool that needs to be updated. Let's run through the process of using the new SMS Web Reporting installation wizard to update this site and verify the installation.

First, install the SMS Additional Web Reports from the SMS SUS Feature Pack (the Administration Feature Pack doesn't contain the Additional Web Reports). After you update the site, you'll be able to edit the SMS site files to create custom Web reports and to report detailed SMS client information by using the new Web Reports. When you edit the sms_def.mof file, remember that this process adds new information to the Microsoft SQL Server database that you can query through the SMS Administration Console or the SMS Web Reporting tool.

In my example, the SMS Web Reporting tool is installed from the Win2K SMS Web server, DENWEB01. The SMS SUS Feature Pack is expanded on the local hard disk, so I double-clicked the smswebreporting_enu.exe file, then followed the installation wizard prompts to enter the name of the Win2K server on which the SMS database is maintained and the SMS database name.

Depending on the SMS architecture hardware, your SQL Server database might be on the same server as the SMS primary site. However, in some larger enterprises, the SQL Server database might be on a separate cluster server, with the hardware and SQL Server program managed by a database administrators group. When we installed the SMS configuration that Figure 1 shows, we chose a custom installation, installed additional SMS components, and configured the database on the primary site DENSMS01 with the name SMS_AA1. This process created a secure method to read the SMS data by creating a new account, SMS_Web_Read, and provided read-only access to the new account. The SMS reporting process uses this account to provide access from the IIS server to the SQL Server database.

In addition to this account, the SMS Web Reporting tool installs SQL Views that the SMS IIS Web-reporting server uses. The system creates the SQL Views from default SMS SQL Server database tables. These default views provide examples of how to customize Web reports to provide added value specific to your company's needs.

Increased Hardware and Software Inventory
Now let's look at how you can extend SMS 2.0's functionality by reading the SMS client registry information. You can increase the functionality of SMS's hardware and software inventory by editing some of your primary site files. Let's consider two examples of reading registry keys and reporting that information to the SMS site database: the Add/Remove Programs information and Custom Registry Key Software Update information.

Windows provides a Control Panel Add/Remove Programs applet that corresponds directly with a registry key that reports on information that's present during the installation of a software program, security patch, service pack, or any off-the-shelf Windows program. Inhouse programs written specifically for Windows should follow the same rules of writing to the registry during the program's installation steps. Updating the registry with inhouse .exe files lets SMS report the installation on a client-by-client basis.

Before you start the process to extend the SMS default inventory process, it might be helpful to consider some background information about hardware inventories. SMS clients report data to their respective site servers. In turn, the site servers forward that information to the primary site that contains the SQL Server database. The SMS site settings for each site in the SMS hierarchy are managed in the SQL Server database with all the SMS client data or client objects. All SMS client objects in the SQL Server database are recorded into the database as part of the SMS hardware inventory process. The collected data is referred to as managed objects or manageable objects. (You can review the objects using simple SQL queries through the SMS Administration Console or create new SQL Views similar to those that the SMS Web Reporting tool uses.) You can use SMS to manage approximately 600 hardware objects; only about 200 objects are configured and inventoried by default. If the other 400 objects that aren't enabled can't inventory the specific information you need, you'll need to extend the reach of SMS on your client systems. Let's see how to increase the SMS hardware and software from client systems.

Adding objects to the default Managed Object Format (MOF) can extend the SMS hardware inventory. When you install SMS on the workstation or server, the sms_def.mof file is copied from the SMS site server in the \siteserversitesharesmsinboxescliefiles.srchinv directory to the client system. Microsoft provides a separate program called the MOF Manager program, mofman.exe, to edit the sms_def.mof file. (This file is on the SMS 2.0 CD-ROM in the supportreskitbinx86 directory.) However, experienced SMS engineers might want to use Notepad to edit the MOF file. A good practice is to make a backup of the sms_def.mof file during testing and use GUI 2.0.21 (which you'll find on the SMS 2.0 CD-ROM) to check for syntax errors during compilation.

Listing 1 shows the changes needed to report the Add/Remove Programs installed on the SMS client system and to report this information to the SMS site server database. Simply copy the listing into your test SMS site MOF file. This addition is then updated to the SMS Client, and each client reports the Add/Remove Programs registry information to the SMS site server. You can add this script to the sms_def.mof file for testing. (The script includes spaces for clarity; they aren't necessary for compilation.)

The Custom Registry Key Software Update information is added to the client system during the installation of SMS scripts because we edited the .mof file. The SMS installer program lets you encapsulate an executable into an SMS script. You can choose the option to install the SMS Installer program during a custom installation of the SMS 2.0 software. The SMS Installer can repackage a program after it's installed so that the system can advertise it to an SMS collection.

My company's SMS test lab has client systems that represent our current production client configuration. This configuration is known as our standard build, and the company maintains a build version number (e.g., 2.00.2). The SMS installer program runs on one of these client systems; it takes a snapshot of the configuration, and the SMS installer pauses. During this paused state, we install a new application (e.g., Visio) on our client system. At the end of that installation, we let the SMS installer program complete its processes by creating a file that has identified all the changes made to the client system after we installed the application. The resulting file is in a format that we can push to SMS clients and provides more detailed information about the software installed on each SMS client. The SMS installer program lets you add lines of software code or a script to the file. To help identify custom applications or standard client build information, we add a small amount of information to the client registry for each SMS script we install. We then test this new installation program on client computers for interoperability, and after it passes all our criteria checks, we can add it to the SMS packages that we might push to a collection of client systems. We also increase the company's standard build version number (e.g., 2.00.3) and record the changes we made to our production systems.

Reporting Client Registry Information
We've followed all the steps to update the registry for every SMS package that we pushed to our client computers. Wouldn't it make sense to edit the sms_def.mof one more time so that SMS can report on this data? This process is similar to the process of editing the managed object file to report on the Add/Remove Programs data. Listing 2 shows the changes needed to report on the installed SMS packages. You can add the script to the sms_def.mof file in your lab for testing.

By default, the system will report sms_def.mof file changes to the SMS database during the next hardware inventory cycle in 7 days or during the next client reboot. In the meantime, you can open the SMS Administration Console to create an SMS query that reports the changes to the database. Listing 3 shows a sample SMS query that counts all the programs listed in the Add/Remove Program tables in the SQL Server database. The query that Listing 3 shows is for my company's operations; specific registry data is similar.

Powerful Tools
SMS 2.0 is a scalable platform that can help you manage your Windows infrastructure. Using the new tools that are freely available in the program's Administration Feature Pack, SMS administrators can increase efficiency, identify security vulnerabilities, distribute client updates, and improve corporate network-reporting capabilities. Whether you're a senior SMS administrator who wants to more easily use and enhance your SMS infrastructure or a technical manager who's reviewing SMS features for deployment in a corporate enterprise, you're going to want these tools in your SMS infrastructure.