How to Use WinRoute and MailQ

Downloads
24434.zip

To monitor the health and performance of your Exchange 2000 Server system, you need to monitor its routing service regularly. Two tools that can help you with this task are WinRoute and the Exchange 2000 Mail Queue Summary Web Page, which is better known as MailQ. Both tools are easy to understand and use.

About WinRoute
To determine how best to route messages, Exchange 2000 uses the Link State Algorithm (LSA), which is similar to the Open Shortest Path First (OSPF) algorithm that IP network implementations use. Simply put, the OSPF algorithm lets routers calculate the shortest connection between nodes in a network for a message. The LSA uses the same concept, except the nodes are called routing groups and the connections are called connectors or links.

To calculate the best path for a message to take, the routing service uses information about the available routing groups and the state of the connectors (i.e., either up or down). In addition, the routing service uses restriction information, such as message-size restrictions. Exchange 2000 stores all this information in a Link State Table (LST). This table exists only in the memory on each server; Exchange 2000 never writes this table to disk.

You can view some of an LST's contents with Exchange System Manager (ESM). Although you can use ESM's Queue Viewer to view link queues and ESM's Monitoring and Status tool to view connector states, ESM doesn't have an option that lets you view a table in its entirety. Rather than obtain only some of the information piecemeal, you can use WinRoute to look at the entire LST for any Exchange server in your organization. You can even capture that information and save it to a file. WinRoute is an invaluable tool for environments with numerous routing groups and connectors.

Using WinRoute
WinRoute is on the Exchange 2000 CD-ROM in the \support\utils\i386 directory. To use WinRoute, you simply copy its executable to any subdirectory from which you want to run it. (You can also use an alternative method of installation. For information about this installation method, see the Microsoft article "XCON: How to Use the WinRoute Tool" at http://support.microsoft.com/directory/article.asp?id=kb;en-us;q281382.) You can run WinRoute from Windows XP Professional Edition, Windows 2000 Professional, and Win2K Advanced Server. (You can probably run WinRoute from XP Home Edition as well, but I haven't tested it with that OS.) After you launch the executable, the Server name dialog box, which Figure 1 shows, prompts you to enter the name of the server to which you want to connect. After you enter a name and click OK, WinRoute displays the LST associated with that server. WinRoute works by connecting to an Exchange 2000 server and identifying itself as another Exchange 2000 server in the same routing group. WinRoute then receives the LST as if it were a real Exchange 2000 server within the organization.

At this point, the LST consists of globally unique identifiers (GUIDs) representing the objects (e.g., server objects, connector objects) that the table contains. After WinRoute receives the GUIDs, it uses them to access Active Directory (AD) and retrieve the human-readable information associated with the GUIDs. Therefore, you need to run WinRoute from an Exchange Administrator account or another account that has full read permissions in the Exchange 2000 portion of AD's configuration naming context (NC).

If you're using WinRoute to examine data about Exchange servers outside your domain, you can bind to a specific directory server to assist with the resolution of the GUIDs. For example, you might need to provide this assistance if you're a consultant running WinRoute on your Win2K Pro laptop to check a customer's site or if you're an Exchange administrator traveling to different locations within your enterprise. To render resolution assistance, enter the server name, then click Bind Options in the Server name dialog box. In the Ldap Bind Options dialog box, which Figure 2 shows, enter the information needed to establish the appropriate Lightweight Directory Access Protocol (LDAP) binding.

A major benefit of using WinRoute is that you can save the link state information to a file and send this file to Microsoft for review if you're having routing problems. You can also use the file to compare how ESM sees your configuration with the configuration that Exchange 2000's routing engine sees. The two should be the same.

The WinRoute display consists of three panes, as Figure 3 shows. The top pane arranges the information by routing group. Each routing group expands to show information about the routing group master, link state version number, routing group addresses, member servers, and connectors.

The middle pane contains information about the connectors. Most administrators find this pane the most useful. For each connector, the pane displays the address space, the address type, the cost, the existence of restrictions, the name, and the routing group and administrative group to which the connector belongs. (The Administrative Group column, which you can't see in Figure 3, is immediately to the right of the Routing Group column.) You can sort the data in each column by clicking the appropriate header. Note that the cost isn't the cumulative cost of traveling to a particular connector but rather the static cost assigned to the connector during configuration. The routing service uses the static cost to determine the least cost path to any given connector by summing the cost of all potential hops along a given route.

The bottom pane contains the raw data that WinRoute received from the Exchange server. WinRoute used this data to retrieve the human-readable information from AD, which appears in the top and middle panes.

About MailQ
After Exchange 2000 determines the best path for a message, Exchange 2000 submits the message to various server queues. MailQ lets you view those servers' message queues from a Web browser. MailQ is part of the Microsoft Exchange 2000 Server Resource Kit.

MailQ is a monitoring tool that's based on Windows Management Instrumentation. WMI is Microsoft's implementation of Web-Based Enterprise Management (WBEM), a protocol that provides uniform access to management information. WMI uses the Common Information Model (CIM), which the Distributed Management Task Force (DMTF) designed, to represent systems, applications, networks, and other managed components. CIM can model any component in the managed environment, regardless of the data source's location. Exchange 2000 supports WMI by including WMI providers that let you access status and other information about the Exchange system.

MailQ lets you view from one Web page the queue lengths for all the Exchange 2000 servers in the Win2K forest in which you're logged on (assuming you have Exchange Administrator privileges). Figure 4 shows a sample MailQ page. If the account with which you've logged on has Exchange Administrator privileges in other Win2K forests (e.g., by means of pass-through authentication), you can even use MailQ to monitor the queues for the Exchange 2000 servers that exist in those Win2K forests.

Using MailQ
MailQ is in the \mailq\web directory on the resource kit's CD-ROM. This tool has two parts: the crawler and the Web files. The crawler is a VBScript file called Globals.vbs. This script collects message queue information from the Exchange servers it's monitoring and writes that information to an XML file. The Web files convert the XML file into an HTML file. The Web files consist of default.html, err.xml, ptinfo.css, ptqueues.xml, and ptqueues.xsl.

Using MailQ is simple. Just follow these steps:

1. On the server that will host your MailQ Web page, create a directory called mailq, with two subdirectories underneath it: crawler and web. (You can use other names for the directory and subdirectories if you'd like.) The \mailq\web subdirectory will be the root of the virtual directory for the MailQ Web page.
2. Copy the crawler and Web files on the resource kit's CD-ROM to your \mailq\crawler and \mailq\web subdirectories, respectively.
3. Open the Microsoft IIS Internet Services Manager (ISM) 5.0 administration console, and expand IIS's root node. Select the machine to host the MailQ Web page, then select a Web site (typically, Default Web Site).
4. Right-click the Web site, and select New, Virtual Directory. Follow the instructions that the Virtual Directory Creation Wizard provides. You'll need to specify an alias (e.g., Mailq). When the wizard asks you to specify the directory for the virtual directory, enter the \mailq\web subdirectory.
5. In a text editor, open the Globals.vbs file so that you can customize it. Enter the names of all the servers you want to monitor. (The script tells you where to place the names.) Your DNS server must resolve the server names, so use a format appropriate for your system.

MailQ appears to be evolving, even though it doesn't have a version number. The latest release of this tool lets you specify the server names in the Globals.vbs file. However, in an earlier release, you had to list the server names in a separate input file called serverlist.xml and place that file in the \mailq\web subdirectory.

6. Start the crawler so that you can begin capturing data. Open the command shell window and run the command

cscript go.wsf X:\mailq\web

where X is the drive on which you've placed the \mailq\web subdirectory. If you called the subdirectory that contains the Web files another name and that name contains spaces, you need to enclose the pathname in quotes. For example, if the Web files are in D:\mailq web\, you run the command

cscript go.wsf "D:\mailq web\"

Note that you must include the trailing backslash (\).

7. Ensure that the Web server is running and test the MailQ Web page. Enter the URL

http://machine_name/alias

where machine_name is the name of the Web server and alias is the alias you specified when you created the virtual directory in Step 4 (e.g., http://e700/mailq).

You can use the URL in Step 7 to view the MailQ Web page at any time. As Figure 4 shows, the page displays the message queue lengths for the SMTP, Message Transfer Agent (MTA), and message database (MDB) links for the specified servers. By clicking the column headers, you can sort the data by time of data collection (Time Updated), server name (Server), or queue length (SMTP, MTA, or MDB).

If the number of queued messages in a given cell is greater than 2000, the cell's background is red. If the number of queued messages is between 1000 and 2000, the cell's background is yellow. This color scheme lets you see at a glance which servers might be having mail-flow problems. You can modify the Extensible Stylesheet Language (XSL) style sheets to change this behavior, if you want.

The Time Updated column shows the time that MailQ gathered the data for a given server. Under normal operation, this column has a white background. If the crawler isn't updating the data, the background will initially turn wheat and, over time, turn to a color called peru (an orange color). A wheat- or peru-colored time column might indicate problems with the crawler. For example, the crawler might not be running or its output might be going to the wrong file. Note that you can change these colors by editing ptinfo.css, MailQ's Cascading Style Sheets (CSS).

Because you can use URLs to access nearly all of Exchange 2000's functions, you can create a custom Web page that combines MailQ results with some of Exchange 2000's standard functions. For example, you can create a Web page that lets you view the message queues and your email messages. Even better, as Figure 5 shows, you can finally hush Lotus Notes users who poke fun at Exchange for not being able to show the Inbox and Calendar at the same time by creating a Web page that shows your Calendar, your Inbox, and the message queues. The script MAILQ from OWA.htm, which Listing 1 shows, creates this Web page. The code at callout A builds a set of menu choices. The code at callout B forms the heart of the display.

You can download MAILQ from OWA.htm from the Code Library on the Exchange & Outlook Administrator Web site (http://www.exchangeadmin.com). To use this script, open it in Notepad (or another editor) and customize the URLs to the user's Inbox (e.g., http://e700/exchange/yo/inbox), Outbox (e.g., http://e700/exchange/yo/outbox), and Calendar (http://e700/exchange/yo/calendar). In addition, customize the URLs to the MailQ Web page (e.g., http://e700/mailq). You can place this HTML code anywhere, including in D:\mailq web\.

Two Useful Tools
Right out of the box, Microsoft offers WinRoute to monitor Exchange 2000's routing service. You can also use the resource kit's MailQ. These two tools can help you obtain a solid grasp of the health and performance of your Exchange 2000 system.