One of my customers was running into an odd case of disappearing e-mails. They have an on-premise Exchange 2010 mail server on which they have a Shared mailbox to which all employees have access.

Now all of a sudden mails that are moved/copied TO this shared mailbox mysteriously disappear…

First thing that came to mind: Rules!

Bring in the Shell

First of all I needed to check if there weren’t any Server side rules which were configured, which you can easily do with the following command:

1

Get-InboxRule

Blank result told me that if it was going to be Rules, it would have to be Client Side Rules…. great…

I had informed the customer of this and it would be up to them to have the users check their Client Side Rules [if needed disable them temporarily] in order to find the culprit. The customer took it one step further and went past all the users’ desks [luckily ‘only’ around 30’ish people] and checked the Rules himself, but unfortunately nothing.

Back to the drawing board

First of all I confirmed the 2 next issues:

1. The mailbox is actually a proper Shared Mailbox and not a Resource Mailbox by mistake ```powershell Get-Mailbox -Identity ProblemMailbox | Select-Object RecipientType,RecipientTypeDetails

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

  2. What happens to e-mail directly sent to the mailbox?
    Well, I had sent 2 test emails to the mailbox and left them in the Inbox for 2 days to see if perhaps someone's Client Side Rules would get triggered..
    [Un]Fortunately these mails were not moved/removed, so something else must be causing this…

Knowing these bits, I needed to drill down to the specific mailbox and find out exactly what was happening there.

# The magic word is….

**Auditing!**
But of course, if you audit folders etc. , why can't you audit mailboxes?

It turns out, you can, and quite detailed as well!

Using my best friend <a href="http://www.google.com" target="_blank">Google</a>, I looked up the details on what to use and how to use it.
Yes, I know, perhaps I should've used the built in

```powershell
Get-Help

but I personally prefer to use Google to point me in the right direction and then let the built-in Help function show me how to customize the usage of said command.

This TechNet article told me everything I needed, the command I required was as simple as ever

1

Set-Mailbox -Identity ProblemMailbox -AuditEnabled $true

But what is audited by default? What are the default settings for the auditing?

1

Get-Mailbox -Identity ProblemMailbox | Select-Object *audit*

This shows me the following:

• AuditingEnabled Well, this should be rather clear 🙂 Default value = False
• AuditLogAgeLimit How long should the Audit Log live before it’s recycled? As the Audit Log is contained within the actual mailbox, you want to limit this, as it takes up space depending on how much you want to have audited Default value = 90 days
• AuditAdmin Which actions performed by Administrators should be logged? Default value = Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create
• AuditDelegate Which actions performed by a Delegate should be logged? Default value = Update, SoftDelete, HardDelete, SendAs, Create
• AuditOwner Which actions performed by the Mailbox owner should be logged? Default value = nothing

Great, but I would prefer if I saw a little more details for Delegates to I can report this back to the customer. This TechNet article explains exactly what action means what, so you can easily tell if it’s interesting for your auditing or not.

Ok, so this is what I set up to configure both auditing and the actions I wanted audited

1
2
3
4

$Mbx = 'ProblemMailbox'
$AuditDelegate = 'Create','HardDelete','Move','MoveToDeletedItems','SendAs','SendOnBehalf','SoftDelete','Update'

Set-Mailbox $Mbx -AuditEnabled $true -AuditDelegate $AuditDelegate

Testing your code

Ok, I’ve added auditing, now what?

I need to be able to check my audit logs and see if specific actions get reported the way I want them to. What I did was as follows:

1. I created a subfolder under Inbox called Test
2. I moved my first test message to the newly created folder
3. I copied my second test message to the newly created folder
4. I removed my original second test message

Great, these are basically the actions I need to have checked.

I can now search the logs using this command:

1

Search-MailboxAuditLog -Identity $Mbx -LogonTypes Delegate -ShowDetails

Because the output can be a bit much to sift through, I save the details to a variable first

1

$logs = Search-MailboxAuditLog -Identity @Mbx -LogonTypes Delegate -ShowDetails

and I’ll sift through the values to see what I would like to have reported back to me.

Now to be honest, while running through this I had also found this GREAT article by Paul Cunningham, an Exchange Server MVP which basically had all my wishes pre-made. While I love playing around with PowerShell to find the perfect solution, I have to take into account that the customer is experiencing an issue that needs addressing, so I used Paul’s script to get the report I wanted.

Automate the reporting

Now I have auditing configured and reporting on my audit, I have to make sure I get this report on a regular basis so I can track the culprit down.

Since this customer has a Windows 2008R2 Server running, setting up Scheduled Tasks with PowerShell was not yet properly implemented, so for this time I’ll manually add the Scheduled Task following the steps in my Scheduled Tasks - PowerShell Scripts with Parameters post [conveniently posted BEFORE this article 😉 ] and run it once to confirm that it runs as it should and doesn’t produce errors.

The trap is set, now we wait!

As this is an actual issue I’m experiencing right now, I’ll let you know the results when I know them, but you can already use the above techniques for your own troubleshooting.

Happy scripting!