Reading Jeff Guillet’s ExBPA blog the other day, I came across an entry describing a solution for the problem posed by Exchange 2013’s health mailboxes when journaling. The health mailboxes are new in Exchange 2013 and are used by the Managed Availability system to send probes to different Exchange components to ensure that they are in robust good health. Two health mailboxes are created per mailbox database so a server that supports a number of databases will generate a reasonable number of probe messages, all of which accumulate and have to be journaled, if you elect to capture messages via journaling for archive or retention purposes.
In any case, I rather liked the solution described by Jeff, which is to create a journal rule based on a dynamic distribution group with the health mailboxes being excluded from the group by filtering on a value in one of Exchange’s custom attributes. I might change the command used to create the group with the New-DynamicDistributionGroup cmdlet by including a value for –RecipientContainer to ensure that the OPATH filter picks up all mailboxes in the organization, but that’s just being picky.
The solution stops the messages created by health mailboxes from being journaled, but does nothing to stop the messages accumulating in the mailboxes. Thus, you might end up seeing something like this when running the Get-MailboxStatistics cmdlet to examine how many items are in the health mailboxes.
Seeing that I am in the middle of writing the chapter on compliance for “Exchange 2013 Inside Out” The bright idea then came into my mind that it should be possible to apply a retention policy to these mailboxes to have the Managed Folder Assistant clean them out on a regular basis. In fact, a single-tag policy will do the trick, as all we really need is a default tag that removes items after a set period, which should be pretty short as there’s no good reason to retain anything in these mailboxes. I therefore created a default tag that would permanently delete items older than 2 days and added it to a new retention policy that I called “Health Mailboxes Retention Policy” (insightful naming conventions have never come easily to me).
I then applied the new retention policy to the health mailboxes by running the following command:
Get-Mailbox –Monitoring | Set-Mailbox –RetentionPolicy ‘Health Mailboxes Retention Policy’
Running Get-Mailbox with the –Monitoring switch returns a list of all of the mailboxes marked as being used by Exchange for monitoring purposes. It’s an easy way of identifying the health mailboxes within the organization. However, when I ran the command again to see whether the retention policy was now in place, no mailboxes showed up. This was very odd because the mailboxes and their underlying Active Directory user objects were still in place and were still operational as probes were still being sent and could be identified by running the Get-MessageTrackingLog cmdlet.
Even odder, I could now see the health mailboxes in the Exchange Administration Center (EAC) where they had been invisible beforehand. A little investigation revealed that Exchange now regarded the health mailboxes to be “user mailboxes”, evident by the fact that their RecipientTypeDetails properties were reported to be “UserMailbox” rather than “MonitoringMailbox”. Further probing revealed that although the health mailboxes are exposed through EAC, you can’t update their properties as the objects can only be managed by a console with a version higher than “126.96.36.199”. I had assumed that EAC was in this category because its version is 15.0.32, the RTM version for Exchange 2013, but something else is clearly getting in the way. I also haven’t figured out how to reset the RecipientTypeDetails property for the health mailboxes as the Set-Mailbox cmdlet doesn’t support this property.
I’ve reported this issue as a bug to Microsoft and no doubt will hear back from their support staff soon. In the interim, the good thing is that the retention policy is working as planned and MFA is clearing out items once they are more than 2 days old.
New health mailboxes are created normally with new mailbox databases. These mailboxes operate just like their older counterparts. However, I won’t apply the retention policy to these mailboxes until I hear back from Microsoft support! Living on the edge with the new stuff in Exchange 2013 can sometimes get on the nerves…
Follow Tony @12Knocksinna
Pingback: Applying Retention Policies to Exchange 2013 Mailboxes « SME IT guy
Good Posting. What I did was to create a Task which exports all the Searchmailbox mail to a normal user Mailbox called search once per day with search-mailbox -deletecontent.
Then I applied the Retention policy to the search Mailbox.
have you heard anything back regarding this bug? i am in the same boat. Thanks!
No, but I don’t know if the developers think that it is a bug. What’s for sure is that Exchange 2013 CU1 generates a lot less traffic to these health mailboxes so the problem is lessened. I expect that further improvement will come in CU2 as the word (from TechEd North America) is that the developers have been looking at how Managed Availability works in production to tweak it a tad more.
Tony, I thought I would ask the question again now that we are on CU3? Any change to the behavior once you place a retention policy in these mailboxes?
Nope. The health mailboxes seem to generate less junk, but that’s just a feeling. And the retention policy doesn’t seem to hurt.
Any changes w.r.t to SP1 since health mailbox holding lot of items in it. Will it be best practice to clean the email item which are older than 30 days…will have any impact
Nothing has changed that I am aware of in this area in SP1. Items still accumulate, but there seem to be fewer from CU2 onward. Just an impression as I have not really investigated.
Seems to be fixed in CU5
You’d expect that… CU5 is five updates into a release cycle!
Hi, I applied the retention policy to the health mailbox and the health mailboxes are shown on the EAC as described in the article. (My environment is Exchange 2013 CU1). I am wondering whether I can re-create the health mailbox to hide the mailboxes in EAC by using the Remove-Mailbox and restart the Exchange Health HM.
I’d upgrade. You are now running a very old environment. Get to SP1 or CU5 if you can and you’ll find that the health mailboxes are less chatty. You can recreate the health mailboxes if you like, but getting to newer and more sorted software is much better.
Thank you for your reply. Would you point me where I can find the instructions on how to delete the health mailbox?
I wouldn’t delete the health mailboxes unless you absolutely must. But something like Get-Mailbox -Monitoring | Remove-Mailbox will remove all the mailboxes while a command like Get-Mailbox “HealthMailboxec1ed3f5774d4f51ab89da8bfe99f888” -Monitoring | remove-mailbox will remove a specific mailbox. Of course, you have to identify which ones belong to a specific database so check the properties of the mailboxes first. Or just delete the AD accounts belonging to the mailboxes. And when you are done, restart the MSExchangeHM service and the mailboxes should be recreated. Test what you want to do in a dogfood environment first.
Can you move the Monitoring Mailboxes to another MailboxDatabase, like the one you use for Journaling and disable Journaling on that DB?
No. The monitoring mailboxes are required by Managed Availability and will be recreated if they cannot be found in a mailbox database.
I guess we need Microsoft to add another property to TransportConfig, so we can use a switch like Set-TransportConfig -VoicemailJournalingEnabled $false
Maybe call it MonitoringMailboxJournalingEnabled