Use PowerShell to Audit Changes Made to Exchange Server 2010
Summary: Learn how to use a new Exchange Server 2010 cmdlet to audit via Windows PowerShell changes made to the server.
Hey, Scripting Guy! I am not sure this is a scripting question, but I need help, and you seem to like to help people. In fact, if you cannot help me, I might be looking for a new job. Here is the deal. We are running Microsoft Exchange Server 2010 and we are running Service Pack 1. We are currently evaluating Service Pack 2; but frankly, after the trouble we had upgrading to Service Pack 1, it might be a while. The problem is that there are several Exchange administrators in our company, and recently we have been having all sorts of Exchange Server problems. I have checked the Application Logs and the Security Logs to try to see who has been making the bad changes to our server, but I do not see anything that can help me chase it down. Please don’t tell me I have to enable something, because I would love to prove it is not me who has been messing up.
—BV
Hello BV,
Microsoft Scripting Guy, Ed Wilson, is here. Back when I was a consultant, I was called in to help a company determine who had been embezzling money by manipulating their accounting database. I was able to identify the changes; unfortunately, they were all made via the Administrator account. BV, if your Exchange administrators use their own user accounts to do their work, and they are not using a generic logon account, it is very possible that changes made to your Exchange Server 2010 are logged. This is because Exchange Server 2010 has a feature called Administrator Audit Logging. The good news is that new installations of Exchange Server 2010 Service Pack 1 enable this logging by default.
To make it easier to work remotely, I wrote about the New-ExchangeSession function on Monday and the Get-ExCommand function and on Tuesday in the Hey, Scripting Guy! Blog. I uploaded the two functions to the Exchange Server 2010 Helper Function library in the Scripting Guys Repository. You can find them here:
In keeping with my Windows PowerShell best practices, this function library incorporates two new aliases for the two functions. The first alias is NXS for the New-ExchangeSession function, and the second alias is GCX for the Get-ExchangeCommand. The first thing to do is to dot source the two functions into my current environment. Here is an example of how to do that (note there is a space between the period and the path to the function library. This command brings both functions and both aliases into the current environment.
. E:\data\ScriptingGuys\2012\HSG_1_23_12\ExchangeHelperFunctions.ps1
The commands to import the helper function library, use the aliases to create a new implicit remoting session to the server running Exchange Server 2010, and then use the alias to retrieve the Exchange commands appears in the image that follows.
After establishing an implicit remoting session to the remote server, the Windows PowerShell console is ready to use to manage the server. One of the cool features of Exchange Server 2010 is the Administrator Audit Logging feature. This feature logs when a user or an administrator makes a change to the Exchange organization. This permits the ability to trace back changes to a specific user for auditing purposes. In addition, the detailed logging provides a history of changes to the organization, which are useful from a regulatory compliance perspective or as a troubleshooting tool.
By default, Microsoft Exchange Server 2010 Service Pack 1 enables audit logging on new installations. To determine the status of audit logging, use the Get-AdminAuditLogConfig command. The use of this command and the associated output from the command are shown in the following image.
In a large network, it might be preferable to specify a specific domain controller from which to retrieve the administrator audit logging configuration. To do this, use the DomainController parameter. On my network, I can use the host name or the fully qualified domain name (fqdn). These two commands are shown here:
Get-AdminAuditLogConfig -DomainController dc1
Get-AdminAuditLogConfig -DomainController dc1.iammred.net
Prior to Service Pack 1, when enabled, the Administrator Audit Logging feature sent emails to a specific audit-log mailbox configured via the Set-AdminAuditLogConfig cmdlet, and it was examined via an email client. After Exchange Server 2010 Service Pack 1, the audit entries reside in a hidden mailbox, and the Search-AdminAuditLog cmdlet retrieves the entries. The mailbox appears in the Users container in the Active Directory Users and Computers tool, and it is possible to obtain statistics about this mailbox by using the Get-MailboxStatistics cmdlet. This command is shown here:
Get-MailboxStatistics “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}”
Exchange Server 2010 Service Pack 1 has a cmdlet called Search-AdminAuditLog. When run without any parameters, the Search-AdminAuditLog cmdlet returns all records. By default, the retention period is 90 days (on a fresh Exchange Server 2010 Service Pack 1 installation). Configure the retention period by using the Set-AdminAuditLog cmdlet.
When you make a change to the administrator audit logging, keep in mind that changes rely on Active Directory replication to take place; and therefore, they could take up to an hour to replicate through the domain. Also, keep in mind that changes to auditing apply to the entire Exchange organization—there is no granularity. The following command sets the retention period to 120 days.
Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 120
To retrieve all of the admin audit logs, use the Search-AdminAuditLog cmdlet without any parameters, as shown here:
Search-AdminAuditLog
The command to retrieve all of the admin audit logs and the output that is associated with that command is shown in the image that follows.
It is certainly possible to pipe the results from the Search-AdminAuditLog cmdlet to a Where-Object cmdlet, but it is better to use the parameters when possible. For example, to see only changes from the administrator user account, use the UserIDs parameter as shown here:
Search-AdminAuditLog -UserIds administrator
To see audit log entries that occur prior to a specific date, use the EndDate parameter. The following commands retrieve audit entries from events created by the administrator user account that occurred prior to January 18, 2012.
Search-AdminAuditLog -UserIds administrator -EndDate 1/18/12
Search-AdminAuditLog -UserIds administrator -EndDate “january 18, 2012”
To review only the audit entries that are generated by a specific cmdlet use the Cmdlets parameter. The following example only retrieves audit entries that are generated by the Enable-Mailbox cmdlet.
Search-AdminAuditLog -Cmdlets Enable-Mailbox
The Cmdlets parameter accepts an array of cmdlet names. To find audit events that are generated by either the Enable-Mailbox or the Set-Mailbox cmdlet use the command shown here:
Search-AdminAuditLog -Cmdlets Enable-Mailbox, Set-Mailbox
One really powerful feature of the admin auditing framework is to use the New-AdminAuditLogSearch cmdlet. In addition to searching the admin audit logs, this cmdlet also emails the report when it is completed. The email includes an XML attachment that contains the results from the search. The StartDate and the EndDate parameters are mandatory parameters that limit the size of the returned report. Reports are limited to 10 megabytes in size, and they take up to 15 minutes to arrive in the Inbox. The following command is a single logical line command (no line continuation characters) that creates a new report of all Enable-Mailbox commands used between 1/1/2012 and 1/18/2012. The command emails the report to edwilson@iammred.net.
New-AdminAuditLogSearch -cmdlets enable-Mailbox -StatusMailRecipients edwilson@iammred.net -StartDate 1/1/2012 -EndDate 1/18/2012
The command and the output associated with the command are shown in the image that follows.
The image that follows is the email with the search results from the previous query.
The XML attachment is shown in the image that follows.
Refer to the Hey, Scripting Guy! Is There an Easier Way to Work with XML Files blog for information about using Windows PowerShell to work with XML files.
BV, that is all there is to using the administrator audit log cmdlets. Join me tomorrow for more Windows PowerShell cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments