There are a number of tools on the market for the automation of asset management. Most are costly in terms of purchase price and all are expensive to get running. When you begin to investigate the solution to your own corporate asset management needs there are other items you discover almost from the start:

• The solution is either polling based or it's client based
• A database is involved, thus
• A special query tool is required
• Reporting solutions integrated with the query tool are complex, unreliable and just plain confusing
• Agent based tools give a decent snapshot of the enterprise after a week or so
• Polling tools take a week to even finish the job

This is an intolerable situation! What if you could not have to struggle through an installation and could approach the reporting problem from a different angle without any cumbersome databases or reporting tools? What if you could write 'queries' based on simple disk utilities native to Windows?

This is a 4 part series on just such a tool I've built to simplify life, keep costs down and, generally, avoid having to learn another vendor specific tool. Call me conceited (I heard that!!), but I'm fairly certain this tool has a low learning curve and will produce results you're able to work with quickly and efficiently. The results will be available from any of your systems at any time AND you'll be done faster than you can imagine. In my own tests, a nationwide network of about 3000 hosts took between 3 and 5 business days to poll and tabulate. The end reports, when passed on to managers tasked with making decisions based on the data, almost always caused me to spend even more time answering even more questions!! Damn!! That's not what I wanted at all!

In the same corporate network and using the tools in this article, all systems present at the time of the scan had been polled and the data tabulated in less than 3 hours! Reporting was a simple task of looking at the granular results and importing to whatever tool the managers wanted to work with. Usually, they wanted to work with Excel and they absolutely hate having to spend time interpreting the results. I can't blame them.

And get this: I received a request from a manager who wanted to send her technicians to only a small set of machines armed with the knowledge that those machines were running a piece of software forbidden by corporate policy. She didn't have to think too long, because this tool set had already refined the data. All I needed to know was the name of the offending application, pass it to her and her technicians then had a current (within 4 hours) list of hosts to attack!

So, are you interested yet?

There are two things I really ought to tell you before going any farther. If you've imagination, neither should bother you. But you wouldn't believe the number of other people who have complained during testing, because the tools create text output, have no GUI and require that they spend a couple short minutes applying their own formatting within their own favorite word processor or spreadsheet.

If you're one of these, I've a short, not so polite message for you. Surely it's not too much to ask you to learn something on your own, right? And you're all familiar with the need for portable data, right? What's more portable than text? Finally, a GUI can be nice when there are lots of things to remember. There simply isn't much to remember in order to produce results with this collection so don't even ask!

Those of you who do prize form over function (egads), you are welcome to use these tools as your starting point if you just have to have that GUI. I only ask that you remember where you got your start and give credit appropriately. It bothers me to no end that one of the pieces of this tool set is so prevalent on the Internet without the original author's details that it's impossible for me to identify and thank them.

And for the others who want to spoil the fun by writing the results to a database, well, your demands are more reasonable. You are also welcome to start with these tools and figure out the database details for yourselves.

In fact, Dian has already published the details of how you might start pushing the data to an Access database using ADO. The article specifically discusses data from a Word form to/from Access, but the VBA/ADO code download shows you how to make that basic connection. See the article Please Fill Out This Form, Part 5 at the link HERE.

So here's how to get started -

1. Log in to your system using an account with administrative privileges across your domain
2. Download the package from http://www.mousetrax.com/pub/domainreport.zip
3. Save the file to a directory on your system
4. Unzip the file
5. Open a CMD prompt (Yes, I recommend you run these tools from Windows 2000 or higher workstations or servers)
6. Navigate to the folder containing DomainReportManager.vbs
7. Set the default script processor to cscript.exe, turn off the WSH logo and save these settings by issuing the following command at the CMD prompt:
8. Cscript //H:cscript //NoLogo //S
9. Type DomainReportManager.vbs

DomainReportManager will now browse the NetBIOS namespaces and return the names of all the workgroups and domains it can find on your local network. When it has gathered these names, simply type the name of the domain you want to inventory, press enter and wait.

Special or Interesting Things to Know

Oh, there are a few tricky things done in these scripts. Some are the result of limitations to WSH scripting. Some just plain cool. All can be improved upon, I'm sure. The entire process is aimed at going as fast as we can without blowing up the host system. To accomplish this, DomainReportManager.vbs attempts to track all the running instances of script on the survey system. By default, up to 150 clients may be surveyed at any one time. This is the primary way in which the system's speed is attained.

But doing all this parallel processing causes another problem; how do we know the job is done and it's time to parse the results out into the refined data? Since DomainReportManager.vbs is already throttling the processing load to 150 client queries, it merely watches the number of cscript instances in memory until the number of instances is the same as the number that existed when it started working.

As with all my scripts, logging is done and the depth of logging is controllable. Be careful to leave Debug=1 unless you're chasing a problem. Taking the Debug level to 4 leads to extended processing time and huge logs.

That's all I'm going to say about the tools for now. However, if you're still not convinced to try them, here's the Readme file for the package. It should answer the more basic questions you might have as you start to understand the depth of the information the tools present and all the options you can use to control the tool.

README

----------------------------------------------------------------------

MouseTrax Windows Net Tools, Readme.txt

Copyright 2002 MouseTrax Computing Solutions

http://www.mousetrax.com

Author: Greg Chapman

----------------------------------------------------------------------

Table of Contents

1.0 Introduction

2.0 Client Requirements

3.0 Scanning System Requirements

4.0 Getting Started/Quick Start

5.0 Using the results

----------------------------------------------------------------------

1.0 Introduction

These tools are designed to leverage the installed tools resulting from Microsoft's development of Active Directory Services Interfaces, its released tools for Windows systems under the guidance of the Desktop Management Task Force (Windows Management Instrumentation) and its finest element for Windows, the Windows Script Host.

Ever take a job with an undocumented Windows network? No idea what applications are installed on what machines? What about Service Pack installations? How about no asset control documentation?

Well, I have and it's damned painful. Even manual visits to each workstation tend to produce data that is stale by the time you visit the last machine. At the end of a day, a month or a couple years, you're still not sure exactly what's out there in the field that someone may tell you you're responsible for! It's even worse when a software vendor visits your network with a demand to audit your software assets. You just know your raise and those of several others will be spent to true up those overlooked licenses.

While this collection of tools doesn't completely document a Windows Domain, it's customizable with a little imagination and knowledge of VBScript. After running these processes, you'll have a directory structure that:

• Inventories all systems to which you have administrative access
• Harvests Hardware Vendor name, model number and serial numbers
• All versions of Windows NT (i.e., 2000, XP and 2003) installed on the network, broken down by Service Pack
• Complete inventory of all installed software and the systems upon which it's installed
• Complete inventory of all running processes and services and the systems upon which they are running
• List of all systems not available for inventory
• List of all computers posing as members of the domain
• List of all systems in the domain and their roles within that structure
• Better feeling at night that you actually may know what you think you know

At long last, you'll be able to find every single last instance of Kazaa! installed on your network's systems.

----------------------------------------------------------------------

2.0 Client Requirements

Windows Management Instrumentation 1.5 (system default) winmgmts service running (system default) Default DCOM configuration (system default) Administrative privileges on that system

Note that only Windows NT 4 systems may need to have the WMI Core 1.5 package installed. Windows 2000, XP and 2003 already have it installed.

----------------------------------------------------------------------

3.0 Scanning System Requirements

Windows Management Instrumentation 1.5 (system default) winmgmts service running (system default) Default DCOM configuration (system default) Administrative privileges on that system Windows Script Host enabled (system default) FileSystemObject installed and enabled (system default).

Note that only Windows NT 4 systems may need to have the WMI Core 1.5 package installed. Windows 2000, XP and 2003 already have it installed.

----------------------------------------------------------------------

4.0 Getting Started/Quick Start

It's much simpler than you may think. First, it's best to set up the Windows Script Host environment on the scanning system. The key element is to make cscript.exe the default script processor (wscript.exe is the installed default). This can be accomplished by opening a command console (CMD.EXE) and issuing this command string followed by pressing Enter:

cscript //H:cscript //NOLOGO //S

Once that is complete, you have four options for getting started. Navigate to the folder containing DomainReportManager.vbs. Type: DomainReportManager.vbs OR DomainReportManager.vbs <domain/workgroup name>

Starting the DomainReportManager.vbs script without an domain or workgroup name specified as an argument will cause the script to enumerate the domain namespace and return the names of all domains and workgroups that it identifies. It will then wait for you to type in the name of the domain you'd like to survey.

DomainReportManager will also allow you to specify a list of hosts to check. Using the '/List:' option, specify a path and filename of hosts. You may make comments in these lists by making the first character of the line a semi-colon (;).

Example 1 - Scanning a Domain

cscript <drive>:\<path>\DomainReportManager.vbs MyDomainNameHere

Example 2 - Enumerating all domains

cscript <drive>:\<path>\DomainReportManager.vbs

Example 3 - Referencing a host list

cscript <drive>:\<path>\DomainReportManager.vbs /List:"<drive>:\<path>\MyList.txt"

Note: surrounding the path/filename of the list in double quotes is required if the path or list name does not comply with 8.3 file naming conventions.

----------------------------------------------------------------------

5.0 Using the Results

When the DomainReportManager has finished it will wait for all outstanding machine surveys to terminate (this can take a while on some networks). At this point, you may either terminate the script by pressing Ctrl-C or simply wait for the script to start the HardwareReportCompiler.vbs script.

At the end of this phase, you should see the following directory structure:

%lt;script-dir>
            \DomainName
	               \DateStamp
                                 \Systems By NetBIOS Name

The HardwareReportCompiler has an unenviable job. It is fed the directory to which all the computer inventories are archived. Each inventory file is then examined and parsed out to result in the following example directory structure rooted at the \DateStamp level of the previously mentioned path:

\Installed Software
\Operating Systems
                  \Windows XP
		             \Service Packs
			                   \1
					     \Installed Software
					     \Services
					     \Tasks
				          
\Systems By NetBIOS Name
                        \Vendors
	                        \VendorName
\Services
\Tasks

Update! Don't miss Hard and Soft Asset Management – Part 2