SMS: Inventory Your Desktop Systems, Part 1

As the typical harried and over-stressed network administrator, how can youmake Microsoft Systems Management Server (SMS) collect the information you need?This article is the first in a series that covers procedures for using SMS toinventory 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-onproducts, such as Digital Equipment's Assetworks.

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

These four points present an increasingly complex set of problems to anetwork administrator. Handling the last two situations requires taking SMSbeyond the basics.

Who Has Winword.exe
If you have installed SMS properly, it automatically inventories thehardware and operating-system software on your network. The first softwareinventory 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 whohas winword.exe, you create a package by selecting New from the File menu in thePackages window, to get the display on screen 1.

Once you specify the properties of the file you want inventoried, SMS goesto work. The process is straightforward: The SMS_Executive service includes aprocess called the Applications Manager, which monitors the SQL database for newor changed packages and locates a transaction requesting an inventory ofwin-word.exe: PACKAGE1"InventoryWINWORD.EXE" FILE"WINWORD.EXE"DATE10/09/94.The Applications Manager updates the file package.rul, which contains all thesoftware scanning rules for the site, in the site.srvmaincfg.boxpkgruledirectory.

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 atthe site. When a client logs on to the domain, the logon script initiates theappropriate inventory agent process on the desktop. This local process searchesthe local drives based on the rules in pkg_16.cfg and saves the results in afile with a .raw or .mif extension on the logon server. The Maintenance Managermoves these results back to the site server; then the Inventory Processor andInventory Data Loader upload them from the site server to the SQL database. Atthis point, you can see the inventory results by reviewing the Personal ComputerProperties of a system in the Sites window, shown on screen 2.

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

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

To set up an inventory for a specific software package, you manually createa rule file similar to package.rul. Microsoft provides a list of more than 2800commercial applications in the file smsprimsite.srvauditaudit.rul. You canedit or append rules to this list.

Let me give you an example of software auditing: Suppose you want to findout who has any version of Microsoft Word. Believe it or not, there are morethan 105 different releases of Word, including all the different languageversions, but not including the Office, Professional Office, or Office 95releases. Setting up inventory packages for all these releases would be anightmare, so you decide to try auditing instead. Your first step is to editaudit.rul to include only the information for Word and save it as a temporaryfile, as screen 3 shows.

To get the 105 releases of Microsoft Word, I edited the version ofaudit.rul that comes with SMS 1.1 and saved it as word.rul. Then, I ran theprogram rul2cfg.bat, also in smsprimsite.srvaudit, to turn this file intoaudit.cfg. (No matter what you call your temporary file, the output file isalways audit.cfg, which corresponds to pkg_16.cfg.)

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

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

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

To find out, you can use a combination of standard SMS features and twobasic strategies. The first, and probably simpler, strategy is to create anaudit 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 thesystem'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, thewildcard is a %. I have been unable to get inventory package definitions to useany 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 aRun Command on Workstation job and schedule it to run when a user logs on to hisor her workstation, as you see on screen 6. This job results in a file with datain the format you can see on screen 7. Then, you create an inventory package tocollect 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 amajor question unanswered: Does that version of the program (in this case, Word)work? You can determine the answer by using the Remote Troubleshootingutilities. However, having a general strategy to test configurations and tocollect and analyze the test results with SMS is useful.

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

To demonstrate this strategy, let's try to figure out whether TCP/IP isloaded and correctly bound on a desktop system. The program in listing 1determines whether TCP/IP works. (The code is based on messages on the Internetat comp.os.ms-windows.networking.tcp-ip.) This program writes a flag to the diskto 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, distributeit as a mandatory job, and create a package that will inventory and collect theresults file, c:tcpip.txt. Once the results files from the desktop systems areon the site server, you can look at them individually or write a program toparse them and produce a summary report.

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

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

you can create a job to install the full package on those workstations, butignore 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. Butit isn't. SMS doesn't have a NOT operator for its queries, as you see on screen8. 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, notjust those that don't have Word. All systems have at least one file thatisnotlike %Word%. However, you could audit for Word and then write a small testprogram to query the database directly. Part 2 of this series will deal withthis and similar issues.

SMS, Part 2
The next article will show you how to query the SMS database with the SMSquery 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 queriesproduce.

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