As the typical harried and over-stressed network administrator, how can you make Microsoft Systems Management Server (SMS) collect the information you need? This article is the first in a series that covers procedures for using SMS to inventory desktop systems. Part 1 focuses on how to collect the information. Part 2 will illustrate how to develop reports using data in the SMS database. Part 3 will examine how to extend the SMS database and third-party add-on products, such as Digital Equipment's Assetworks.

To see how to use SMS in a typical environment, let's examine four levels of inventory needs. For example, with Microsoft Word, these four levels tell you

  • who has winword.exe
  • who has Word
  • who has a working version of Word
  • who has no version of Word

These four points present an increasingly complex set of problems to a network administrator. Handling the last two situations requires taking SMS beyond the basics.

Who Has Winword.exe
If you have installed SMS properly, it automatically inventories the hardware and operating-system software on your network. The first software inventory level concerns finding out which desktop systems have a given file, such as winword.exe. The SMS Administrator's Guide covers this level. You create a package, and SMS tells you who has it. For example, to find out who has winword.exe, you create a package by selecting New from the File menu in the Packages window, to get the display on screen 1.

Once you specify the properties of the file you want inventoried, SMS goes to work. The process is straightforward: The SMS_Executive service includes a process called the Applications Manager, which monitors the SQL database for new or changed packages and locates a transaction requesting an inventory of win-word.exe: PACKAGE1"InventoryWINWORD.EXE" FILE"WINWORD.EXE"DATE10/09/94. The Applications Manager updates the file package.rul, which contains all the software scanning rules for the site, in the \site.srv\maincfg.box\pkgrule directory.

Another portion of the SMS_Executive service, the Maintenance Manager, creates the real rule file, pkg_16.cfg, and copies it to the logon servers at the site. When a client logs on to the domain, the logon script initiates the appropriate inventory agent process on the desktop. This local process searches the local drives based on the rules in pkg_16.cfg and saves the results in a file with a .raw or .mif extension on the logon server. The Maintenance Manager moves these results back to the site server; then the Inventory Processor and Inventory Data Loader upload them from the site server to the SQL database. At this point, you can see the inventory results by reviewing the Personal Computer Properties of a system in the Sites window, shown on screen 2.

This procedure is fine if you just want to view the information on a computer-by-computer basis. Ordinarily, however, you want a list of all the systems that have a given file. To generate this list, you create a query. The SMS Administrator's Guide describes this process, which Part 2 of this series will discuss at length.

Who Has Word
More often than not, you won't care whether a desktop system has a file of a given name or date; you're more likely to be interested in a certain software package. Which files are in that package doesn't matter. SMS lets you create a special type of package into which you can import a set of definitions that software vendors have created to aid in the inventory process. This process is software auditing.

To set up an inventory for a specific software package, you manually create a rule file similar to package.rul. Microsoft provides a list of more than 2800 commercial applications in the file \sms\primsite.srv\audit\audit.rul. You can edit or append rules to this list.

Let me give you an example of software auditing: Suppose you want to find out who has any version of Microsoft Word. Believe it or not, there are more than 105 different releases of Word, including all the different language versions, but not including the Office, Professional Office, or Office 95 releases. Setting up inventory packages for all these releases would be a nightmare, so you decide to try auditing instead. Your first step is to edit audit.rul to include only the information for Word and save it as a temporary file, as screen 3 shows.

To get the 105 releases of Microsoft Word, I edited the version of audit.rul that comes with SMS 1.1 and saved it as word.rul. Then, I ran the program rul2cfg.bat, also in \sms\primsite.srv\audit, to turn this file into audit.cfg. (No matter what you call your temporary file, the output file is always audit.cfg, which corresponds to pkg_16.cfg.)

To conduct the software inventory, you also need to create a regular SMS package and job: You import audit.pdf for the package definition and create a Run Command on Workstation job, which forces clients to run audit16.exe or audit32.exe on the desktop. The resulting .mif file is brought back to the site server from the logon server, and the data is loaded into the SQL database. This time, however, you don't see the data in the Packages section of the Personal Computer Properties; you see the Audited Software group, as on screen 4.

The difference between using a package to take a basic inventory and using an audit to take a more advanced inventory is simply: Do you want to use a graphical tool to create the .rul and .cfg files, or will you put up with some extra ASCII editor steps to avoid having to learn filenames, dates, and sizes?

Sometimes network administrators want to know everything that's out there on the desktop, without having to specify in advance what to look for. For example, what software do your users have on their local drives that the software police might care about? Who has downloaded .gif and .jpg files from the Internet?

To find out, you can use a combination of standard SMS features and two basic strategies. The first, and probably simpler, strategy is to create an audit package with one rule. The wildcard syntax

package 1 "All .exe files"

file "*.exe"

creates an audit package that shows all the executable files on the desktop (or *.gif for all the .gifs, and so on). You can view this package using the system's Personal Computer Properties in the Sites window, as shown on screen 5. (Note that the wildcard in the audit rule is a *, whereas in a query, the wildcard is a %. I have been unable to get inventory package definitions to use any wildcard at all.)

The second strategy is to create, distribute, and run this batch file:

C:

CD \

DIR *.EXE /S /B > C:\INVLIST.TXT

If you save this batch file as inv_get.bat, you can create a package and a Run Command on Workstation job and schedule it to run when a user logs on to his or her workstation, as you see on screen 6. This job results in a file with data in the format you can see on screen 7. Then, you create an inventory package to collect this file so you can analyze it locally at the site server.

Who Has a Working Version of Word
Taking a basic inventory or audit is useful, but you're still leaving a major question unanswered: Does that version of the program (in this case, Word) work? You can determine the answer by using the Remote Troubleshooting utilities. However, having a general strategy to test configurations and to collect and analyze the test results with SMS is useful.

To learn whether Word is installed correctly, you need to use it, not just look at the disk and see that it's there. The strategy you need to follow is relatively simple, although the details are sometimes elusive.

  • Create a test program that identifies whether Word loads correctly and that writes the result to a text file.
  • Create a package and a job to distribute and run your test program on the desktop system.
  • Create an inventory job to collect the results file.

To demonstrate this strategy, let's try to figure out whether TCP/IP is loaded and correctly bound on a desktop system. The program in listing 1 determines whether TCP/IP works. (The code is based on messages on the Internet at comp.os.ms-windows.networking.tcp-ip.) This program writes a flag to the disk to signal the function's return condition:

Open "C:\TCPIP.TXT" For Output As #1

Print #1, CheckWinsock()

Close #1

To see whether TCP/IP loads correctly, you compile this program, distribute it as a mandatory job, and create a package that will inventory and collect the results file, c:\tcpip.txt. Once the results files from the desktop systems are on the site server, you can look at them individually or write a program to parse them and produce a summary report.

To do the same for Word, or any application program, is no more difficult in principle. However, the process requires knowing how the application works and some programming expertise. For example, you can write a program that loads Word and tests whether it can retrieve a handle for Word or whether you can run a Word macro. (You can flesh out the pseudocode in listing 2. It writes a text file to the local C drive, from which SMS can inventory, collect, and analyze data.)

Who Has No Version of Word
In some cases, you need to know who does not have a copy of a specific file such as Word. If you know the answer,

you can create a job to install the full package on those workstations, but ignore other desktop systems that do not need it.

Discovering who has any version of Word and who's in the database is easy. So listing all the systems that do not have Word should be simple. But it isn't. SMS doesn't have a NOT operator for its queries, as you see on screen 8 . You can AddAND, and you can AddOR, but you can't AddNOT.

You might be tempted to create a query of the following form:

MICROSOFT|SOFTWARE|1.0:Software Name is not like '%Word%''

However, this query would retrieve all the computers in your database, not just those that don't have Word. All systems have at least one file that isnotlike %Word%. However, you could audit for Word and then write a small test program to query the database directly. Part 2 of this series will deal with this and similar issues.

SMS, Part 2
The next article will show you how to query the SMS database with the SMS query tool and with external tools, such as Microsoft Access and Visual Basic. You will also learn how to write reports that summarize the data these queries produce.

REFERENCES
The SMS Administrator's Guide and the Microsoft Exchange Server course, Administering Microsoft Systems Management Server, contain a variety of procedures for administering SMS inventories.

Microsoft
206-882-8080
Email: info@microsoft.com
Web: http://www.microsoft.com