In Exchange Server 2003, Microsoft expanded the Windows Management Instrumentation (WMI) capabilities by supplying five new providers and 15 new WMI classes. In "Managing Exchange 2003 with WMI, Part 1," January 2004, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40755, and "Managing Exchange 2003 with WMI, Part 2," February 2004, InstantDoc ID 41022, I showed you how to use these new providers and classes to manage Exchange servers, logons, mailboxes, and public folders. In this article, I finish the exploration of the new WMI features by showing you how to use the new providers and classes to manage Exchange queues and links.
Because all messages that users exchange go through the queues and links of an Exchange system, monitoring those queues and links and changing their states are crucial tasks. Exchange 2000 Server lets you perform some monitoring, but Microsoft made several important enhancements in this area in Exchange 2003.
Exchange 2003 provides a new WMI queue provider called ExchangeQueue2Provider in the Root\MicrosoftExchangeV2 namespace. This new provider doesn't replace but rather complements the Exchange 2000 queue provider called ExchangeQueueProvider in the Root\CIMV2\Applications\Exchange namespace. Both providers support a set of classes, which Web Table 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 41342) describes. From this point on in the article, I concentrate on the new WMI queue classes in Exchange 2003. If you want additional information about the WMI queue classes in Exchange 2000, see the Microsoft article "Automating Exchange 2000 Management with Windows Script Host" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/maintain/featusability/ex2kwsh.asp?frame=true.
With the classes that the ExchangeQueue2Provider supports, you can use scripts that retrieve information about Exchange queues and links and perform some management tasks, such as thawing, freezing, and forcing links; disabling and enabling all outbound SMTP traffic; managing mail messages; and monitoring the cache refresh. Before I show you how to use these scripts, you need to understand the important distinction between queues and links.
Queues vs. Links
When you install Exchange 2003, the Exchange setup program creates a series of default queues and links. In a messaging topology, queues refer to the end destinations of the messages, whereas links establish connectivity to the adjacent SMTP nodes. Queues are built based on DNS domains, whereas links reflect TCP/IP connections used to route messages. When you send a message, Exchange places that message in the queues of the domains of all the targeted recipients. For example, if you send a message to users in the hp.com, compaq.com, and digital.com domains, Exchange places the message in three queues called hp.com, compaq.com, and digital.com, respectively.
In the simplest scenario, three outgoing links might correspond to each of these three queues. However, this scenario isn't necessarily the case. If a domain has multiple DNS MX records, Exchange might use more than one link per queue. Or if the domains' DNS MX records contain the same values (e.g., hp.com, compaq.com, and digital.com all point to the server smtp.hp.com), the queues might share the same link.
WMI clearly distinguishes between queues and links. It has classes to manage SMTP queues and links (i.e., Exchange_SMTPQueue and Exchange_SMTPLink) and X400 queues and links (i.e., Exchange_X400Queue and Exchange_X400Link). Because Exchange handles both SMTP and X400 messages, WMI also has classes to manage SMTP and X400 messages (i.e., Exchange_QueuedSMTPMessage and Exchange_QueuedX400Message). Virtual servers handle the queues, links, and messages, so WMI has classes that support SMTP and X400 virtual servers (i.e., Exchange_QueueSMTPVirtualServer and Exchange_QueueX400VirtualServer). Finally, WMI has the Exchange_QueueCacheReloadEvent class, which provides information about when the ExchangeQueue2Provider cache was last refreshed.
Now that you know the difference between queues and links, let's take a quick look at how you can use these nine new WMI classes in scripts. Taking the easiest task first, let's look at how you can retrieve queue and link information.
Retrieving Queue and Link Information
In Parts 1 and 2 of this series, I showed you how to use the script GetCollectionOfInstances.wsf to list all instances of a WMI class. (You can find GetCollectionOfInstances.wsf and all the other code that I discuss in this article on the Exchange & Outlook Administrator Web site. Go to http://www.winnetmag.com/microsoftexchangeoutlook, enter InstantDoc ID 41342 in the InstantDoc ID box, then click Download the Code.) You can use this script to retrieve instances of WMI's queue- and link-related classes. For example, to view SMTP queue information on an Exchange server, you can run GetCollectionOfInstances.wsf against the WMI Query Language (WQL) query
Select * From
Exchange_SMTPQueue
On my Exchange server, this WQL query retrieved the properties of all SMTP queues, including the queues associated with a Routing Group Connector (RGC) and an outgoing Internet mail connector. Figure 1 contains an excerpt from this output. This excerpt shows the values for the QueueName property, which specifies a queue's name. Web Figure 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 41342) shows the output in its entirety.
If you run GetCollectionOfInstances.wsf against the WQL query
Select * From
Exchange_SMTPLink
you'll receive the properties of all the links on an Exchange server. Figure 2 contains an excerpt from the output I received. This excerpt shows the values for the LinkName property, which specifies a link's name. Web Figure 2 shows this output in its entirety. You can also run GetCollectionOfInstances.wsf against WQL queries that specify the Exchange_X400Queue and Exchange_X400Link classes to expose similar sets of properties.
Unfortunately, the queue and link information that you receive through WMI doesn't match the queue and link information you see in Exchange System Manager (ESM). WMI explicitly separates the queue and link information, whereas ESM shows queue and link information together without delineating which information is queue related and which information is link related. In Figure 3, I show which ESM elements correspond to the Exchange_SMTPQueue, Exchange_SMTPLink, Exchange_X400Queue, Exchange_X400Link, and Exchange_QueueSMTPVirtualServer classes.