Executive Summary:
| Use PowerShell commands to manage and test Microsoft Exchange Server 2007objects such as mailboxes, servers, and distribution groups. |
Before Exchange Server 2007, no test commands existed for Exchange. In Exchange 2007, you can use Windows PowerShell commands to manage and test objects such as mailboxes, servers, and distribution groups. You need administrative permissions on the Exchange server to execute these commands.
Testing the Basic Server Environment
The first step in testing an Exchange 2007 server is to check that all the necessary components are installed and are configured at the right revision level. The Test-SystemHealth command scans an Exchange 2007 server to verify that it’s running the correct software versions and to detect other conditions that might cause problems. Before it runs, the Test-SystemHealth command checks the Microsoft Web site for any updates that are necessary for accurate server testing. Test-SystemHealth doesn’t deliver the same kind of comprehensive system analysis and comparison against a knowledge base that the Microsoft Exchange Server Best Practices Analyzer (ExBPA) produces, but it’s a quick and useful test to ensure that a server is functioning as expected.
Figure 1 shows the results of running Test-SystemHealth on an Exchange 2007 server. In this case, the command reported the following problems that an administrator should check out:
- Circular logging is enabled for a storage group. This isn’t necessarily a problem, if you have a good reason to enable circular logging (e.g., while you move mailboxes, so as to restrict the number of transaction logs that the Information Store creates as it processes mailbox data). However, the fact that the storage group is called “Critical Mailboxes” indicates a certain priority level for the mailboxes in the group’s databases. This priority level might require protection against failure that circular logging can’t provide, so it’s definitely worthwhile to determine why circular logging is enabled.
- Two drivers need to be checked: hpcisss.sys and cpqcidrv.sys. Because hpcisss.sys is more than two years old, the administrator should check the vendor’s Web site to see whether a newer version is available. The second driver, cpqcidrv.sys, has some known problems, and an update is available from the vendor. Driver details are published on Microsoft’s Web site, and Test-SystemHealth uses this information when it checks a system.
- Some older Messaging API (MAPI) clients are blocked on the server. Again, this isn’t a problem if you explicitly want to block previous versions of Outlook. For example, you might want to force users to use Microsoft Office Outlook 2003 or later so that they use Cached Exchange Mode to connect to the server. However, the administrator should check the validity of client restrictions, because someone might have set a block for a reason that no longer exists.
Testing Exchange Server Health
After you test the server environment, you need to check whether Exchange 2007 is in good health by using the Test-ServerHealth command as follows to validate that Exchange’s services are running on the server.
Test-ServerHealth -Server ExchMbxSvr1
Exchange responds by listing the server roles installed on the target server, with a list of services that are running and any that aren’t currently operational, as Figure 2 shows.
Testing Client Connections
The command Test-MapiConnectivity verifies that clients can make MAPI connections to a database. If you run this command on a mailbox server, Exchange attempts to make a connection to every mailbox database on the server and reports how quickly it can make the connection. You can specify the name of a server or a mailbox database, as in the following code, to focus in on a specific issue.
Test-MapiConnectivity -Server ExchMbxSvr1
Figure 3 shows the output from running this command. If you don’t specify the name of a mailbox to connect to, then Exchange connects to the special systems administrator mailbox in the database.
During Exchange 2007 development, every build until just close to the end of development included the Test-PopConnectivity and Test-IMAPConnectivity commands, which let you check that an Exchange 2007 Client Access server is able to service incoming requests from POP3 and IMAP4 clients, including their ability to make LDAP requests to search Active Directory (AD). In the following commands, note the use of a pipelined call to the Get-Credential command, which forces Exchange to prompt the user with a standard dialog box to gather the credentials necessary to log on to the XYZ\Redmond account.
Test-PopConnectivity
-ClientAccessServer ExchCAS1
-MailboxCredential(Get-Credential Domain1\Redmond)
Test-IMAPConnectivity
-ClientAccessServer ExchCAS1
-MailboxCredential(Get-Credential Domain1\Redmond)
Figure 4 shows the output from running the Test-IMAPConnectivity command.
Unfortunately, Microsoft removed the Test-PopConnectivity and Test-IMAPConnectivity commands from Exchange 2007 at the last minute, citing “stability issues.” (Because of their late removal, these commands are documented in some books, including mine.) The two commands have resurfaced in Exchange 2007 SP1.
The Test-OWAConnectivity command did make it to the end of development in the original Exchange 2007 release. You can use Test-OWAConnectivity to verify that users can connect to Exchange 2007 via HTTP, including the ability to log on to a mailbox with Outlook Web Access (OWA), and that a Client Access server provides the correct URLs for clients to connect. You can test a specific server or all servers (mailbox and Client Access) in an AD site. For example, the following command tests the ability to log on to a mailbox on a specific server for the specified user. Again, Get-Credential prompts for credentials before you can connect to a specific user account with OWA.
Test-OWAConnectivity
-MailboxCredential(Get-Credential Domain1\Redmond)
-MailboxServer ExchMbxSrv1
Figure 5 shows the output from running the command.
Testing Mail Flow
The Test-MailFlow command lets you test whether the Exchange 2007 transport service is functioning correctly. When you run Test-MailFlow, you force Exchange to log on to the system mailbox in the default database on a mailbox server and create and send a test message. You can specify an external email address to receive the test message, as in the following command, and you can test a specific mailbox server rather than the one that you’re currently logged on to.
Test-MailFlow
-TargetEmailAddress [email protected]
The output of the test, which Figure 6 shows, reports the time taken to send the message and whether the test used an external address. Figure 7 shows the kind of message that you’d expect to see following a successful test.
Testing Web Services
Exchange 2007 includes several Web services that are used by Microsoft Office Outlook 2007 and OWA 2007 clients to discover services such as the HTTP address for an Offline Address Book (OAB) distribution point or where free and busy data is held. The Test-OutlookWebServices command tests whether the set of Web services are functioning correctly on a Client Access server. The following command specifies the name of a Client Access server and states that we want to use the email address [email protected] to connect. (This email address must be a valid user account that we have access to.) In addition, we want to use the Availability service to check the free and busy data for the user [email protected].
Test-OutlookWebServices
-ClientAccessServer ExchCAS1
-Identity [email protected]
-TargetAddress [email protected]
The output in Figure 8 shows some errors in contacting services such as OAB, which prompts further investigation to discover if the published HTTP address for this data is correct and available.
Miscellaneous Test Commands
Among the commands that you can use to verify different aspects of the transport system are Test-IPAllowListProvider and Test-IPBlockListProvider. These commands test the connection to an external third-party provider of an IP allow or block list that you might want to use on a Hub Transport server or Edge Transport server. In both cases, you pass the name of the provider and the IP address of a suspected problem server to test. The result of the test will be a true or false to indicate that a connection to the provider is possible and another true or false if the lookup for the IP address is successful. Test-SenderID is a useful command if you use checks against Sender ID records in DNS to verify that servers aren’t sending spam.
If you deploy Exchange Edge Transport servers, you can run the Test-EdgeSynchronization command on a Hub Transport server to verify that any Edge Transport servers that synchronize their copy of Exchange configuration and recipient data with AD (in their local copy of Active Directory Application Mode—ADAM) are up-to-date. If you’ve deployed Exchange unified messaging (UM), you can use the Test-UMConnectivity command to check that everything is working. Likewise, if you’ve deployed Outlook Anywhere, you can use the Test-OutlookAnyWhereConnectivity command to test that it’s functioning correctly. Finally, the Test-ExchangeSearch command verifies that Exchange content indexing and retrieval is working properly, assuming that you’ve enabled content indexing on the target database that you want to check.
A Place to Start
Exchange 2007 includes some useful PowerShell commands that let you test different aspects of an Exchange deployment. Although these commands can’t confirm that everything is working perfectly, they’ll help you test that the messaging system’s fundamentals are functioning. You can include one or more of the commands in a script that you run in the background on a regular basis, or you can open a PowerShell command window when you want to run individual commands.
You can find full details of all of these commands in the Exchange online Help, on the Microsoft TechNet Web site (http://technet.microsoft.com). You’ll also find some examples to get you started testing your own Exchange environment.