Monitoring Exchange Server 2010

Lesson 2: Monitoring Mail Flow

One of the most important things you need to monitor in your Exchange organization is how well messages are flowing through your email system. Message queues are probably inevitable in a busy Exchange environment, but are the correct messages in the appropriate queues, are they staying in queues for too long, are queues being retried when appropriate, and how do you track messages that appear to have been lost or stuck in the system?

In this lesson, you will look at how you configure message tracking and message tracking log files. You will look at how you view, retry, and delete message queues. The lesson covers back-pressure thresholds and whether NDRs are sent when specific types of messages (for example, suspected spam messages) are deleted.

Configuring Message Tracking

Message tracking tracks all messages transferred to and from an Exchange Server 2010 Hub Transport, Edge Transport, or Mailbox server. Message tracking logs assist in mail flow analysis, reporting, and troubleshooting. By default, message tracking is enabled on all Exchange Server 2010 Hub Transport, Edge Transport, or Mailbox servers. You can use the EMS and (for a limited number of settings) the EMC to configure message tracking. Note that this section discusses message tracking configuration. How you track messages and view message tracking reports is covered later in this lesson.

Enabling or Disabling Message Tracking and Changing the Log Path

To use the EMC to enable or disable message tracking on a Hub Transport server, carry out the following procedure:

1. Open the EMC and expand the Console tree.

2. In the Console tree, select Hub Transport under Server Configuration.

3. In the Action pane, click Properties directly under the server name.

4. In the Properties dialog box, click the Log Settings tab, as shown in Figure 9-13.

   

   Figure 9-13 The Log Settings tab of the server Properties dialog box

5. In the Message Tracking Log section, you can select or clear the Enable Message Tracking Log check box to enable or disable message tracking. If message tracking is enabled, you can, if required, change the default path to the message tracking log. Note that you cannot use the EMC to change the path to the message tracking log on Mailbox servers that do not also have the Hub Transport role installed.

6. Click OK to save your changes and close the Properties dialog box.

To use the EMS to enable or disable message tracking and to change the path to the message tracking log, you enter a command based on the Set-TransportServer or Set-MailboxServer cmdlet. For example, the following command disables message tracking on the Exchange Server 2010 Hub Transport server VAN-EX1:

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogEnabled:$false

The following command enables message tracking on the Exchange Server 2010 Mailbox server VAN-EX2:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogEnabled:$true

The following command changes the path to the message tracking log on Hub Transport server VAN-EX1 to C:\Logfiles\MessageTracking:

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogPath C:\LogfilesMessageTracking

The following command changes the path to the message tracking log on Mailbox server VAN-EX2 to C:\Logfiles\Tracking\MessageLogs:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogPath C:\Logfiles\TrackingMessageLogs

Configuring the Size and Age of Message Tracking Log Files

By default, the maximum size for each message tracking log file is 10 megabytes (MB). When a message tracking log file reaches its maximum size, Exchange Server 2010 opens a new message tracking log file. This continues until the message tracking log directory reaches its specified maximum size (by default 250 MB) or until a message tracking log file reaches its specified maximum age (by default 30 days). In either of these cases, Exchange Server 2010 deletes the oldest message tracking log file.

You can use the EMS (but not the EMC) to change the maximum size of each message tracking log file, the maximum age of each message tracking log file, and the maximum size for the entire message tracking log directory on Hub Transport, Edge Transport, and Mailbox servers.

The following command changes the maximum size of each message tracking log file on the Hub Transport server VAN-EX1 to 15MB (the same command would work on an Edge Transport server):

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxFileSize 15MB

The following command changes the maximum age of each message tracking log file on the Hub Transport server VAN-EX1 to 35 days (as before, the same command would work on an Edge Transport server):

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxAge 35.00:00:00

The following command changes the maximum size of the message tracking log file directory on the Hub Transport server VAN-EX1 to 300 MB (again the same command would work on an Edge Transport server):

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxDirectorySize 300MB

The commands to configure maximum log size and age and the maximum size of the message tracking log file directory on a Mailbox server are similar, except that the Set-MailboxServer cmdlet is used. Note that if an Exchange Server 2010 server holds both the Mailbox and the Hub Transport roles, the effective maximum size of its message tracking log file directory is twice the size that is specified because message tracking log files for the mailbox and the transport functions have different prefixes. File prefixes are discussed later in this lesson.

The following command changes the maximum size of each message tracking log file on the Mailbox server VAN-EX2 to 20 MB:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogMaxFileSize 20MB

The following command changes the maximum age of each message tracking log on the Mailbox server VAN-EX2 to 40 days:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogMaxAge 40.00:00:00

The following command changes the maximum size of the message tracking log file directory on the Mailbox server VAN-EX2 to 350 MB:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogMaxDirectorySize 350MB

Configuring Message Subject Logging in Message Tracking Logs

By default, the subject line of a Simple Mail Transfer Protocol (SMTP) email message is stored in the message tracking log. However, you may want to disable message subject logging to comply with security or privacy requirements. Before you enable or disable message subject logging, you need to verify your organization’s policy about revealing subject-line information. As with previous message tracking configurations, you use the Set-TransportServer and Set-MailboxServer EMS cmdlets to enable or disable message subject logging on Hub Transport and Edge Transport servers and on Mailbox servers, respectively.

For example, the following command disables message subject logging in message tracking logs on the Hub Transport server VAN-EX1:

Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogSubjectLoggingEnabled $false

The following command enables message subject logging in message tracking logs on the Mailbox server VAN-EX2:

Set-MailboxServer -Identity VAN-EX2 -MessageTrackingLogSubjectLoggingEnabled $true

Monitoring Transport Queues

If a mailbox database is experiencing performance problems, this typically manifests itself in excessively long transport queues associated with the database. If a Hub Transport or Edge Transport server becomes overloaded, this can result in an excessive number of messages in the transport queues on that server. It is a good idea to monitor transport queues on a regular basis, and you would typically look at queue statistics as a matter of course when you encounter performance problems.

You can use both the EMC and the EMS to monitor transport queues. To use the EMC on a Hub Transport server, carry out the following procedure:

1. Open the EMC on the Hub Transport server and expand the Console tree.

2. Click Toolbox in the Console tree.

3. Click Queue Viewer in the Result pane.

4. Click Open Tool in the Actions pane.

5. Click the Queues tab in Queue Viewer, shown in Figure 9-14. This displays a list of the queues on the server to which you are connected. Note that you are unlikely to see any queues on your isolated test network.

   

   Figure 9-14 Queue viewer

6. If you want to export the list of queues, click Export List in the Actions pane. If you want a list of messages in a queue, click the queue in the Queues tab in the Result pane and click View Messages in the Actions pane.

You can use the Get-Queue EMS cmdlet to view transport queues. For example, the following command lets you view all the queues on the Hub Transport or Edge Transport server on which it is entered:

Get-Queue | FL

The following command displays detailed information for a queue that exists on the server VAN-EX1:

Get-Queue -Server VAN-EX1 | FL

Figure 9-15 shows the output from this command.

Filtering Queues

In a busy Exchange Server 2010 organization, the number of queues can become very large, depending on the current mail flow. The queue list can change frequently as messages enter and leave a server. You can filter queues to search for specific criteria and locate queues that are experiencing mail flow problems. You can use the Exchange Queue Viewer in the EMC and EMS commands to filter queues. You can then perform operations that modify the status of those queues.

To use the Queue Viewer to filter queues on a Hub Transport server, carry out the following procedure:

1. Open the EMC on the Hub Transport server and expand the Console tree.

2. Click Toolbox in the Console tree.

3. Click Queue Viewer in the Result pane.

4. Click Open Tool in the Actions pane.

5. Click the Queues tab in Queue Viewer.

6. Click Create Filter.

7. In the queue property drop-down list, select a queue property. The options available are shown in Figure 9-16.

   

   Figure 9-16 Queue property options

8. Select a comparison operator from the comparison operator drop-down list (for example, Equals).

9. Depending on the queue property you have chosen, either type a value in the value drop-down list or select a value from the drop-down list. If the property requires a date/time expression, change the current date/time values or click the drop-down list to select a date from the calendar interface. Figure 9-17 shows the options available for the Status queue property.

   

   Figure 9-17 Value options available for the Status queue property

10. Optionally, click Add Expression and specify additional filter criteria. Only queues that meet all filter criteria are displayed.

11. Click Apply Filter to display only queues that meet the filter criteria.

You can also use the Get-Queue EMS cmdlet with the Filter parameter to filter queues. For example, the following command lists all the queues on the Hub Transport or Edge Transport server on which it is entered that contain more than 50 messages:

Get-Queue -Filter {MessageCount -gt 50}

You can also use the Filter parameter of the Get-Queue cmdlet to display the number of messages in queues bound for a particular destination. For example, the following command displays the number of messages in queues on the Hub Transport or Edge Transport server on which it is entered where the next-hop destination is the Contoso.com domain:

Get-Queue -Filter{NextHopDomain -eq "contoso.com"}

You can also use a remote server name or site name in place of the SMTP domain name.

In general, the Filter parameter requires an expression that identifies the queues that you want to display. The expression includes a property name followed by a comparison operator and value. The following queue properties are valid for the Filter parameter:

• DeliveryType The delivery type for a queue must be one of the following values:

  • DNSConnectorDelivery

  • NonSMTPGatewayDelivery

  • SmartHostConnectorDelivery

  • SmtpRelayWithinAdSitetoEdge

  • MapiDelivery

  • SmtpRelayWithinAdSite

  • SmtpRelaytoRemoteAdSite

  • SmtpRelaytoTiRg

  • Undefined

  • Unreachable

• Identity The queue identity takes the form Server\destination, where destination is a remote domain, Mailbox server, or persistent queue name.

• LastError A text string that contains the last error recorded for a queue.

• LastRetryTime The time when a connection was last tried for this queue.

• MessageCount The number of items in the queue.

• NextHopConnector The GUID of the connector that was used to create the queue.

• NextHopDomain The next hop domain of the queue, specified as a remote SMTP domain, a server name, the name of an Active Directory site, or a message database identifier.

• NextRetryTime The time when a connection will next be tried for this queue.

• Status The status of the queue. The queue status can be Active, Ready, Retry, or Suspended.

Queue Types

How a message is routed determines the type of queue in which it is stored. The following types of queues are used in Exchange Server 2010:

• Submission queue A submission queue is a persistent queue that the categorizer uses to store messages that need to be resolved, routed, and processed by transport agents. All messages that are received by a Transport server are held in the submission queue before processing. Messages are submitted through SMTP-receive, the Pickup directory, or the store driver. The categorizer retrieves messages from this queue and determines the location of the recipient and the route to that location. After categorization, the message is moved to a delivery queue or to the unreachable queue. Only one submission queue exists on each Exchange Server 2007 Transport server. Messages that are in the submission queue cannot be in other queues at the same time.

  NOTE: THE CATEGORIZER

  The categorizer is an Exchange transport component that processes all inbound messages and determines what to do with them on the basis of information about their intended recipients. In Exchange 2010, a server with the Edge Transport role uses the categorizer to route messages to their appropriate destinations. A server with the Hub Transport role uses the categorizer to expand distribution lists and to identify alternative recipients and forwarding addresses. After the categorizer retrieves full information about recipients, it uses that information to apply policies, route the message, and perform content conversion.

• Mailbox delivery queue A mailbox delivery queue holds messages that are delivered to a Mailbox server by using an encrypted Exchange RPC. Mailbox delivery queues exist only on servers with the Hub Transport role. A mailbox delivery queue holds messages that are being delivered to mailbox recipients whose mailbox data is stored on a Mailbox server located in the same site as the Hub Transport server. Several mailbox delivery queues can exist on a server with the Hub Transport role. The next hop for a mailbox delivery queue is defined by the distinguished name of the mailbox store.

• Remote delivery queue A remote delivery queue holds messages that are being delivered to a remote server by using SMTP. Remote delivery queues can exist on servers with both the Hub Transport and the Edge Transport role, and more than one remote delivery queue can exist on each server. A remote delivery queue contains messages that are being routed to recipients that have the same delivery destination. On a server with the Edge Transport role, these destinations are external SMTP domains or SMTP connectors. On a server with the Hub Transport role, the destinations are outside the Active Directory site in which the server with the Hub Transport role is located. A server with the Hub Transport role can also route Internet email. Remote delivery queues are created dynamically as required and are automatically deleted from the server when they no longer hold messages and when their (configurable) expiration time has passed. By default, a remote delivery queue is deleted three minutes after the last message has left the queue. The next hop for a remote delivery queue is an SMTP domain name, a smart host name or Internet Protocol (IP) address, or an Active Directory site name.

• Poison message queue The poison message queue is a special queue that is used to isolate messages that are potentially harmful to Exchange Server 2010. This queue is typically empty. If no poison messages exist, the queue does not appear in queue-viewing interfaces such as Queue Viewer. The poison message queue is always in a Ready state. By default, all messages in this queue are suspended. You can delete the messages if you judge that they are harmful to the system. If an event that causes a message to enter the poison message queue is unrelated to the message, message delivery can be resumed. If delivery is resumed, the message enters the submission queue.

  MORE INFO: DETERMINING WHETHER A MESSAGE IS A POISON MESSAGE

  A poison message is a message that has exceeded the maximum number of delivery attempts to an application. For more information about poison message identification and how these messages are handled, see http://msdn.microsoft.com/en-us/library/ms789028.aspx.

• Unreachable queue The unreachable queue contains messages that cannot be routed to their destinations. An Edge Transport or Hub Transport server can have only one unreachable queue. Typically, an unreachable destination can be created when configuration changes modify the delivery routing path. All messages that have unreachable recipients reside in the unreachable queue.

When a message is received, a transport mail item is created and saved to the database, and a unique identifier is assigned to the item. If a message or transport mail item is being sent to more than one recipient, the item can have more than one destination. Each destination represents a separate routing solution for the transport mail item, and each routing solution causes a routed mail item to be created.

The routed mail item refers to the transport mail item. If a transport mail item has more than one routing solution, more than one routed mail item references the same transport mail item. A single message addressed to recipients in two different domains appears as two distinct messages in the delivery queues, even if there is only one transport mail item in the database.

Suspending, Resuming, and Retrying Queues

Sometimes if you are experiencing message flow problems on a Hub Transport or Edge Transport server, you need to stop queued messages from being sent so that you can investigate problems within the queue. You then need to enable the queue to resume normal operations. If a queue is experiencing problems sending messages, it will try again to do so at configured intervals. Sometimes you need to force an immediate retry. This section investigates all these situations.

Suspending Queues

You can suspend a transport queue on a Hub Transport or Edge Transport server if you want to prevent messages from leaving the queue. Suspending a queue does not change the status of messages in that queue. Messages that are in the process of delivery will finish operations. You can suspend a queue to stop mail flow and then suspend one or more messages in the queue. When you resume the queue, the messages that were suspended will not leave the queue.

You can suspend a queue that has a status of Active or Retry. You can also suspend the Unreachable queue and the Submission queue. If you suspend the Unreachable queue, items are not resubmitted to the categorizer when the Transport server receives configuration updates until the queue is resumed. If you suspend the Submission queue, messages are not picked up by the categorizer until the queue is resumed.

The Queue Viewer can be used to suspend a queue. You access the Queues tab as described earlier in this lesson, right-click the queue, and click Suspend. You can also select several queues and then click Suspend in the Actions pane.

You can use commands based on the Suspend-Queue EMS cmdlet. Like the Get-Queue cmdlet, this supports the Filter parameter. For example, the following command suspends all queues that have a message count equal to or greater than 500 and have a status of Active:

Suspend-Queue -Filter {MessageCount -ge 500 -and Status -eq "Active"}

The cmdlet supports the Confirm switch, which you can use to suppress the confirmation prompt that appears by default when the cmdlet is run. For example, the following command suspends the same queues as the previous command, but you do not need to confirm the action:

Suspend-Queue -Filter {MessageCount -ge 500 -and Status -eq "Active"} -Confirm:$False

Resuming Queues

When you resume a suspended queue on a Hub Transport or Edge Transport server, this restarts the queue’s outgoing activities. The queue must have a status of Suspended for this action to have any effect. When you resume a queue, the status of messages in the queue does not change. Messages that have a status of Suspended remain suspended and do not leave the queue.

To use the Queue Viewer to resume queues, you must first list all the queues that have a status of Suspended. Open the tool, access the Queues tab, and click Create Filter, as described in the procedure to filter queues earlier in this lesson. Then set the queue property, comparison operator, and value drop-down lists to Status, Equals, and Suspended, respectively. Click Apply Filter, and all the queues with a status of Suspended on the server are displayed. You can then right-click an individual queue and click Resume or select a number of queues and click Resume in the Actions pane.

You can use the Resume-Queue EMS cmdlet to resume queues. This cmdlet also supports the Filter parameter. For example, the following command resumes all the suspended queues on the Hub Transport or Edge Transport server on which it is entered:

Resume-Queue -Filter {Status -eq "Suspended"}

Retrying Queues

When a Hub Transport or Edge Transport server cannot connect to the next hop, the delivery queue is put in a status of Retry. You can retry a delivery queue by using the EMC Queue Viewer or the EMS. This forces an immediate connection attempt and overrides the next scheduled retry time. If the connection is unsuccessful, the retry interval timer is reset. The delivery queue must be in a status of Retry for this action to have any effect.

To use Queue Viewer to retry a queue, you first need to display all the queues that have a status of Retry. To do this, you open the tool, access the Queues tab, and click Create Filter, as described in the procedure to filter queues earlier in this lesson. You then set the queue property, comparison operator, and value drop-down lists to Status, Equals, and Retry, respectively. Click Apply Filter, and all the queues with a status of Retry on the server are displayed. You can then right-click an individual queue and click Retry or select a number of queues and click Retry in the Actions pane.

You can also use commands based on the Retry-Queue cmdlet to retry transport queues. For example, the following command retries all queues with the status of Retry on the Hub Transport or Edge Transport server on which it is entered:

Retry-Queue -Filter {status -eq "Retry"}

The following command forces a connection attempt for all queues on a Hub Transport or Edge Transport server that are holding messages for the domain fabrikam.com and have a status of Retry:

Retry-Queue -Filter {NextHopDomain -eq "fabrikam.com" -and Status -eq "Retry"}

Managing Messages

In addition to managing message queues, you also need to manage messages within queues. Problems with a single message can prevent an entire queue of messages from being delivered. Sometimes you want to identify and view messages that are greater than a specified size, that are from a particular address, or that you suspect are spam.

Filtering Messages

You can filter messages on a Hub Transport or Edge Transport server by message properties, search using specific criteria, and locate messages that may be causing a mail flow problem. You can then modify the status of those messages. You can use Queue Viewer or the EMS to search for messages by using filter criteria.

To use Queue Viewer to set up a filter that identifies messages by specified criteria, carry out the following procedure:

1. Open the tool, as previously described in this lesson.

2. Click the Messages tab, as shown in Figure 9-18. A list of all messages in all queues on the server is displayed.

3. Alternatively, because there can be a large number of messages on a busy Exchange Server 2010 server, you might find it easier to first click the Queues tab and search for the queue in which the messages you want to access are contained. You can then right-click the queue name and click Messages. A tab for the queue you selected then appears.

   

   Figure 9-18 The Message tab in Queue Viewer

4. If you elected to access the Messages tab directly, click Create Filter. Note that this control is not available on tabs that identify specific queues, which permit you to specify message filter settings immediately.

5. Select a message property from the message property drop-down list. For example, if you want to identify messages that are possible spam, click SCL. The available options are shown in Figure 9-19.

   

   Figure 9-19 Available message property options

6. Select a comparison operator from the comparison operator drop-down list. For example, if you had selected SCL in the message property drop-down list, you might select Greater Than Or Equals in the comparison operator drop-down list.

7. Type a value in the value drop-down list or select a value if the property has fixed values. If the property requires a date/time expression, change the current date/time values or click the drop-down list to select a date from the calendar interface. For example, to list all messages with a spam confidence level (SCL) greater than or equal to 6, you set the filter conditions, as shown in Figure 9-20.

   

   Figure 9-20 Filtering messages with an SCL greater than or equal to 6

8. Optionally, click Add Expression to specify additional filter criteria. Only messages that meet all filter criteria are displayed.

9. Click Apply Filter. Messages that meet the filter criteria are displayed.

You can use the Get-Message EMS cmdlet with the Filter parameter to filter messages. For example, the following command lists all messages that have an SCL equal to or greater than 6 and were sent from any sender in the Adatum.com domain:

Get-Message -Filter {SCL -ge 6 -and FromAddress -eq "*adatum.com"}

Viewing Message Properties

When you have used Queue Viewer to identify and list a specific message, you can right-click that message and click Properties. The Properties dialog box for a message has two tabs: General and Recipient Information.

The General tab displays the following fields:

• Identity

• Subject

• Internet Message ID

• From Address

• Status (Active, Pending Remove, Pending Suspend, Ready, Retry, or Suspended)

• Size (KB)

• Message Source Name

• Source IP

• SCL

• Date Received

• Expiration Time

• Last Error

• Queue ID

• Recipients

• Retry Count

The Recipient Information tab displays the following fields:

• Address

• Status

• Last Error

You can also use the Get-Message cmdlet to view the properties of a message that is queued for delivery. The following command tabulates the sender address, recipients, subject, and received date information for all messages that are currently in the Retry state:

Get-Message -IncludeRecipientInfo -Filter {Status -eq "Retry"} | FT FromAddress,
Recipients,Subject,DateReceived

Suspending and Resuming Messages

You can suspend one or more messages in a queue on a Hub Transport or Edge Transport server. When you suspend a message, you prevent its delivery. However, a message that appears in the queue but is already in the process of delivery will not be suspended. Instead, delivery will continue, and the message status will be set to Pending Suspend. If the delivery fails, the message will reenter the queue, and it will then be suspended. You cannot suspend a message in the Submission queue or in the Poison Message queue. A message that is addressed to multiple recipients might be located in multiple queues. To suspend a message in more than one queue in a single operation, you use a filter.

You can suspend a message that is listed in Queue Viewer by right-clicking the message and clicking Suspend. You can also use the Suspend-Message EMS cmdlet. If you want to suspend a message identified by filter criteria or a message that appears in more than one queue (for example, a message sent to multiple recipients), you can use the Filter parameter. For example, the following command suspends all messages in queues that are from any sender in the domain BlueSkyAirlines.com:

Suspend-Message -Filter {FromAddress -eq "*blueskyairlines.com"}

The following suspends a message with the message ID 2 in the unreachable queue on Hub Transport server VAN-EX1:

Suspend-Message -Identity VAN-EX1\Unreachable\2

You can resume a message that currently has a status of Suspended on a Hub Transport or Edge Transport server. When you resume a message, you enable its delivery. If you resume a message located in the Poison Message queue, the message will be sent to the categorizer for processing.

You can use the Queue Viewer to list all suspended messages on a server or in a selected queue by applying a filter with the message property drop-down list set to Status, the comparison operator drop-down list set to Equals, and the value drop-down list set to Suspended. Click Apply Filter, and all messages that have a status of Suspended are displayed. You can now right-click a message on the list and click Resume.

You can use the Resume-Message EMS cmdlet with the Filter parameter to resume one or more suspended messages. For example, the following command resumes all messages being sent from any sender in the Fabrikam.com domain:

Resume-Message -Filter {FromAddress -eq "*fabrikam.com"}

Removing and Exporting Messages

You can remove messages that are in a queue on a Hub Transport or Edge Transport server. When you remove a message, you can select whether to send an NDR. You cannot remove a message from the Submission queue.

To remove a message listed in Queue Viewer, right-click it and select either Remove Messages (with NDR) or Remove Messages (without NDR). When a confirmation dialog box appears, click Yes.

You can use the Remove-Message EMS cmdlet with the Filter parameter to remove messages. For example, the following command removes messages that have the subject “Weight Loss” without sending an NDR:

Remove-Message -Filter {Subject -eq "Weight Loss"} -WithNDR $false

Figure 9-21 shows the output from this command.

If you want the command to run without requiring confirmation, you can use the Confirm switch, for example:

Remove-Message -Filter {Subject -eq "Weight Loss"} -WithNDR $false -Confirm:$False

When you want to investigate message content, you can export a message from a queue to a file. When you do this, the message is not removed from the queue; instead, a copy of the message is created in the specified location as a text file that you can open using an application such as a text editor or an email client. Optionally, you can resubmit the message by using the Replay directory on any Hub Transport server or Edge Transport server inside or outside your Exchange organization.

You need to use an EMS command to export a message. Queue Viewer cannot perform this function, although you can use this tool to locate, identify, and suspend messages before you export them. Before you export messages, the following prerequisites must be in place:

• The target directory must exist. It can be local to the Exchange Server 2010 server on which the messages exist or a share on a remote server. The command does not create the target directory for you. If you do not specify a path, the current EMS working directory is used.

• The account you use must have Write permission to the destination directory.

• You need to locate and suspend messages to be exported to prevent their delivery during the export process. A message will not be exported unless it is suspended. Messages in the poison message queue are already suspended. You cannot suspend messages in the Submission queue and therefore cannot export messages from that queue.

• The destination file must have a .eml extension.

You can use the Export-Message EMS cmdlet to export a message that you have located, identified, and suspended. You need to identify the message, for example, by specifying its InternalMessageID. The following command exports the message that has an InternalMessageID of 6391 and that is located in the remote delivery queue for the domain Fabrikam.com on the server VAN-EX1 to the path C:\ExportedMessages\Fabrikam\export001.eml:

Export-Message -Identity VAN-EX1\Fabrikam.com\6391 -Path
"C:\ExportedMessages\Fabrikam\export001.eml"

If you want to export all messages from a specific queue, you first retrieve the messages using the Get-Message cmdlet. You need to export each message individually, so you pipe the results of the Get-Message operation into the ForEach-Object PowerShell cmdlet. You need to provide an individual path and file name for each message. In the example given below you do this by specifying a variable, $Destination, that consists of the Internet Message ID and a .eml extension. The Internet Message ID field contains angled brackets (> and <), which need to be removed because they are invalid characters in a file name. This is done using the Replace method in the temporary variable. When the appropriate path is created for each message, that message is exported to it.

The following command exports a copy of all the messages from the Fabrikam.com remote delivery queue on the server VAN-EX1 to the directory C:\ExportedMessages\Fabrikam on the local computer using the Internet Message IDs of each message as the file name (note that this command hangs but does not return an error if the queue Contoso.com does not exist on server VAN-EX1):

Get-Message -Queue "VAN-EX1\Contoso.com" | ForEach-Object {$Destination="C:ExportedMessages\Fabrikam\"+$_InternetMessageID+".eml";$Destination=$Destination.
Replace("<","_");$Destination=$Destination.Replace(">","_");Export-Message $_.Identity |
AssembleMessage -Path $Destination

The following command exports a copy of all the messages from senders in the BlueSkyAirlines.com domain from all queues on the server VAN-EX1 to the directory C:\ExportedMessages\BlueSkyAirlines on the local computer using the Internet Message IDs of each message as the file name:

Get-Message -Filter {FromAddress -like "@BlueSkyAirlines.com"} -Server "VAN-
EX1" | ForEach-Object {$Destination="C:\ExportedMessages\BlueSkyAirlines"+$_
InternetMessageID+".eml";$Destination=$Destination.Replace("<","_");$Destination=$Destin
ation.Replace(">","_");Export-Message $_.Identity | AssembleMessage -Path $Destination}

Tracking Messages

The configuration of message tracking logs on transport and Mailbox servers was discussed earlier in this lesson. This section describes their use and how an administrator would obtain a message tracking report for troubleshooting purposes.

A unique message tracking log exists on every Windows Server 2010 Hub Transport, Mailbox, or Edge Transport server. This is a comma-separated value (CSV) file that contains detailed information about the history of each email message as it travels through an individual server. You can use the Get-MessageTrackingLog EMS cmdlet to search message information stored in the message tracking log.

You can specify parameters such as Sender to view entries sent from a specific email address or Recipients to view entries sent to one or more email addresses. You can specify start and end dates and times. Typically, you want to look at the message tracking log on the server on which you are working, but you also have the option of using the Server parameter to specify another Hub Transport, Mailbox, or Edge Transport server in your organization.

You can view entries for messages with a specific EventID (for example, BadMail, Defer Deliver, PoisonMessage, Fail, and so on). You can specify an InternalEventID to get tracking information about a specific message. The ResultSize parameter specifies how many messages are returned. If you want to see all the messages that meet the other specified conditions but you do not know how many there are, set ResultSize to Unlimited.

For example, the following command retrieves message tracking log entries that were created between November 13, 2010, at 09:00 hours and March 21, 2011, at 17:00 hours with a Sender parameter value of DonHall@adatum.com:

Get-MessageTrackingLog -ResultSize Unlimited -Start "11/13/2010 9:00AM" -End "03/21/2011
5:00PM" -Sender "DonHall@adatum.com"

A message tracking report gives detailed information about a specific email message, and you typically use message tracking reports during troubleshooting. Suppose, for example, that Don Hall at the Adatum Corporation is expecting an email message from Jeff Hay at Fabrikam, but the message does not arrive. Don contacts the Adatum Help desk, and Kim Akers views the message tracking report for that message.

Kim uses a command based on the Get-MessageTrackingReport EMS cmdlet. As an administrative user, Kim can enter a command that uses the BypassDelegateChecking parameter to enable her to view a message sent from another user to a different user. She can specify whether the report is a summary or a verbose report. She can use the DoNotResolve parameter to prevent the resolution of email addresses to display names and hence improve performance.

However, the Get-MessageTrackingReport cmdlet requires the ID for the message tracking report. Therefore, Kim needs first to use the Search-MessageTrackingReport EMS cmdlet to find the message tracking report ID for the message and pass this information to the Get-MessageTrackingReport cmdlet. Typically, Kim might find all message tracking reports for messages from Jeff Hay to Don Hall and use the ForEach-Object PowerShell cmdlet to generate a report for each message.

The message tracking report typically identifies where the message is held in the transport queues. The message could be in the unreachable queue or the poison message queue, in which case it will not be delivered. It could be in a queue that is currently suspended, or the message itself could be suspended. The message could be in a queue with the status of Retry, which would indicate that connectivity problems may be preventing next-hop delivery. You can resume a message or a message queue or manually retry a queue as appropriate. If this does not result in message delivery, further investigation of the message properties (described earlier in this lesson) may be required.

The following command, entered by Kim Akers on a server in the Adatum Exchange organization, gets the message tracking reports for all email messages Jeff Hay has sent to Don Hall and displays a detailed message tracking report for each email message, without resolving display names:

Search-MessageTrackingReport -Identity "Don Hall" -Sender "JeffHay@fabrikam
.com" -ByPassDelegateChecking -DoNotResolve | ForEach-Object { Get-MessageTrackingReport
-Identity $_.MessageTrackingReportID -DetailLevel Verbose -BypassDelegateChecking
-DoNotResolve -RecipientPathFilter "DonHall@adatum.com" -ReportTemplate RecipientPath }

Testing Mail Flow

Exchange Server 2010 provides you with tools to test mail flow and resolve situations where email messages are not delivered. The EMC provides the Microsoft Exchange Mail Flow Troubleshooter as part of the Microsoft Exchange Troubleshooting Assistant, but the primary tool for resolving mail flow and resolving nondelivery situations is the EMS Test-Mailflow cmdlet.

You can use this cmdlet to diagnose whether mail can be successfully sent from and delivered to the system mailbox on a Mailbox server. You can also use it to verify that email is sent between Mailbox servers within a specified time (sometimes termed the latency threshold). The Test-Mailflow cmdlet tests mail submission, transport, and delivery. It verifies that each Mailbox server can successfully send itself a message. You can also use this cmdlet to verify that the system mailbox on one Mailbox server can successfully send a message to the system mailbox on another Mailbox server.

The Test-Mailflow cmdlet supports the AutoDiscoverTargetMailboxServer parameter. This specifies whether a command will automatically populate a list of target Mailbox servers to which a test message is sent. The task queries Active Directory Directory Services (AD DS) to discover all Mailbox servers and then sends each server a test message.

You can use the TargetDatabase parameter to specify a target mailbox database to which messages are sent. You can also use the TargetEmailAddress parameter to specify a target email address when you want to send test messages to a Mailbox server in a remote forest. The TargetMailboxServer parameter specifies one or more Mailbox servers in the local Exchange organization to which test messages are sent. If more than one of these parameters is specified, the AutoDiscoverTargetMailboxServer parameter takes precedence over the TargetEmailAddress and TargetMailboxServer parameters. The TargetMailboxServer parameter takes precedence over the TargetEmailAddress parameter. A system mailbox must be present on all servers involved in the test.

Several parameters specify time-outs. The ActiveDirectoryTimeout parameter specifies the number of seconds that elapse before the task provides an informational message about the delay. The default value is 15 seconds. The ErrorLatency parameter specifies the number of seconds that elapse before an error event is logged in Microsoft System Center Operations Manager 2007. The default value when a test message is sent to the local Mailbox server is 15 seconds. When a test message is sent to a remote Mailbox server, the default value is 180 seconds.

The ExecutionTimeout parameter specifies the maximum time that the task can run before the test is determined to be a failure. If no test message or delivery report arrives before the execution time expires, the task ends, and an error is reported. When the task is run in the EMS, the default setting is 240 seconds. When you include the MonitoringContext parameter, which specifies that System Center Operations Manager 2007 is being used for server monitoring, the default setting is 15 seconds.

The Identity parameter specifies the source Mailbox server name or source mailbox SMTP address from which a test message is sent. The default value is the local Mailbox server. If you include the Confirm switch, this causes the command to pause and requires you to acknowledge that you want the task to proceed before processing continues. You do not specify a value with the Confirm switch.

The following command tests message flow from the Mailbox server VAN-EX1 to the Mailbox server VAN-EX2:

Test-Mailflow VAN-EX1 -TargetMailboxServer VAN-EX2

The following command tests message flow from the server VAN-EX1 to the email address DonHall@adatum.com:

Test-Mailflow VAN-EX1 -TargetEmailAddress DonHall@adatum.com

Figure 9-22 shows that this test was successful.

Scanning for Disconnected Mailboxes

A connected mailbox requires that a mailbox object exists in the Exchange store and the corresponding user object exists and has Exchange properties in AD DS. A disconnected mailbox is a mailbox object in the Exchange store that is not connected to a user object in Active Directory. You can use the Disable-Mailbox EMS cmdlet to disconnect a mailbox and the Connect-Mailbox cmdlet to reconnect a disconnected mailbox to an AD DS user account. You can use the Remove-Mailbox cmdlet to disconnect a mailbox and remove the user object from AD DS. Using the Remove-Mailbox cmdlet permanently removes the mailbox object from the Exchange store.

Under normal circumstances, a mailbox is marked as disconnected immediately after the Disable-Mailbox or Remove-Mailbox command completes. However, if you use the Disable-Mailbox cmdlet or the Remove-Mailbox cmdlet while the Microsoft Exchange Information Store service is stopped or if a mailbox is disabled by external means other than the Disable-Mailbox cmdlet or the Remove-Mailbox cmdlet, it is possible that the disconnected mailbox is not marked as disconnected in AD DS, and this can lead to problems if email messages are sent to the user.

In this situation, you can use the Clean-MailboxDatabase EMS cmdlet to scan a mailbox database for disconnected mailboxes that have not been marked as disconnected within AD DS. Commands based on this cmdlet also update the status of those mailboxes so that they are correctly marked as disconnected.

For example, the following command scans the database Mailbox Database 1363123687 for disconnected mailboxes that are not marked as disconnected within AD DS and updates their status so that they are correctly marked as disconnected:

Clean-MailboxDatabase -Identity "Mailbox Database 1363123687"

Lesson Summary

• The EMS is the primary tool for configuring message tracking and tracking logs. You can use the EMC to perform some tasks, but its functionality is limited.

• You can use Queue Viewer in the EMC to monitor or EMS commands to monitor, filter, and manage transport queues on a Hub Transport or Edge Transport server.

• You can use Queue Viewer in the EMC to filter messages but the primary tool for managing messages and testing mail flow is the EMS.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 2, “Monitoring Mail Flow.” The questions are also available on the companion CD if you prefer to review them in electronic form.

1. You want to enable message tracking on the Mailbox server AdatumMail02. What EMS command do you use?

   1. Set-TransportServer –Identity AdatumMail02 -MessageTrackingLogEnabled:$false

   2. Set-MailboxServer –Identity AdatumMail02 -MessageTrackingLogEnabled:$false

   3. Set-TransportServer –Identity AdatumMail02 -MessageTrackingLogEnabled:$true

   4. Set-MailboxServer –Identity AdatumMail02 -MessageTrackingLogEnabled:$true

2. You want to change the maximum size of each message tracking log file on the Edge Transport server NY-Edge01 to 15 MB. What command do you enter in the EMS?

   1. Set-TransportServer –Identity NY-Edge01 -MessageTrackingLogMaxDirectorySize 15MB

   2. Set-TransportServer –Identity NY-Edge01 -MessageTrackingLogMaxFileSize 15MB

   3. Set-MailboxServer –Identity NY-Edge01 -MessageTrackingLogMaxDirectorySize 15MB

   4. Set-MailboxServer –Identity NY-Edge01 -MessageTrackingLogMaxFileSize 15MB

3. You want to display the number of messages in queues on an Edge Transport server in the Contoso.com domain that are bound for the BlueSkyAirlines.com domain. What command do you enter in the EMS?

   1. Get-Queue –Filter {NextHopDomain –eq “blueskyairlines.com”}

   2. Get-Queue -Filter {MessageCount -gt 50}

   3. Get-Queue –Filter {NextHopDomain –eq “adatum.com”}

   4. Get-Queue -Filter {MessageCount -ge 50}

4. You want to suspend all queues on a Hub Transport server that have a message count equal to or greater than 450 and have a status of Retry. The command should work immediately without requiring confirmation. What EMS command do you enter on the server?

   1. Suspend-Queue -Filter {MessageCount -ge 450 -and Status -eq “Retry”}

   2. Suspend-Queue -Filter {MessageCount -gt 450 -and Status -eq “Retry”} -Confirm:$False

   3. Suspend-Queue -Filter {MessageCount -ge 450 -and Status -eq “Active”} -Confirm:$False

   4. Suspend-Queue -Filter {MessageCount -ge 450 -and Status -eq “Retry”} -Confirm:$False

5. You want to test the message flow from the Mailbox server NY-EX1 to the Mailbox server NY-EX2. What command do you enter in the EMS?

   1. Test-Mailflow NY-EX1 -TargetMailboxServer NY-EX2

   2. Test-Mailflow NY-EX2 -TargetMailboxServer NY-EX1

   3. Test-Mailflow NY-EX1 -TargetDatabase NY-EX2

   4. Test-Mailflow NY-EX1 -TargetEmailAddress NY-EX2