Network Mining
Think about how much there is to know about a single networked Windows NT system. On the surface, there are a lot of configuration settings, for the operating system and for each of dozens of application packages. Under the hood, NT's behavior is controlled by hundreds of registry variables. In addition, over time, NT can log thousands of system, application, and security events. Turn on disk and performance monitoring, and the number of data points a single NT machine produces can climb into the hundreds of thousands -- and from just one system.
Facing this daily avalanche of NT data, a network manager can ignore it and run for cover, or accept it and try to manage it. If you choose the latter, you can get help from Microsoft's System Management Server (SMS), or from third-party products such as Mission Critical's OnePoint Operations Manager. But products like these are only the first step.
You'll find a relational database behind most network and systems management products, and your millions of NT datapoints will accumulate over time into these database mountains. Before you set out to mine useful information out of those mountains, keep one of our industry's oldest principles in mind: garbage in, garbage out.
On the input side, take some time to configure your products to collect the information you'll need, as often as you think you'll need it. When setting up SMS inventory collection, for example, you might want to add .DLL, .COM, .LOG, and .BAT files to the default .EXE files that the SMS inventory agent catalogs. You can probably reduce the frequency of scanning things that don't change very often, such as a system's hardware inventory. But you might want to check things that do change -- like software -- more often than the default. Of course, you'll be trading processing and network overhead for collecting more data, but the management value of the information you gather can greatly outweigh the lost cycles and bandwidth.
Did I mention software agents? Because high-end system management products usually require you to install agent software on your managed systems, many network managers are reluctant to use them with production servers. Overcome this fear and install the agents anyway. Someday, when you ask the database a question about your servers, the answers will more than justify the effort you put into getting those agents up and running.
That gets us to the output side of your network data mining problem. It may be hard to overestimate the potential value of a comprehensive database for your networked NT systems, but its easy to underestimate the effort involved in realizing this potential. You'll probably find your management product comes with several canned queries you can use to get a list of, say, all NT workstations with Service Pack 6. The real power of the product's database can only be unlocked by someone who knows SQL. You'll find even simple queries that cross two or more kinds of information -- such as finding all the machines in your SMS database that are being used by people in your finance user group -- can exceed the capabilities of your product's standard retrieval features.
What's that you say? The vendor said its management product would do all this for you? They lied. Take some time to think about what you want from the product, then configure it properly to collect the necessary raw data. On the back end, take more time to get to know SQL. Or, ask one of the database-savvy IT people in your IT organization's development group to help out. There's gold in your management products, but you'll have to do a little digging to get it out. --Al Cini is a senior consultant with Computer Methods Corp. (Marlton, N.J.) specializing in systems and network integration. Contact him at al.cini@computermethods.com.