In-Depth

The Three Components of Network Management

Before you use MOM, brush up on the basics of enterprise systems monitoring.

• By Bill Heldman
• December 01, 2001

Managing enterprises comes down to the need for three different components: metrics, monitoring and systems management.

Metrics
Metrics let you monitor a computer's total uptime for some period of time and then be able to report on that uptime. It's important to note that uptime doesn't necessarily revolve around a computer being up. If an application service (daemon or NLM) isn't running, then for all intents and purposes that server is down. In other words, if you have an Exchange Server box and the Exchange Mail Transfer Agent (MTA) service is down, your server is essentially in an outage state.

Uptime is measured in nines. We strive for five nines, meaning we'd like to see 99.99999 percent uptime over a given period (including maintenance windows). The nines on the right side of the decimal are of interest to us. Five nines are practically impossible because that kind of uptime amounts to less than a minute a year of downtime. Three nines, which a lot of server companies tout in their advertising these days, are only a tiny bit more realistic at roughly five minutes per year. Most networks I've seen run at "human temperature" uptime-98.6 percent or thereabouts (about 10 hours a month of downtime).

If you're serious about metrics, check into NetIQ or MOM. If you have a variety of disparate systems such as Unix, NetWare, Linux and what have you, you may need to investigate a more robust methodology that can talk to different platforms. Software such as HP Openview, CA Unicenter or IBM's Tivoli might be in order, especially if you're interested in serious bandwidth monitoring and shaping and protocol analysis-and you have the budget and staffing to support one of those solutions.

Monitoring
Enterprise monitoring (also known as operations management) allows administrators to receive alerts when a system, computer, peripheral or other monitored device goes "toes up." It also allows for bandwidth measurement, protocol analysis and network sniffing.

There's potential for a disconnect between server administrators and network folks (the people who put up the infrastructures and manage the routers and switches) when it comes to enterprise monitoring. I call the switch and router experts "internetworkers" because they're involved not with the Internet, but with the networking in buildings and between buildings. The average internetworker sniffs at a server administrator and wonders why that person wants monitoring statistics anyway. After all, it's the job of the internetworker to monitor the network, isn't it? But you have to overlook that and get around it somehow.

Your goal with enterprise monitoring is that of alerting, early detection, and problem eradication. I've seen systems that call the admin: "Print spooler XYZ00001 has gone down. Press 1 to attempt restart." Admin presses 1. "Spooler XYZ00001 has successfully restarted. Have a nice day." Would that your system worked that way.

Systems Management
Systems management, in essence, allows for three fundamental operations:

• The automatic regular collection of hardware and software asset inventory.
• The ability to deliver software automatically to designated groups of computers.
• The ability to remotely control a PC or remotely obtain diagnostic information from a PC

Microsoft's Systems Management Server (SMS) 2.0 handles all three of these operations—and a bit more. It also handles, in some fashion, some network monitoring functionality and server health diagnosis, although these features aren't nearly as well leveraged in SMS as its systems management functionality.

In a recent white paper that Microsoft published regarding return on investment (ROI), the authors stated that by implementing SMS, you can expect to save about $17/computer/year by gathering an automatic, routine asset inventory. (That's available at http://www.microsoft.com/smsmgmt/
exec/roi.asp.) Seventeen bucks isn't much, but you're probably not interested in the asset inventory for its ROI potential. You need inventory to build collections so that you can run reports and send software to designated groups of computers. Collections are cool because if they're set up right, they're self-populating. That is, you set up the criteria you want the collection to use when populating itself (using a query that you build first), then you establish a calendar to determine the days and hours when you want the collection to fire and update itself.

You can use either SMS or Windows 2000 Advanced Server to send packages out to users. There are caveats to consider if you're packaging with an eye toward Win2K. You can only send out Microsoft Installer (.MSI) files, which means you'll have to use the Wise Installer or some other package preparation product that creates .MSIs or you'll have to check with the vendor to make sure that an .MSI is available for the application you wish to push. Furthermore, you can only send packages to Win2K computers, even though Windows 9x, Me and NT boxes may be equipped with the Installer service. Also, though you have some granularity in whom you send the package to in Win2K, you have to use Group Policy Objects (GPOs) to accomplish this. SMS makes this process much easier by allowing you to create collections of computers that you want to give the package to. With SMS you can use the Installer to package .EXEs, to repackage applications that you'd like to develop silent or minimal installations for, and to send out applications that have an associated Package Definition File (PDF—now called "SMS" files and suffixed with a .SMS extension). SMS' packaging capabilities are far more robust than Win2K's, and you'll probably find that you'll want more horsepower under the hood when you consider putting together a packaging methodology for your enterprise. There's considerable ROI to be attained by implementing a packaging paradigm-about $1,550 per computer per year, so it's to your company's benefit to entertain such a notion.

Finally, though Win2K provides you with some remote control capabilities in Terminal Services, the remote tools component of SMS is a feature that most help-desks can't live without once they've tasted its capabilities. There's significant ROI to be attained from a remote tools implementation, about $370 per computer per year.

As I mentioned, SMS is a bit weak in the network monitoring department and completely useless in the network metrics section. You might be able to whip out a quick System Monitor (called Performance Monitor in NT 4.0) chart, but your CIO wants uptime figures, not charts. SMS comes with the full-blown version of Network Monitor and as such works as a great protocol analyzer. But it won't let you say, "Hey! What the heck is that process that happens every Friday night at 4:30 that slows the network to a crawl? I'll just fire up SMS Network Monitor and find out!"

A rather lame component called Network Trace allows you to monitor where systems are breaking down, but it's like HP Openview without the third-party add-ins-kind of pretty, but not very powerful.