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 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.
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, 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
- 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
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.