By default, all Edge Transport and Mailbox servers perform message tracking. You can enable or disable message tracking on a per-server basis by setting the –MessageTrackingLogEnabled parameter of the Set-TransportService cmdlet to $true or $false, as appropriate. The following example disables message tracking on MailServer34:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogEnabled $false

Each Edge Transport and Mailbox server in your organization can have different message tracking settings that control the following:

By default, message tracking logs are stored in the %ExchangeInstallPath%TransportRolesLogsMessageTracking directory. Generally, message tracking does not have high enough input/output activity to warrant a dedicated disk. However, in some high usage situations, you might want to move the tracking logs to a separate disk. Before you do this, however, you should create the directory you want to use and set the following required permissions:

After you’ve created the directory and set the required permissions, you can change the location of the tracking logs to any local directory by setting the –MessageTrackingLogPath parameter of the Set-TransportService cmdlet to the desired local directory. The following example sets the message tracking directory as G:Tracking on MailServer34:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogPath "G:Tracking"

By default, all Edge Transport and Mailbox servers perform extended message tracking, which allows you to perform searches based on message subject lines, header information, sender, and recipient. If you don’t want to collect information on potentially sensitive subject lines, you can disable subject line tracking by setting the –MessageTrackingLogSubjectLoggingEnabled parameter of the Set-Transport-Service cmdlet to $false, as shown in the following example:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogSubjectLoggingEnabled $false

Exchange Server continues to write to message tracking logs until a log grows to a specified maximum size, at which point Exchange Server creates a new log and then uses this log to track current messages. By default, the maximum log file size is 10 megabytes (MB). You can change this behavior by setting the –MessageTrackingLogMaxFileSize parameter to the desired maximum file size. You must qualify the desired file size by using B for bytes, KB for kilobytes, MB for megabytes, or GB for gigabytes. The following example sets the message log file size to 50 MB:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogMaxFileSize "50MB"

Exchange Server overwrites the oldest message tracking logs automatically when tracking logs reach a maximum age or when the maximum log directory size is reached. By default, the maximum age is 30 days and the maximum log directory size is 1,000 MB. You can use the –MessageTrackingLogMaxAge parameter to set the maximum allowed age in the following format:

DD.HH:MM:SS

DD is the number of days, HH is the number of hours, MM is the number of minutes, and SS is the number of seconds. The following example sets the maximum age for logs to 90 days:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogMaxAge "90.00:00:00"

You can set the maximum log directory size by using the –MessageTrackingLogMaxDirectorySize parameter. As with the maximum log file size, the qualifiers are B, KB, MB, and GB. The following example sets the maximum log directory size to 2 GB:

Set-TransportService -Identity "MailServer34"
 -MessageTrackingLogMaxDirectorySize "2GB"

The tracking logs are useful in troubleshooting problems with routing and delivery. In the Exchange Management Shell, you use Get-MessageTrackingLog to search through the message tracking logs. The related syntax is:

Get-MessageTrackingLog [-Start DateTime] [-Server ServerId]
[-End DateTime] {AddtlParams}
{AddtlParams}
[-DomainController DCName] [-EventId {"BadMail" | "Defer" | "Deliver" |
"DSN" | "Expand" | "Fail" | "PoisonMessage" | "Receive" | "Redirect" |
"Resolve" | "Send" | "Submit" | "Transfer"} ] [-InternalMessageId
MessageTrackingLogId] [-MessageId MessageId] [-MessageSubject
Subject] [-Recipients SMTPEmailAddress1, SMTPEmailAddress2,...]
[-Reference ReferenceField] [-ResultSize NumEntriesToReturn]
[-Sender SMTPEmailAddress]

These parameters allow you to search the message tracking logs in the following ways:

To begin a search, you must specify one or more of the previously listed identifiers as the search criteria. You must also identify a server in the organization that has processed the message in some way. This server can be the sender’s server, the recipient’s server, or a server that relayed the message.

You set the search criteria by using the following parameters:

Using the –Start and –End parameters, you can search for messages from a starting date and time to an ending date and time. Using the –Server parameter, you specify the server to search. Consider the following example:

Get-MessageTrackingLog -Start "05/25/2014 5:30AM" –End "05/30/2014 7:30PM"
-Server MailServer18 –Sender [email protected]

In this example, you search for a messages sent by [email protected] between 5:30 A.M. May 25, 2014 and 7:30 P.M. May 30, 2014.

Exchange Server creates message tracking logs daily and stores them by default in the %ExchangeInstallPath%TransportRolesLogsMessageTracking directory. For US-English, each log file is named by the date on which it was created, using one of the following formats:

The message tracking logs store each message event on a single line. The information on a particular line is organized by comma-separated fields. Logs begin with a header that shows the following information:

Table 8-1 summarizes message event fields and their meaning. Not all of the fields are tracked for all message events.

You can view the message tracking log files with any standard text editor, such as Microsoft Notepad. You can also import the message tracking log files into a spreadsheet or a database. Follow these steps to import a message tracking log file into Microsoft Excel:

As part of message tracking, you can create delivery reports in Exchange Admin Center. Delivery reports allow you to search for the delivery status of messages sent to or from user’s in your organization. In delivery reports, messages are listed by sender, recipients, and date and time sent. If subject line tracking is enabled, the subject line of messages is also included in reports.

You can track messages for up to 14 days after they were sent or received by completing the following steps:

By default, protocol logging isn’t enabled on custom connectors. As long as you know the identity of the custom connector with which you want to work, you can configure protocol logging for a specified connector. To retrieve a list of available Send and Receive connectors for a server, use the Get-SendConnector and Get-ReceiveConnector cmdlets, respectively. If you run either cmdlet without specifying additional parameters, a list of all available Send or Receive connectors is returned.

You enable or disable protocol logging on a per-connector basis. For Send connectors, you use the Set-SendConnector cmdlet to enable protocol logging. For Receive connectors, you use the Set-ReceiveConnector cmdlet to enable protocol logging. Both cmdlets have a –ProtocolLoggingLevel parameter that you can set to Verbose to enable protocol logging or to None to disable protocol logging. Here is an example:

Set-ReceiveConnector -Identity "Corpsvr127Custom Receive Connector"
-ProtocolLoggingLevel 'Verbose'

In the Transport service on every Mailbox server and in the Front End Transport service on every Client Access server is an implicitly created Send connector, referred to as the intra-organization Send connector. The Transport service on Mailbox servers uses the intra-organization Send connector to relay messages to other Transport servers in the Exchange organization. By default, the Transport service on Mailbox servers doesn’t perform protocol logging on the intra-organization Send connector. You enable or disable protocol logging for this Send connector on a Mailbox server by using the -MailboxDeliveryConnectorProtocolLoggingLevel parameter of the Set-MailboxTransportService cmdlet. Use Verbose to enable protocol logging or to None to disable protocol logging. Here is an example:

Set-MailboxTransportService -Identity MailServer18
-MailboxDeliveryConnectorProtocolLoggingLevel 'Verbose'

The Frontend Transport service uses the intra-organization Send connector to relay messages to the Transport service on Exchange 2013 Mailbox servers. By default, the Front End Transport service on Client Access servers performs protocol logging on the intra-organization Send connector. You enable or disable protocol logging for this Send connector on a Client Access server by using the -IntraOrgConnectorProtocolLoggingLevel parameter of the Set-FrontEndTransportService cmdlet. Use Verbose to enable protocol logging or set to None to disable protocol logging. Here is an example:

Set-FrontEndTransportService -Identity CAServer26
-IntraOrgConnectorProtocolLoggingLevel 'Verbose'

Although you enable protocol logging on a per-connector basis, you configure the other protocol logging parameters on a per-server basis for either all Send connectors or all Receive connectors by using the Set-TransportService cmdlet. As it does with message tracking logs, Exchange Server overwrites the oldest protocol logs automatically when tracking logs reach a maximum age or when the maximum log directory size is reached. If you decide to move the protocol log directories, you should create the directories you want to use and then set the following required permissions:

Because the parameters are similar to those for message tracking, I’ll summarize the available parameters. Table 8-2 shows the Send connector parameters for configuring protocol logging. Table 8-2 shows the Receive connector parameters for configuring protocol logging. In the default path for logs, the ServerType can be FrontEnd, Mailbox, or Hub. Under FrontEndProtocolLogs, you’ll find logs for the Front End Transport service on Client Access servers. Under HubProtocolLogs, you’ll find logs for the Transport service on Mailbox servers. Under MailboxProtocolLogs, you’ll find logs for the Mailbox Transport service on Mailbox servers.

When protocol logging is enabled, a Mailbox server or a transport server creates protocol logs daily. Mailbox and transport servers store logs in either the %Exchange-InstallPath%TransportRolesLogsServerTypeProtocolLogSmtpSend or %Exchange-InstallPath%TransportRolesLogsServerTypeProtocolLogSmtpReceive directory as appropriate for the type of server and connector being logged. For POP, IMAP, and other non-SMTP content aggregation, related logs are in the %ExchangeInstallPath%TransportRolesLogsProtocolLogHTTPClient directory. Each log file is named by the date on which it was created, using the format SENDYYYYMMDD-N.log or RECVYYYYMMDD-N.log, such as SEND20140605-1.log for the first Send connector log created on June 5, 2014. Additional protocol logs are found in subdirectories of the %ExchangeInstallPath%Logging directory. In the AddressBook Service subdirectory, you’ll find logs for the Address Book service. In the RPC Client Access subdirectory, you’ll find logs for Remote Procedure Calls for Client Access services.

The protocol log stores each SMTP protocol event on a single line. The information on a particular line is organized by comma-separated fields. Logs begin with a header that shows the following information:

Table 8-4 summarizes SMTP event fields and their meanings. Not all of the fields are tracked for all protocol events. You can view the protocol log files with any standard text editor, such as Notepad. You can also import the protocol log files into a spreadsheet or a database.

Client Access servers have web-based applications and virtual directories that use Microsoft Internet Information Services (IIS) to provide the related services. In IIS 7.0 and later, protocol logging for HTTP is a feature available when the HTTP Logging module is installed and logging is enabled. By default, this module is installed with IIS and enabled. The default configuration is to use one log file per website per day.

You can view and manage the logging settings by completing the following steps:

On Client Access servers, HTTP protocol log files can help you detect and trace problems with HTTP, Outlook Web App, Microsoft Exchange ActiveSync, and Outlook Anywhere. By default, Exchange Server writes protocol log files to a subdirectory of %SystemDrive%inetpublogsLogFiles. You can use the logs to determine the following:

Most protocol log files are written as ASCII text. This means you can view them in Notepad or another text editor. You can import these protocol log files into Excel in much the same way as you import tracking logs.

Log files, written as space-delimited or tab-delimited text, begin with a header that shows the following information:

The name of the subdirectory used for logging depends on the number of websites hosted on a server. Typically, when a server has either the Client Access role or the Mailbox role, the subdirectory name is W3SVC1, which identifies the website as the first created for IIS. When a server has the Client Access role and the Mailbox role, the W3SVC1 subdirectory typically is used for front-end logging and the W3SVC2 subdirectory is used for back-end logging. As discussed in Chapter 9, you also can use Log Parser Studio to work with HTTP protocol logs.

Servers can have additional websites or may not have websites created in the expected order, such as when you deploy a Mailbox server and then later add the Client Access role to this server. In this case, you’ll want to confirm the identity of the logging subdirectory by using the following command:

Get-OwaVirtualDirectory -Server ServerID -ShowMailboxVirtualDirectories
|fl identity, metabasepath

ServerID is the host name or fully-qualified domain name of the Exchange server to check, such as:

Get-OwaVirtualDirectory -Server MailServer21 -ShowMailboxVirtualDirectories
|fl identity, metabasepath

The output will show the website identity and metabase path for the Outlook Web App (OWA) virtual directories created on the server. If the server has front-end and back-end virtual directories for OWA, the output will be similar to the following:

Identity     : MAILSERVER21owa (Exchange Back End)
MetabasePath : IIS://MAILSERVER21.pocket-consultant.com/W3SVC/2/ROOT/owa
Identity     : MAILSERVER21owa (Default Web Site)
MetabasePath : IIS://MAILSERVER21.pocket-consultant.com/W3SVC/1/ROOT/owa

In the output, note that the name of the associated website is shown in parenthesis as part of the identity and the subdirectory path can be extrapolated from the metabase path. Here, the back-end virtual directory is named Exchange Back End and has the associated subdirectory W3SVC2 (which is shown as W3SVC/2 in the metabase path). The front-end virtual directory is named Default Web Site and has the associated subdirectory W3SVC1 (which is shown as W3SVC/1 in the metabase path).

By default, Exchange Server performs connectivity logging. Exchange Server creates connectivity logs when clients connect to the Front End Transport service on Client Access servers and when clients are proxied or redirected to the Transport service on Mailbox servers. Exchange Server also creates connectivity logs for communications with the mailbox databases on a Mailbox server. Generally, Exchange Server creates connectivity logs to track:

You manage connectivity logging for the Front End Transport service by using Set-FrontEndTransportService, the Transport service by using Set-TransportService, and the Mailbox Transport service by using Set-MailboxTransportService. With any of these cmdlets, you can enable or disable connectivity logging for the service by setting the –ConnectivityLogEnabled parameter to $true or $false, as appropriate. The following example disables connectivity logging for the Transport service on MailServer34:

Set-TransportService -Identity "MailServer34"
-ConnectivityLogEnabled $false

The Front End Transport service, the Transport service, and the Mailbox Transport service can have different connectivity logging settings:

As it does with other logs, Exchange Server overwrites the oldest connectivity logs automatically when tracking logs reach a maximum age or when the maximum log directory size is reached. If you decide to move the protocol log directories, you should create the directories you want to use and set the following required permissions:

Exchange Server creates connectivity logs daily and stores them in the %Exchange-InstallPath%TransportRolesLogsServerTypeConnectivity directory. In the default path for logs, the ServerType can be FrontEnd, Mailbox, or Hub. Under FrontEndConnectivity, you’ll find logs for the Front End Transport service on Client Access servers. Under HubConnectivity, you’ll find logs for the Transport service on Mailbox servers. Under MailboxConnectivity, you’ll find a Submission subdirectory containing logs for the Mailbox Transport Submission service on Mailbox servers, and a Delivery subdirectory containing logs for the Mailbox Transport Delivery service on Mailbox servers.

Each log file is named by the date on which it was created, using the format CONNECTLOGYYYYMMDD-N.log, such as CONNECTLOG20140521-1.log for the first connectivity log created on May 21, 2014. The connectivity log stores outgoing queue connection events on a single line. The information on a particular line is organized by comma-separated fields. Logs begin with a header that shows the following information:

Table 8-5 summarizes connectivity logging fields and their meanings. Not all of the fields are tracked for all outgoing queue connection events. You can view the connectivity log files with any standard text editor, such as Notepad. You can also import the connectivity log files into a spreadsheet or a database, as discussed previously.

Physical and virtual memory is critical to normal system operation. When a server runs low on memory, system performance can suffer and message processing can grind to a halt. To counter this problem, you should configure performance alerting to watch memory usage. You could then increase the amount of virtual memory available on the server or add more random access memory (RAM) as needed. However, keep in mind that increasing virtual memory isn’t something you should do without careful planning. For detailed guidance on tuning virtual memory, see Chapter 10, “Performance Monitoring and Tuning,” in Windows Server 2012 Inside Out (Microsoft Press, 2012).

You configure a memory alert by completing the following steps:

To manage an alert, select the User Defined node in the left pane, press and hold or right-click the alert in the main pane, and then select one of the following options:

You can use a CPU utilization alert to track the usage of a server’s CPUs. When CPU use is too high, Exchange Server can’t effectively process messages or manage other critical functions. As a result, performance can suffer greatly. For example, CPU utilization at 100 percent for an extended period of time can be an indicator of serious problems on a server. To recover, you might need to use Task Manager to end the process or processes with high CPU use, or you might need to take other corrective actions to resolve the problem, such as closing applications you are running while logged on to the server.

You’ll also want to closely track process threads that are waiting to execute. A relatively high number of waiting threads can be an indicator that a server’s processors need to be upgraded.

You configure a CPU utilization alert by completing the following steps:

Exchange Server uses disk space for data storage, logging, tracking, and virtual memory. To ensure ample disk space is always available, Exchange Server monitors free disk space. If free disk space drops below specific thresholds, Exchange will gracefully shut itself down. When Exchange is in this state, it is likely that data could get lost. To prevent serious problems, you should monitor free disk space closely on all drives used by Exchange Server.

You’ll also want to track closely the number of system requests that are waiting for disk access. A relatively high value for a particular disk can affect server performance and is also a good indicator that a disk is being overutilized or that there may be some problem with the disk. To resolve this problem, you’ll want to try to shift part of the disk’s workload to other disks, such as by moving databases, logs, or both.

You configure disk usage alerting by completing the following steps: