PFEMessaging

Auditing Admin Activities - reporting purposes

Akshay Katti [MSFT] — Wed, 06 Jul 2016 14:04:20 GMT

In many organizations that I visit, they have multiple administrators. If in case something breaks anytime, not a lot of administrators have any clear information on what was changed, what object was modified, who did the change and when was the change done. This is not only applicable to customers who are on on-premises Exchange servers but also for the customers who are already on Exchange Online. So, I thought of writing a script to get these information. Although it just uses our age old (yeah, since Exchange 2010 days) method of searching Admin audit logs, it gives it in a clear format for both admin to consume and understand the changes in the environment from Exchange admin console or Exchange management shell. So that if they review it, there is a clear information of what was changed from the Exchange environment perspective. Use cases: Exchange Admin takes permissions over another mailbox or adds user to permissions on another mailbox (can be sendas permission or full mailbox permission). Exchange Admin makes a change with Exchange management shell/Exchange management Console/Exchange administration Center on a change in transport rule etc.

################################ Disclaimer ################################### <# This software (or sample code) is not supported under any Microsoft standard support program or service. The software is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the software and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the software be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the software or documentation, even if Microsoft has been advised of the possibility of such damages. #> # Version 1.0 ############################## Start of the script ################################# $smtp = "HTServer1.contoso.com" # This should be a Hub transport server in the environment. # $smtp has the server name which can be used as a server to connect from the script and submit the email. This can be either an Exchange server/IIS SMTP server/Any other third party servers. $from = "AdminAuditLogReport@domain.com" #This is just an email address that it shows up in the sender field - can be any email address. # $from has the name that needs to appear in the from field of the email. $users = "AuditManager@contoso.com"; # this can be any email address you would like to have. #$users = "Auditmanageruser1@contoso.com","Auditmanageruser2@contoso.com"; #You can add any other users also who would like to receive this alert email for Admin Audit logs $AdminAuditCount = 0 $Begin = $null $Begin = Get-Date $Start = $Begin.AddDays(-1) $end = $Begin $Filename = $null $Filename = ".\AdminAuditLogSearch_" + $Begin.Hour + $Begin.Minute + "_" + $Begin.Day + "-" + $Begin.Month + "-" + $Begin.Year + ".htm" $report = $null $report += "" $report += "" $report += "" $report += 'Admin Audit Log Search Report' $report += '" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "

" $report += "These were the Admin Audit logs on the Exchange Environment from $Start till $end " $report += "

" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $AdminAuditLog = Search-AdminAuditLog -StartDate $Start -EndDate $end | where{($_.cmdletname -notlike "New-Mailbox") -and ($_.cmdletname -notlike "enable-mailbox") -and ($_.cmdletname -notlike "Set-Mailbox") -and ($_.cmdletname -notlike "New-Mailcontact") -and ($_.cmdletname -notlike "Set-Mailcontact") -and ($_.CmdletName -notlike "Add-DistributionGroupMember") -and ($_.cmdletname -notlike "Remove-DistributionGroupMember") -and ($_.Cmdletname -notlike "Set-DistributionGroup") -and ($_.Cmdletname -notlike "New-DistributionGroup") -and ($_.Cmdletname -notlike "New-MoveRequest") -and ($_.CmdletName -notlike "New-MailboxExportRequest") -and ($_.CmdletName -notlike "New-MailboxImportRequest") -and ($_.CmdletName -notlike "Suspend-MoveRequest") -and ($_.CmdletName -notlike "Remove-MoveRequest") -and ($_.Cmdlet -notlike "Search-Mailbox")} # The above line has a lot of conditions that should not go in the report. The reason being - Admin Audit logs keeps track of any command which modifies an object on the Exchange server (Set, enable, add, remove, move, new etc.) # Having this all other information is too much junk every day. Only the major changes should be monitored. if ($AdminAuditLog -ne $null) { foreach ($Entry in $AdminAuditLog) { Write-Host $Entry.caller `t $Entry.cmdletname `t $Entry.ObjectModified `t $entry.Succeeded `t $entry.RunDate `t $entry.OriginatingServer -ForegroundColor GREEN $caller = $entry.caller $cmdlet = $entry.cmdletName $objmodified = $entry.objectmodified $success = $entry.succeeded $RunDate = $entry.RunDate $servername = $entry.originatingServer $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $report += "" $AdminAuditCount += 1 } } else { Write-Output "No Commands were run which modified any objects in AD from $start till $end." } $report += "

Admin Who Ran the command	Commandlet Run	Modified Object	Succeeded	Run Date	Server on which the commandlet was run
$caller	$cmdlet	$objmodified	$success	$RunDate	$Servername

" $report += "
" $report += "Note: This will Not Include any changes done on the Edge servers/Any modifications done in AD directly logging into AD servers(eg: using ADSIEDIT/DSA/Any AD tools)" $report += "" $report += "" Write-Output $AdminAuditCount if ($AdminAuditCount -ge 1) { foreach ($user in $users) { Send-MailMessage -BodyAsHTML $report -SmtpServer $smtp -From "$from" -To "$user" -subject "Administrator Audit Logs" # send emails to all the users which you had specified in the $users $report | out-file -encoding ASCII -filepath .\reports\AdminAuditLogs\$Filename # The above line saves a copy of the report in the location. So, there needs to be folder structure created for this. } } ############################## End of the script #################################

The above commandlet checks for admin activities in any environment - in terms of what changes were performed by the admin except the actions excluded above and sends an email to all the email addresses that is mentioned in the $users. Admin audit logs are saved for a period of 90 days by default - customizable in on-premises Exchange server. Hope this helps a few of the admins out there who want to know what all changes were done in terms of Exchange environment in a specific duration.

Figuring out which client was used by the sender to send an email

Akshay Katti [MSFT] — Wed, 06 Jul 2016 13:21:14 GMT

I have had several customer requests in the past who wanted to figure out what client was used to send an email from a specific mailbox in their Exchange environment (eg: want to figureout whether OWA/Outlook/ActiveSync/EWS etc. was used to send an email) The simplest and the easiest way is to look through your Message Tracking logs. In Exchange 2010, we introduced this field in the message tracking logs called as original client IP address. This captures the machine IP that was used to send an email. This does not show up in your Get-MessagetrackingLogs commandlet by default on Exchange 2010. So, you will have to manually get into the message tracking log file (based on the time the email was sent) from the mailbox server and look for the message ID for the email being sent. The message ID is something that could be found from both your Get-MessageTrackingLog as well as the message header from the recipients mailbox. In the above screenshot of an email sent from one of the user using Outlook when you run the commandlet Get-MessageTrackingLog using EventType as Submit, we see that it did mention that the client used was MOMT (look at the SourceContext field). ClientType:MOMT Here are the various Client Types and their meaning. MOMT - expands to Messsaging On Middle Tier (means Outlook client). If you are using OWA to send an email, you would notice ClientType as OWA Now that we know what type of client is being used, how do we know what was the IP address from which the email was submitted? Well, in Exchange 2010 there is no simple way like Get-MessageTrackingLog and you will have to depend on searching through Raw message tracking logs on the mailbox server on which the users mailbox database is mounted to find out which Transport server the Email was submitted from the Mail submission part of the mailbox server. If you are having more than one multi-role servers in the same AD site, the submission service will always try to submit the email to the transport service other than itself preferably. Only in case where it couldn't submit an email to other servers, it will try to submit to the transport service locally on the server. So, go to the Exchange install directory (you can get that by looking at the inbuilt variable $exinstall from your Exchange management shell) Under V14, go to TransportRoles\Logs\MessageTracking You will notice a large number of Tracking log files under MessageTracking folder. But as you can notice, since the above screenshot is from my lab, you do not notice a large number of files here. Look for the file name MSGTRKM********-*.log around the time that the message was sent. Note - The file name is MSGTRKM and not MSGTRK. MSGTRKM means a message tracking log generated by the submission part of email from the mailbox server and MSGTRK logs are the ones contain the further information about what happened to the email when the message is in transport pipeline. You can copy the MSGTRKM log files to a machine which contains Excel and filter it out for the MessageID that you obtained from the above Get-MessagTrackingLog command. You will notice the Hub Transport Server the message was given to under the Server-Host-Name Header. Once you obtain that, you open up the message tracking logs generated during the time of this email submission from that particular Transport server (obtained under Server-Host-Name header) and then filter that for MessageID again. Also filter the obtained results for Event-id "Receive" You must now notice only one line as mentioned in the screenshot below. Here, if you scroll right at look at the column "original-client-ip", you notice the IP address of the client machine from which the client submitted the email. In Exchange 2013, this task is much simplified as we have introduced the OriginalClientIP address attribute in the Get-MessageTrackingLog commandlet. Now, if you are wondering why you aren't seeing the correct IP of the client machine, there could be several reasons behind that. Few of them are listed below:

You have a Load balancer which masks the client IP address and stamps the connection coming to the server with its own floating IP address.
You have client coming from internet and the client comes through a firewall/Proxy server which masks the IP address of the client machine.

If there is a user account which gets compromised and sends out large number of spam emails, you can now quickly figure out what type of client is being used to send emails out and take actions against such clients for that user. For more information on the fields in Message Tracking Logs, please refer: https://technet.microsoft.com/en-us/library/bb124375(v=exchg.160).aspx

Pulling out users who are connecting using Outlook 2003 in your Exchange 2010 environment

Akshay Katti [MSFT] — Tue, 12 May 2015 05:08:00 GMT

I have had many customers work their way out in pulling the information of what client is being used by various users in their Exchange 2010 environment. Especially Outlook 2003 clients. As if you have Outlook 2003 in your environment, you will not be able to go with Exchange upgrade to a new version.

Outlook 2003 is not supported with Exchange 2013 or even Office365.

One of the most easiest and fastest way of getting that information is by parsing the RPC Client Access logs using Log Parser Studio (LPS) tool written by Kary Wall. You can know more about what are the updates to this by adding yourself into RSS feeds on this https://blogs.technet.com/b/karywa/archive/tags/log+parser+studio/

You can find more information about usage of LPS could be found in the article mentioned https://blogs.technet.com/b/exchange/archive/2012/03/07/introducing-log-parser-studio.aspx and https://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx

A pre-requisite for LPS to work is Log parser to be installed on the machine you are using LPS. You can download and install Log parser from https://www.microsoft.com/en-us/download/details.aspx

LPS uses Log parser in the background. LPS is a GUI mode representation of what Log Parser can do in terms of parsing through Exchange related logs. To understand more, I would definitely recommend going through the https://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx mentioned earlier and download the LPS tool.

Now, that we have covered the way to download LPS, I will dig into going through RPC Client Access Logs.

The RPC Client Access Logs are saved by default in the directory mentioned inside the file Microsoft.Exchange.RPCClientAccess.Service.exe.config file located inside your Bin folder.

To pull the information about where we have our Exchange install directory on a specific server, you could open your Exchange management shell and Run $exinstall

The logging is by default enabled on Exchange 2010 servers. You could see the setting "ProtocolLoggingEnabled" set to "true" in the above config file image.

Now, if you open up the RPC client access logs that are generated inside the logging directory, you get to see various fields.

A few of the fields which will be of use to us in this specific activity are:

1. client-name - User Distinguished name (UserDN)

2. client-software - the software that is connecting to the server (eg: outlook.exe, communicator.exe etc)

3. client-software-version - the version of software connecting to the server (eg: 11.*.*.*, 12.*.*.*, 14.*.*.*, 15.*.*.* etc., )

4. client-ip - IP address of the machine from which the software mentioned above is connecting to the server.

Now, there are a couple of ways of getting the information about users/machine IPs connecting to your environment.

One is a manual, old fashioned, time consuming and boring way of using Excel to get the fields you need.

Other is a quick (did I say quick? well, it flies), modern way of using LPS (let LPS do the job for you) - which we will be discussing in the post here.

I prefer to generally copy the log files to a location on my local machine before I go through any log files.

But, LPS also has this facility where you specify the share location and it can read through the logs on the share and still give you good results (will be a little slow as network latency will play its role here especially going across the WAN if you are specifying the logs on remote site servers)

Once you decide to either copy the log files locally or use file share to use a remote location share, we get into LPS tool.

When you open LPS, it shows up the main page.

We will use a custom query to pull this information out from RPC Client Access Server.

Click on Create New Query option on Top of the page.

It opens up another tab as shown in the image below

In the new query tab, select the Log Type: from "NOTSET" to "EELLOG"

and copy paste the Query mentioned below.

SELECT DISTINCT TO_LOWERCASE(Client-Software) as Software, TO_LOWERCASE (Client-Software-Version) as Version, TO_LOWERCASE(Client-Name) as UserDN, Client-Ip

FROM '[LOGFILEPATH]'

WHERE Software IS NOT NULL

AND Client-IP IS NOT NULL

AND Version LIKE '11.0%'

AND Software LIKE 'outlook.exe%'

ORDER BY Version Asc

Explaining the query written above.

We are selecting 4 different columns. Client-Software as Software, Client-Software-Version as Version, Client-Name as UserDN and Client-IP

Now, click on Log shown on top as shown in the image below.

As soon as you click on the Log, it opens up a popup window as shown below.

Click on Add folder and browse a the server share to the location where RPC Client Access Logs are saved or select a local directory where you have the log files saved.

Selecting a server share:

Or selecting from a local directory:

Click Open

You could add multiple folders as well.

Once all the folders are selected, as shown below, you can click on OK

After this, you click on Execute on the top of the LPS page

Now, sit back while LPS is doing its parsing. It should get you the information that you asked for in the Query mentioned above.

You could use this data to identify the Machine IP address and the users using those machines which has Outlook 2003 to access the mailbox on Exchange 2010.

The Versions are explained below

Client Version number	Friendly Name
11.0.5604.0	Outlook 2003
11.0.6352.0	Outlook 2003 SP1
11.0.6555.0	Outlook 2003 SP2
11.0.8000.0	Outlook 2003 SP2
11.0.8161.0	Outlook 2003 SP3
11.0.8200.0	Outlook 2003 SP3
11.0.8303.0	Outlook 2003 SP3

If you notice any of the above versions in the output, it means that there are outlook 2003 clients connecting to the server and it needs to be upgraded ASAP.

- Akshay Katti

Get-MailboxFolderStatistics wrong output?

Akshay Katti [MSFT] — Sun, 19 Oct 2014 21:47:03 GMT

I was recently working on an environment where the item counts inside the folders were not showing up the actual number as the count. It was always shows a couple of items more than what it was in the folder. Some time more than 10. Can be many... In my case its 484 (may be more on your mailbox as well...)

After banging my head over why it is showing extra count, we started looking at the TechNet for Get-MailboxFolderStatistics. TechNet clearly mentioned that the count will include hidden items as well.

A mailbox can have hidden items that are never visible to the user and are only used by applications. The Get-MailboxFolderStatistics cmdlet can return hidden items for the following values: FolderSize, FolderAndSubfolderSize, ItemsInFolder, and ItemsInFolderAndSubfolders.

So, got more curios about what was actually a hidden item. Digged in a little deeper using one of my favorite tool MFCMAPI.

Make sure the Outlook is in Online mode while you open up MFCMAPI.

Open MFCMAPI, click on Session > Logon

Select the outlook profile if it prompts you for the Account to log into.

Expand "Root Container"

Expand "Top of Information Store"

Right click on the folder which you want to find out hidden messages about.

Click on "Open Associated Contents table"

Once you click on it, it opens up another window which will contain all the hidden messages.

It contains hidden messages such as Rules (mailbox rules), User Profile information, Retention Policies that user might have etc.

The Message Class column of the window would give us a pretty close idea about what those messages are meant for.

Most of these would be information that the mailbox would need for its configuration. Users/Administrators do not have to worry about what each of these messages contain.

For more information, refer https://technet.microsoft.com/en-us/library/aa996762(v=exchg.150).aspx

Our first blog

Akshay Katti [MSFT] — Sun, 05 Oct 2014 10:40:00 GMT

This is a test blog. Here is where we will add our new innovations/sharable findings/Any thing that is worth sharing from the Microsoft messaging end