Like most Windows products released in 2003, Exchange Server 2003 offers more manageability through Windows Management Instrumentation (WMI). As Web Table 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40755) shows, Exchange 2000 Server was the first release in which Microsoft implemented WMI interfaces for Exchange. The original release offered three WMI providers: ExchangeRoutingTableProvider, ExchangeQueueProvider, and ExchangeClusterProvider. These providers are available from the Root\CIMV2\Applications\Exchange namespace. Later, Microsoft released Exchange 2000 Service Pack 2 (SP2), which introduced two new WMI providers in the Root\MicrosoftExchangeV2 namespace: ExchangeDsAccessProvider and ExchangeMessageTrackingProvider.
Little difference exists between the five providers in Exchange 2000 SP2 and those same five providers in Exchange 2003. The only noticeable change is that Microsoft updated the ExchangeMessageTrackingProvider's Exchange_MessageTrackingEntry class by adding values to the class's EntryType property. To view the documentation on the EntryType property's possible values, go to the Microsoft Developer Network (MSDN) Web site at http://msdn.microsoft.com/library/en-us/e2k3/e2k3/_wmiref_pr_exchange_messagetrackingentryentrytype.asp.
In addition to the five WMI providers found in Exchange 2000 SP2, Exchange 2003 offers five new WMI providers in the Root\MicrosoftExchangeV2 namespace: ExchangeFolderTreeProvider, ExchangeMapiTableProvider, ExchangePublicFolderProvider, ExchangeQueue2Provider, and ExchangeServerProvider. So, when you install Exchange 2003, you're installing a total of 10 WMI providers, which support more than 20 WMI classes in various management areas of Exchange 2003.
Any WMI consumer (i.e., any application that can access and use WMI data) can use the WMI classes that the Exchange 2003 installation adds to the Common Information Model (CIM) repository. Therefore, a Windows Script Host (WSH) script, a WMI event consumer provider (e.g., SMTP permanent event consumer), or enterprise-management software (e.g., HP OpenView Operations for Windows) can act as a WMI consumer. Let's look at how to use WSH scripts to access and use the Exchange 2003 WMI management information. I discuss only the new providers that Exchange 2003 adds. I won't discuss the five original Exchange WMI providers because they're well documented. If you're interested in more details, see the Microsoft article "Automating Exchange 2000 Management with Windows Script Host" (http://www.microsoft.com/technet/prodtechnol/exchange/exchange2000/maintain/featusability/ex2kwsh.asp?frame=true). For the same reason, I won't cover WMI basics. If you're unfamiliar with WMI, check out the references at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/further_information.asp.
Exchange 2003's five new providers support 15 new WMI classes. These providers and their classes fall into the following categories:
- Exchange server management
- Exchange logon management
- Exchange mailboxes
- Exchange public folders and folder tree management
- Exchange SMTP and X400 queues management
Because these categories cover a lot of material, I'm splitting this article into three parts. I'll cover the first three categories in Part 1, the fourth category in Part 2, and the fifth category in Part 3.
Exchange Server Management
For Exchange server management tasks, you use the ExchangeServerProvider. This provider supports the Exchange_Server class, which let's you retrieve information about an Exchange 2003 server, such as the server's Administrative Group or Exchange version.
Let's begin by looking at how you use the Exchange_Server class to perform a simple task: obtaining a list of all the available Exchange servers in an organization. The article "Exchange 2000 SP2 WMI Updates," January 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 27211, includes a script named GetCollectionOfInstances.wsf, which uses a WMI Query Language (WQL) query to list all instances of a class. If you run the command
GetCollectionOfInstances.wsf
"Select * From Exchange_Server"
/NameSpace:Root\MicrosoftExchangeV2
from the command-shell window, you can obtain a list of all the available Exchange servers in your organization. Note that the script shows only those properties that have a value. Web Figure 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40755) shows sample data from running GetCollectionOfInstances.wsf against the Exchange_Server class.
You can download GetCollectionOfInstances.wsf as well as all the other scripts discussed in this article from the Exchange & Outlook Administrator Web site. Go to http://www.winnetmag.com/microsoftexchangeoutlook, enter InstantDoc ID 40755 in the InstantDoc ID box, then click Download the Code. To run GetCollectionOfInstances.wsf and the other scripts in this article, you must have Administrator permission if the namespace is accessed remotely or user permission if you access the namespace locally. If you use the user permission, make sure you can log on locally to the server.
Although learning about an Exchange server is interesting, being able to update that information would be more helpful. Using the Exchange_Server class's four read/write properties (i.e., AdministrativeNote, Message-TrackingLogFileLifetime, MonitoringEnabled, and SubjectLoggingEnabled) and two methods (i.e., MoveMTAData and EnableMessageTracking), you can do just that. For example, let's look at how you can use the AdministrativeNote property to update an Exchange server's administrative note and the EnableMessageTracking method to enable message tracking on an Exchange server.
Using the AdministrativeNote property. The script AdminNote.wsf, which Listing 1 shows, is a Windows Script (WS) file that leverages the AdministrativeNote property and the XML features that WSH 5.6 provides. The script uses the TinyErrorHandler.vbs file, which contains the ErrorHandler function. This function helps handle errors that occur during script execution.
Next, AdminNote.wsf creates an SWbemLocator object, which the script uses for the WMI connection. As the code at callout A in Listing 1 shows, the script uses a user ID and password to complete the WMI connection. When the user ID and password are empty strings, the script makes the connection under the security context of the user who's running the script. If you need to run the script under a different security context, you can add a user ID and password in the code at callout A.
Callout A highlights two additional lines that you must customize before you run AdminNote.wsf. First, you must change the cComputerName constant's value to the Fully Qualified Domain Name (FQDN) of an Exchange computer in your organization. In addition, you'll probably want to change the cAdministrativeNote constant's string to a more suitable administrative note.
After establishing the WMI connection, AdminNote.wsf uses the cComputerName constant's FQDN to retrieve an instance of the Exchange_Server class. This instance represents an Exchange 2003 server and its set of information (e.g., the Administrative Group, Exchange version, message-tracking status). Next, the script displays the current value of the AdministrativeNote property, after which it replaces that value with the value assigned to the cAdministrativeNote constant. The script then updates the Exchange_Server instance by invoking the Put_method, which the SWbemObject exposes. (If you're unfamiliar with the SWbemLocator or SWbemObject objects, you can learn about them at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/scripting_api_objects.asp.) After the script saves the instance, the change is visible in Exchange System Manager (ESM).