Showing posts with label Message Tracking. Show all posts
Showing posts with label Message Tracking. Show all posts

Friday, December 15, 2017

Search-MessageTrackingReport Error: You aren't authorized to perform the search

We can use the Search-MessageTrackingReport cmdlet to retrieve the message tracking report for a particular email. With this report ID, we can then pass it on to the Get-MessageTrackingReport cmdlet to get the full tracking information for that email.
However, if you are not used to these cmdlets, you might come across the following error when running your search:
Search-MessageTrackingReport nuno.mota@domain.com -Recipients jonathan.sinasac@domain.com

You aren't authorized to perform the search. You need to have permissions to search for the sender of the message or for every recipient specified.


This is because, by default, users can only track messages that they send or receive from their own mailbox. To overcome this error, simply use the BypassDelegateChecking switch which allows us to track messages for any user.

Wednesday, May 4, 2016

Determine Client Used to Send Email

Just recently someone asked me if there was a way to determine which email client (Outlook, OWA or ActiveSync) was used to send a particular email. On top of that, this person was also interested is finding out how many emails are sent per day using each of these clients.

The good news is that the Message Tracking Logs register this information. Every email sent has a SourceContext property which contains, amongst other information, the ClientType used to send the email. The important thing is to check this property for SUBMIT events, i.e., when the Mailbox Transport Submission service successfully transmits the email to the Transport service.

For SUBMIT events, the SourceContext property contains the following details:
  • MDB: the mailbox database GUID;
  • Mailbox: the mailbox GUID;
  • Event: the event sequence number;
  • MessageClass: the type of message. For example, IPM.Note;
  • CreationTime: date and time of the message submission;
  • ClientType: for example OWA or ActiveSync.


Please note that this only applies to emails sent by internal users. There is no SUBMIT event when an external sender sends an email to an internal user, meaning there is no ClientType property for these emails. In these cases, the only information we have regarding the sender is what the email headers contain, which does not include email client information.

To check what email client was used to send a particular email, we can run something like the following cmdlet and look at the SourceContext field:
Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT -Sender nuno@nunomota.pt -MessageSubject Test | Select SourceContext

This field will contain information like the following:
MDB:34f3dc86-91bb-4ee7-a6a5-3d3ddc536050, Mailbox:a1de664f-9826-43a3-b9c8-3db019c86d8b, Event:29647741, MessageClass:IPM.Note, CreationTime:2016-05-11T07:17:14.922Z, ClientType:MOMT

In this case, MOMT stands for MAPI on the Middle Tier, basically clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP.

To count the number of emails sent using OWA today, we can run something like this:
(Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT | Where {$_.SourceContext -match "OWA"}).Count

Easy as that! :)

Saturday, February 20, 2016

Distribution Groups Statistics

As an Exchange Administrator, have you ever wondered if all those Distribution Groups are actually being used? Organizations running Microsoft Exchange Server are likely to have been running Exchange for a at least a few years and also likely to continue to do so for a while. After all those years, more and more distribution groups get created, some of them stop being used, some are simply forgotten, etc.

Maybe you got asked by the Audit department or by your manager for a list of the 20 most utilized groups, or maybe you are just curious. The good news is that as long as you have Message Tracking Logs enabled, you can easily get this information!

The easiest way to track messages sent to distribution groups is to list all the expansion events. When a user sends an email to a group, Exchange needs to expand that group in order to know who to send the email to. This gets registered with an EventID of EXPAND. Additionally, the RelatedRecipientAddress field in the EXPAND entry contains the PrimarySmtpAddress of the expanded group. And this is pretty much all the information we need.

Using the following cmdlet, we can get a list of all the emails sent to distribution groups on the 1st of January 2016:
Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Select Timestamp, RelatedRecipientAddress, MessageSubject

But what we really want is to know how many emails were sent to which groups during a particular time. Not a problem! All we need to do is tweak the cmdlet above and add Group-Object:
Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count –Descending | Select Count, Name



Do not forget to add Get-TransportService (or Get-TransportServer in Exchange 2007 and 2010) to get the logs across all transport servers if you have more than one!

If you are interested in getting the Top 20 most used groups, for example, this is also very easy:
Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 01/01/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count -Descending | Select -First 20 | FT Count, Name -AutoSize

Exchange Message Queue RiskLevel

When using the Get-Queue cmdlet to view configuration information for queues on Exchange servers, several properties are available for each queue such as DeliveryType, NextHopDomain, Status, MessageCount, LastError, Velocity, RetryCount, and many, many more.

Some of these properties have already been discussed in MSExchange.org articles and/or tips such as Exchange 2013 Queue Velocity. Another interesting one is RiskLevel:

So what is this Risk Level property? Well, according to the Queue filters TechNet article, “this property is reserved for internal Microsoft use, and isn't used in on-premises Exchange 2013 organizations.” As such, I am assuming on-premises customers do not need to worry about this. But just for information, according to the MSDN RiskLevel enumeration webpage, this property has four possible values:
  • Normal: The associated message is normal risk.
  • Bulk: The associated message is part of a bulk mailing.
  • High: The associated message is high risk.
  • Low: The associated message is low risk.

Tuesday, October 27, 2015

Message Tracking Logs Missing

The other day someone asked me for help regarding Message Tracking Logs missing. The problem was that the person had the message tracking logs configured to save 60 days’ worth of data but he could not find a particular email that was supposedly delivered before those 60 days.
 
The first step was to verify that 60 days of logs were actually being saved:
Get-TransportService | Select MessageTrackingLogMax*
MessageTrackingLogMaxAge:           60 Days
MessageTrackingLogMaxDirectorySize: 1000 MB
MessageTrackingLogMaxFileSize:      10MB

Going to the location where the logs are saved (by default %ExchangeInstallPath%TransportRoles\Logs\MessageTracking), there were indeed 60 days’ worth of logs, so why couldn’t we find the email?! Also, the overall folder size was over 1GB in size... But how can that be if we specified to only use 1000MB?! Let us go back a bit first...
 
The naming convention for message tracking log files in Exchange 2013 is MSGTRKyyyymmdd-nnnn.log, MSGTRKMAyyyymmdd-nnnn.log, MSGTRKMDyyyymmdd-nnnn.log and MSGTRKMSyyyymmdd-nnnn.log . The different logs are used by the following services:
  • MSGTRK: these logs are associated with the Transport service;
  • MSGTRKMA: these logs are associated with the approvals and rejections used by moderated transport;
  • MSGTRKMD: these logs are associated with messages delivered to mailboxes by the Mailbox Transport Delivery service;
  • MSGTRKMS: these logs are associated with messages sent from mailboxes by the Mailbox Transport Submission service.
 
The placeholders in the log file names represent the following information:
  • The placeholder yyyymmdd is the coordinated universal time (UTC) date on which the log file was created. Yyyy = year, mm = month and dd = day;
  • The placeholder nnnn is an instance number that starts at the value of 1 daily for each message tracking log file name prefix.
 
Information is written to each log file until the file size reaches its maximum specified value (MessageTrackingLogMaxFileSize) for each log file. Then, a new log file that has an incremented instance number is opened. This process is repeated throughout the day. The log file rotation functionality deletes the oldest log files when either of the following conditions is true:
  • A log file reaches its maximum specified age;
  • The message tracking log directory reaches its maximum specified size.
 
Now here comes the important part! The maximum size of the message tracking log directory is calculated as the total size of all log files that have the same name prefix. Other files that do not follow the name prefix convention are not counted in the total directory size calculation.
On Exchange 2013 Mailbox servers, the maximum size of the message tracking log directory is three times the specified value. Although the message tracking log files that are generated by the four different services have four different name prefixes, the amount and frequency of data written to the MSGTRKMA log files is negligible compared to the three other log file prefixes.
 
Going back to the initial issue, the problem was that there were less than 60 days’ worth of MSGTRKMD logs as the combined log files size has met the 1000 MB limit...
So, the bottom line is that, as with Exchange 2010, if you want to keep X amount of days of message tracking logs, ensure you set MessageTrackingLogMaxDirectorySize to a high enough value.

Thursday, May 15, 2014

Message Trace Extended for 90 Days in Exchange Online

The lack of Message Tracking Logs in Exchange Online has been a concern for some organizations in their adoption of Office 365. Although Message Trace provided a good source of data for investigations, it was limited to the last 7 days of e-mail traffic, meaning administrators would have to frequently extract this data so it could be used later if needed.
 
Not anymore! Exchange Online Protection (EOP) and Exchange Online administrators can now check message trace information for the last 90 days.
 
To access this feature, in the Exchange admin center, click Mail flow and then click on Message trace. When we search for a message sent in the past seven days, we can view the results immediately. However, when searching for older messages, we have to submit a request for an extended message trace. To do this, simply choose the custom date range option and specify any date range in the past 90 days:
 
 
When we create a new extended trace request, we opt to receive an e-mail notification when the trace has been completed by entering an e-mail address in the Notification email address field:
 
 
 We can also choose to receive a summary list report or a detailed message trace report:
  • Summary list report displays basic information about the messages traced, such as time, whether it was delivered, its subject, number of bytes, and so on;
  • Detailed message trace report provides more details about messages than the summary list. To get a detailed report, when creating a new trace request, select the Include message events and routing details with report check box. In a detailed trace, all key events with all details that are available in the message tracking logs are exposed, providing an excellent data source for detailed investigations.
 
Typically, trace requests are processed within hours. The list of submitted requests and their status is displayed on the pending or completed traces page in the Exchange admin center (by clicking on View pending or completed traces under message trace) making it easy to check if a request has been completed:
 
 
Once a message trace request has completed processing, you can click Download this report in the right-hand side to view the results in a downloadable CSV file.

Tuesday, January 7, 2014

Message Tracking Report

New to Exchange 2013, the Get-MessageTrackingReport cmdlet is used to return data for a specific message tracking report.
 
This cmdlet, used by the delivery reports feature, requires you to specify the ID for the message tracking report you want to view. Therefore, first you need to use the Search-MessageTrackingReport cmdlet to find the message tracking report ID for a specific message. You then pass the report ID to the Get-MessageTrackingReport cmdlet.
 
Note that you need to be assigned permissions before you can run this cmdlet. You will not have access to some of its parameters if the account used is not a member of one of the following groups: Organization Management, Records Management or Recipient Management.
 
 
This first example gets the message tracking report for messages sent from one user to another and returns the summary of the message tracking report for a message that Alice Jones sent to John Richardson:
$Temp = Search-MessageTrackingReport “Alice Jones” -Recipients “johnr@letsexchange.com”
Get-MessageTrackingReport $Temp.MessageTrackingReportID -ReportTemplate Summary
  • The ReportTemplate parameter specifies a predefined format for the output. You can either return a summary for all recipients or a detailed tracking report for one recipient using one of the following values: RecipientPath or Summary.
 
 
The second example gets the message tracking report for the following scenario: a user named Nuno Mota was expecting an e-mail message from joe@domain.com that never arrived. He contacted the Help Desk, which generated a message tracking report on behalf of Nuno returning detailed troubleshooting information for the specific recipient path:
Search-MessageTrackingReport “Nuno Mota” -Sender “joe@letsexchange.com” -ByPassDelegateChecking -DoNotResolve | ForEach {Get-MessageTrackingReport $_.MessageTrackingReportID -DetailLevel Verbose -BypassDelegateChecking -DoNotResolve -RecipientPathFilter "nunom@domain.com" -ReportTemplate RecipientPath}
  • The BypassDelegateChecking switch allows Help Desk staff and administrators to retrieve message tracking reports for any user. By default, each user can only see the message tracking reports for messages sent or received by the user. When using this switch, Exchange allows administrators to view message tracking reports for messages exchanged among other users.
  • The DoNotResolve switch prevents the resolution of e-mail addresses to display names. This improves performance, but the end result may not be as easy to interpret because it is missing the display names.
  • The DetailLevel parameter specifies the amount of detail to be displayed for the message tracking report. You can use one of the following values: Basic or Verbose. If you specify Basic, simple delivery report information is displayed, which is more appropriate for information workers. If you specify Verbose, full report information is displayed, including server names and physical topology information.
  • The RecipientPathFilter parameter specifies the recipient for which the command returns the detailed tracking report. This parameter is used when using the RecipientPath report template.

Sunday, January 20, 2013

E-mail Recipient Number Distribution

Have you ever wondered what the distribution of the number of recipients per e-mail in your organization is?
 
The following script will go through every e-mail received by Exchange and group the results by the number of recipients.
Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -EventID RECEIVE -Start "07/05/2012 16:40" | ? {$_.Source -eq "STOREDRIVER"} | Select RecipientCount | Group RecipientCount | Select @{Name="Recipients"; Expression={[Int] $_.Name}}, Count | Sort Recipients

Alternatively, you can group them in batches depending on which format you want the output.
[Int] $1 = $2 = $5 = $10 = $30 = $50 = $75 = $100 = $150 = $200 = $250 = $big = 0

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -EventID RECEIVE -Start "07/05/2012" | ? {$_.Source -eq "STOREDRIVER"} | Select RecipientCount | ForEach {
    If ($_.RecipientCount -eq 1) { $1++ }
    If ($_.RecipientCount -eq 2) { $2++ }
    If ($_.RecipientCount -gt 2   -and $_.RecipientCount -le 5)    { $5++ }
    If ($_.RecipientCount -gt 5   -and $_.RecipientCount -le 10)   { $10++ }
    If ($_.RecipientCount -gt 10  -and $_.RecipientCount -le 30)   { $30++ }
    If ($_.RecipientCount -gt 30  -and $_.RecipientCount -le 50)   { $50++ }
    If ($_.RecipientCount -gt 50  -and $_.RecipientCount -le 75)   { $75++ }
    If ($_.RecipientCount -gt 75  -and $_.RecipientCount -le 100)  { $100++ }
    If ($_.RecipientCount -gt 100 -and $_.RecipientCount -le 150)  { $150++ }
    If ($_.RecipientCount -gt 150 -and $_.RecipientCount -le 200)  { $200++ }
    If ($_.RecipientCount -gt 200 -and $_.RecipientCount -le 250)  { $250++ }
    If ($_.RecipientCount -gt 250 -and $_.RecipientCount -le 300)  { $300++ }
    If ($_.RecipientCount -gt 300) { $big++ }
}

Write-Host "1,                     $1"
Write-Host "2,                     $2"
Write-Host "Between 3 and 5,       $5"
Write-Host "Between 6 and 10,      $10"
Write-Host "Between 11 and 30,     $30"
Write-Host "Between 31 and 50,     $50"
Write-Host "Between 51 and 75,     $75"
Write-Host "Between 76 and 100,    $100"
Write-Host "Between 101 and 150,   $150"
Write-Host "Between 151 and 200,   $200"
Write-Host "Between 201 and 250,   $250"
Write-Host "Between 251 and 300,   $300"
Write-Host "More than 300,         $big"

Sunday, April 22, 2012

Email Latency

If you want to find out the overall latency for e-mails flowing in your Exchange 2007 organization, you can use the MSGAnalyzer tool from Microsoft or you have to check when an e-mail first reached your servers, check when it was delivered to the recipient’s mailbox and then calculate the time difference.

The good news is that with Exchange 2010 this is much, much easier as this information is saved in the Message Tracking Logs. When a HUB server delivers a message (through the Store Driver) it generates a DELIVER event which contains the TimeStamp of when the message was delivered (as with Exchange 2007) but now it also includes the MessageLatency which is the difference between the original arrival time of the message and this timestamp.

So, if you want to check the latency for all the e-mails arriving in your organization, simply use the a cmdlet similar to the following one:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "03/26/2012" -EventID DELIVER | FT MessageLatency

Which will give you a TimeSpan value like “00:00:03.8130000” which means the e-mail took almost 4 seconds to be delivered.

If you are just interested in a particular day and also want to know which HUB server delivered it each message:
Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "03/26/2012" -End "03/27/2012" -EventID DELIVER | Select TimeStamp, ClientHostname, @{Label="LatencyMil"; Expression={$($_.MessageLatency).TotalMilliseconds}} | Export-Csv Latency_20120326.csv -NoTypeInformation

Note that this time we are printing the TotalMilliseconds it took to deliver each message which makes it easier to calculate the average for the day in Excel.

Friday, April 17, 2009

Message Tracking Log Path

Here is a problem I faced today: when trying to move all the tracking logs for 3 CAS boxes from the C to the D drive I used the command:


Get-TransportServer Set-TransportServer -MessageTrackingLogPath D:\LogFiles\MessageTracking


At the time, I didn’t know that if the folder doesn’t exist Exchange will automatically create it. So, I manually created them, copied all the logs to the new location (because existing logs will remain in their previous location and new ones will be created in the new location) and immediately ran the command. After a couple of minutes I checked the Date Modified for the last log on the new folder and that showed me that Exchange was using the new folder. Ok, it’s done! :)
Not exactly...

When I went to the Application Log on the Event Viewer, I saw a few of these errors there:


Event Type: Error
Event Source: MSExchange Common
Event Category: Logging
Event ID: 6004
Date: 16/04/2009
Time: 09:20:32
User: N/A
Computer: DS-EXCAS3
Description: MessageTrackingLogs: Failed to write logs because of the error: Access to the path 'MSGTRK20090317-1.LOG' is denied..



What?! That’s from one month ago!
Ok, let’s look at my current configuration:

MessageTrackingLogEnabled : True
MessageTrackingLogMaxAge : 30.00:00:00
MessageTrackingLogMaxDirectorySize : 2GB
MessageTrackingLogMaxFileSize : 20MB
MessageTrackingLogPath : D:\LogFiles\MessageTracking
MessageTrackingLogSubjectLoggingEnabled : True


Here’s the problem: as you can see, I have it so that Exchange only keeps 30 days of tracking logs. Since I manually created the new folders, I didn’t set up the correct permissions on them. So, Exchange couldn’t delete that log from one month ago! It was creating new ones and logging everything, but just couldn’t delete that one...

If you create the target folder for the logs automatically when running the command, Exchange will assign the correct permissions to the folder. But If you manually create it, make sure you give the following permissions to it:

NETWORK SERVICE: Modify, Read & Execute, List Folder Contents, Read and Write (also give it the Delete Subfolders and Files permission!)


Just out of curiosity, this is the command I used to configure the Message Tracking Logs for my CAS boxes:


Get-TransportServer Set-TransportServer -MessageTrackingLogEnabled $True -MessageTrackingLogPath “D:\LogFiles\MessageTracking” -MessageTrackingLogMaxAge “30.00:00:00” -MessageTrackingLogMaxDirectorySize 2GB -MessageTrackingLogMaxFileSize 20MB -MessageTrackingLogSubjectLoggingEnabled $True


Hope this helps!