Monitoring Win2K-Style
As you can see, an AD-enabled Win2K network includes several new and important infrastructure components that didn't exist in NT-based networks. As a result, ensuring the health and availability of your Win2K systems means that you'll need to account for these additional components in your network-monitoring routine. (Table 1 lists potential problems with components and services that you need to monitor for regularly.) You can employ several management tools and techniques to maintain a healthy and available network.
The primary monitoring consideration in a Win2K environment is AD and its related services and components, including responsiveness to DNS and LDAP queries, AD intersite and intrasite replication, and the Knowledge Consistency Checker (KCC). The health and availability of services such as DNS, the GC server, and DFS are also important.
However, simply knowing what metrics to monitor is only the first step. The most important and complex aspect of monitoring network health and performance isn't determining what to monitor, but how to use the raw data collected from an array of metrics to make useful determinations. For example, you can use Performance Monitor to collect data about AD replication on several dozen metrics, but simply having this information doesn't mean you automatically know how to interpret the data or what tolerance ranges are acceptable for each metric.
Help from the Outside
I highly recommend that to proactively monitor your network, you invest in a full-featured network-monitoring solution. A useful monitoring system not only collects raw data but also understands how to use the information to identify network problems. Look for this kind of artificial intelligence, as well as alerting options, the ability to monitor AD changes, a product architecture that doesn't hinder network performance, the inclusion of a support knowledge base, and SLA awareness, in a network-monitoring software package.
Problem-resolution features. Many third-party products provide automatic problem-resolution features that enable the software to take corrective actions when it detects a specified problem. (For example, you can configure the software to restart a service when the product discovers that the service is unresponsive.) To accomplish these tasks, many tools use scripting or the ability to call external utilities.
Complex network-monitoring software packages base their decisions on rule sets derived from an internal database or intelligent escalation routines that emulate an administrator's actions. For example, you can configure some third-party tools to restart a service the first time that the service fails, restart the computer if restarting the service didn't resolve the problem, then promote another machine to replace the problem system if restarting the system fails to solve the problem. When considering utilities that provide problem-resolution features, look for products that offer a flexible scripting language or the ability to customize and escalate problem-resolution actions.
Alerting options. Good network-monitoring software provides an assortment of alerting options such as console alerts, network pop-up messages, event log entries, email alerts, pager notifications, and SNMP traps. You can even find monitoring software that interfaces with popular network-management packages. (For more information about these monitoring software products, see "Win2K Network-Monitoring Tools.")
Ability to monitor AD changes. In addition to monitoring and troubleshooting Win2K network infrastructure problems, monitoring software provides the ability to monitor and audit changes made within the network—particularly AD changes. In many organizations, dozens or even hundreds of administrators might make daily changes to AD: adding OUs, users, groups, and printers, and defining group policies. To manage the potential chaos this situation presents, your organization needs a monitoring system that can identify recent AD object changes, who made the changes, and when. For example, you might want to track changes to the AD schema, OUs, contacts, computers, and printers, and directory recovery actions (e.g., running a Directory Services Restore Mode operation on a domain controller). If your monitoring software permits it, consider scheduling these reports to run daily, and make a habit of reviewing these reports often so that you'll have a better chance of catching problems early.
Product architecture. An important consideration when selecting a network-monitoring solution for your organization is the product's architecture. Understanding how the product collects data and what impact this information-collection process will have on your network and servers is important. Does the product employ local agents to gather metrics, or does it use remote queries? Are throttling features available to control network bandwidth and system resource usage? Does the product offer a machine/site/domain hierarchy that efficiently passes data to the central collection database? Does the product provide Web-based management? The answers to these questions can have a significant impact on your network environment and your satisfaction with a third-party tool.
Support knowledge base. Another differentiating feature among network-monitoring software packages is whether the software provides a support knowledge base of common problems and solutions. This information is invaluable from a technical and financial standpoint because it reduces the learning curve of IT staff and the amount of time and money administrators must expend researching and solving problems. Some utilities augment this feature by letting administrators add data to the software's knowledge base, leveraging the IT staff expertise and creating a comprehensive problem-resolution system.
SLA awareness. IT shops that have service level agreements (SLAs) with clients or a parent organization might consider a network-monitoring product that is SLA-aware. This functionality lets the software generate alerts and reports that address exceptions to or compliance with SLA obligations.
Tools of the Trade
Understanding Win2K networks' crucial elements, as well as the features you should look for in monitoring software, lets you make an informed purchasing decision. An overwhelming number of tools that provide network-monitoring features are on the market; however, I've encountered only a handful that support most of the previously mentioned features. For more information about these tools, see "Win2K Network-Monitoring Tools."
If you don't have the budget to purchase a third-party monitoring tool, you're not totally out of luck. Win2K, the free Windows 2000 Support Tools (available on all versions of Win2K or the Microsoft Web site), and the Win2K resource kits provide several free utilities that you can use to assemble a decent network-monitoring system. (Table 2 lists these utilities and their locations.)
If you're enterprising and willing to spend time scripting, you can write administrative scripts that supplement Win2K's utilities' functionality by automating them (e.g., schedule jobs that regularly poll services and machines, make intelligent service queries, and evaluate server responses). With enough elbow grease, you might be able to simulate a rudimentary approximation of some of the features found in the higher-end products.
Sharpen Your Monitoring Skills
With the introduction of the sophisticated AD service, Win2K represents a quantum leap forward in the evolution of NT networks. Win2K also introduces a new level of network infrastructure complexity that requires new knowledge and tools for proper management. To reduce the administrative burdens associated with managing a Win2K network, consider employing network-monitoring software that provides features specific to the needs of a Win2K environment. These tools provide early warning indicators that mitigate the risk of loss associated with network downtime, and offer intelligent knowledge bases that augment and leverage the knowledge of the organization's existing IT staff.
Register
