Auditing Administrative Changes in Exchange 2010

Exchange 2010 maintains a hidden mailbox that logs all administrative changes. The "Hey Scripting Guy" blog recently published an article that explains how to retrieve that information with powershell. If you ignore the remoting stuff at the top of the article (that can confuse or discourage some people), the auditing commands can be run directly from the management shell on any of the Exchange 2010 servers. I've always wanted this sort of visibility into who's doing what in Exchange, so I wanted to talk about it some more. But go read this article first:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/25/use-powershell-to-audit-changes-made-to-exchange-server-2010.aspx

For example, to get a list of all the new mailboxes created in the last day, use this command:

Search-AdminAuditLog -StartDate (get-date).adddays(-1) -EndDate (get-date) -Cmdlets enable-mailbox

Which produces this output:

RunspaceId         : 7d4bc202-de70-4c2f-a146-263d05445ea8

ObjectModified     : domain.local/Headquarters/Contractors/Cristin Broom

CmdletName         : Enable-Mailbox

CmdletParameters   : {Identity, Alias}

ModifiedProperties : {Extensions, PoliciesIncluded, EmailAddressPolicyEnabled, PoliciesExcluded, RecipientTypeDetails,

                     RejectMessagesFrom, RecipientTypeDetailsValue, AcceptMessagesOnlyFromDLMembers, ArchiveName, UseDa

                     tabaseQuotaDefaults, OriginalPrimarySmtpAddress, ElcExpirationSuspensionEnabled, ServerLegacyDN, I

                     sMailboxEnabled, ReadOnlyPoliciesIncluded, IsValidSecurityPrincipal...}

Caller             : domain.local/Headquarters/Information Systems/Operations/Don Drieberg

Succeeded          : True

Error              : None

RunDate            : 1/26/2012 9:20:46 AM

OriginatingServer  : EXCH01 (14.01.0323.001)

Identity           : RgAAAACsFGTJn7mcTJ0+hnPZuWZoBwCmwLQTE/orS6kUJLJIy+JCAAAAkH9zAACmwLQTE/orS6kUJLJIy+JCAAAQcrvYAAAJ

IsValid            : True

From this, we can see that Cristin Broom's mailbox was created on 1/26 at 9:20 am by Don Drieberg.

The audit mailbox retains data for 90 days by default, and contains records of changes to all Exchange objects – mailboxes, distribution groups, contacts, connectors, inbox rules, etc. It doesn't log all of the details, though. For instance, although it logs mailbox changes, including which properties were changed, it doesn't include the value (before or after) of those properties. You just know that it was changed somehow. Still could be very handy for auditing. A simple command like this:

Search-AdminAuditLog -StartDate (get-date).adddays(-7) -EndDate (get-date) -Cmdlets new-distributiongroup | fl objectmodified, caller

Can show me any new distribution groups that were created in the past week:

ObjectModified : domain.local/Distribution Lists/CORP - IS-QA for Trade Hold

Caller         : domain.local /Headquarters/Information Systems/Operations/Don Drieberg

ObjectModified : domain.local/Ireland/Distribution Lists/Tax

Caller         : domain.local/Ireland/Users/IT/Admin. Accounts/Sarah Monet

If you don't supply a StartDate or EndDate, your query will return matches for the entire retention period (90 days, by default), which could be quite a lot of information.
If you don't supply a Cmdlets parameter, your query will return matches for all cmdlets.

Of course, you can always pipe the output through a Where-Object clause, to filter the results.

For more information about audit logging, see the Administrator Audit Logging section of the TechNet library.

- Mike

Quickly Retrieving Send-On-Behalf-Of Users

This morning, I needed to verify and provide a list of users with Send-On-Behalf-Of rights to a particular mailbox, and all the usual powershell methods showed the field, but ended with an ellipsis, so I couldn’t be certain that there weren’t more users than what I was seeing. I needed a quick way to view the complete list. After some playing around, I ended up with this nifty one-liner:

[PS]>foreach ($sender in (get-mailbox Mailbox2BeChecked).GrantSendOnBehalfTo) { $sender.tostring() }

This resulted in a nice, complete list of user DNs.

domain.local/Ireland/Users/IT/User1

domain.local/Ireland/Users/IT/User2

domain.local/Ireland/Users/IT/User3

domain.local/Ireland/Users/IT/User4

Search For A Specific Folder

A recent snafu in our deployment of managed folders for email archiving resulted in duplicate folders in a few dozen mailboxes. I didn't know about the duplicate folders at the time it occurred, and none of the affected users reported the "extra" set of folders for over a month.

We use an Exchange managed folder mailbox policy to push a set of managed folders to each mailbox. When created by Exchange this way, the folders can't be modified by the user, which allows Enterprise Vault to apply a consistent archiving and retention policy to the contents of these folders.

If the Enterprise Vault (EV) provisioning process runs before the managed folders are created by Exchange, it causes two problems - (1) the EV-created folders are not managed by Exchange, which means that users can modify or even delete them, (2) and when Exchange tries to create the managed folders, it finds those folder names already exist, so Exchange creates a new set of folders with a slightly different name ("Managed Folders1"). The result is one set of folders targeted for archiving by EV, and another set of folders being managed by Exchange.

If we catch the problem early enough, before the user has moved any messages into either set of folders, then the fix is fairly easy.

1. Open the mailbox in Outlook or OWA, and delete the Managed Folder hierarchy that was created by Enterprise Vault
2. From an EMS prompt, remove the managed folder mailbox policy and folders.
       Set-Mailbox -Identity "mailboxID" -RemoveManagedFolderAndPolicy
3. If the folders are empty, the previous command will delete the entire managed folder hierarchy. Then all we have to do is set the policy again.
       Set-Mailbox -Identity "mailboxID" -ManagedFolderMailboxPolicy
4. And then run the assistant to actually push the new set of managed folders to the mailbox.
       Get-Mailbox -Identity "mailboxID" | Start-ManagedFolderAssistant

What does all that have to do with searching for a folder? Well, after fixing the reported mailbox, I was curious about how many others were out there that hadn't been reported. I needed to find every mailbox that had a "Managed Folders1" folder in it. Here's what I came up with.

$mbxs = Get-MailboxDatabase | Get-Mailbox -ResultSize unlimited

$y = @()

foreach ($mb in $mbxs)

{

    $x = Get-MailboxFolderStatistics $mb | where {$_.Name -match "Managed Folders*"} | Select Name

    $x | Add-Member -MemberType NoteProperty -Name "DisplayName" -Value $mb.DisplayName

    $y += $x

}

$y | where {$_ -AND $_.Name -eq "ManagedFolders1"} | sort DisplayName

It took a few minutes to run through our 3000+ mailboxes, but in the end, I discovered another 72 mailboxes that had Managed Folders that had been deployed incorrectly. Now, the time-consuming task of fixing them, as detailed above, begins. Bummer.

Exchange Server Active Directory Schema Changes Reference, November 2011

Microsoft has published a reference of the Active Directory schema changes made by Exchange Server during installation. 


"The Exchange Server Active Directory Schema Changes Reference includes changes made by Exchange Server 2010 SP2, Exchange Server 2010 SP1, Exchange Server 2010, Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007, and Exchange Server 2003."

http://www.microsoft.com/download/en/details.aspx?id=5401

Maintenance Prep

Being in retail, our company goes into a Q4 "freeze", where systems are locked down and no changes are made during our most critical sales period. I've been using this time to prepare for the next scheduled maintenance window, making lists of servers and what patches and hotfixes need to be applied to them.

A primary goal is to get all of my Exchange 2010 SP1 servers in sync. Those in the main office were in the middle of deployment when the UR4 bug was discovered, and so those have the interim update installed, while those in Australia and Europe, which were installed later, have UR4v2 installed. I was wary of installing UR5 because of the bugs found in UR3 and UR4, so I waited, then UR6 came out just before we locked everything down. Although I got it installed in QA, there wasn't enough time to get comfortable with it prior to the production freeze. After the freeze is lifted, the plan is to get all the servers on UR6, or possibly even SP2 if it's released by that time.

For the CAS/HUB servers in the main office, the steps will be:

1. disable Forefront Protection 2010 for Exchange
2. uninstall the UR4 interim update
3. re-enable strong name checking
4. install UR6
5. re-enable Forefront
6. copy our custom OWA graphics to the new folder

For the DAG members:

1. disable Forefront
2. run StartDAGServerMaintenance.ps1
3. uninstall the UR4 interim update
4. re-enable strong name checking
5. install UR6
6. install the cluster hotfix from kb2550886
7. run StopDAGServer Maintenance.ps1
8. re-enable Forefront
9. run RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference

That last command is supposed to re-balance the databases according to their activation preference. I've never used that script before. I usually re-balance my databases manually in the EMC, which is very tedious, especially when it tries to refresh the list of servers from all sites. Hopefully, the script will work as expected and simplify the process.

Updating the Australia and Europe servers will be simpler, since they don't have the interim update. However, they still need the cluster and Forefront hotfixes. I've already downloaded and copied the relevant installer files to each machine, so they're ready to go when the time comes. Well, unless SP2 is released before then, which will require testing in QA, and then an update to the maintenance plan. I've heard that SP2 will require a schema update, too, so that'll add another step.

A couple of weeks ago, we had a problem with Forefront Protection for Exchange on the DAG members in the main office, which was randomly crashing, taking down the Information Store with it. An emergency change was authorized, and hotfix rollup 3 was installed on the DAG members only, just to fix the immediate problem. Part of the upcoming maintenance will be to update Forefront on all of the Exchange servers, to get that hotfix installed on all of them, bringing them all up to v11.0.713.0.

I'm much happier when all my servers are in sync. It makes it easier to troubleshoot problems, and easier to explain when I have to call Microsoft for support.

ExPerfWiz - Exchange Performance Wizard

ExPerfWiz is a powershell based script to help automate the collection of performance data on Exchange 2007 and Exchange 2010 servers.

I just discovered this script yesterday, but haven't had time to play with it. If it's useful in our environment, I'll post a follow-up article with more details.

http://archive.msdn.microsoft.com/ExPerfwiz

Use VERBOSE to See What Your EMS Commands Do

"Sometimes you need to know exactly what EMS does to help track down a problem, perhaps to provide information to Microsoft support to help them figure out what's going on in your Exchange deployment. You might just want to know what's happening when you execute a command. In either case, you can add the –Verbose parameter to a command to have PowerShell generate details of exactly what it does as it proceeds."

- from "Exchange 2010 Inside Out" (written by Tony Redmond)