This particular client is performing journaling by enabling journaling on each database and configuring all messages to be sent to a journaling mailbox in a separate database. They then have archiving software that removes the messages from the journaling mailbox. This allows them to retain a copy of all messages sent or received in the organization.
As we implemented Exchange 2013, the journaling mailbox was filled with messages generated by Managed Availability. The messages were from inboundproxy@contoso.com with a subject of Inbound proxy probe to a health mailbox.
Managed Availability was sending messages through the transport system to health mailboxes to verify that the system was functioning normally. However, this was resulting in a lot of messages that were not required being journaled. To avoid this, there are two options:
- Use a Journaling rule for specific users or group membership instead.
- Disable some monitors in Managed Availability.
In a knowledgebase article, Microsoft provides the following three commands for disabling the messages:
Add-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesSmtpClientSubmission" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe Add-GlobalMonitoringOverride -Identity "MailboxTransport\Mapi.Submit.Probe" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe Add-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesInboundProxy" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe
Note:
In these commands, you must provide the -ApplyVersion parameter which specifies which version of Exchange Server that the override applies to. When you apply new updates to your system, you must run these commands again.
To identify the version of Exchange you are running, you can use the following command:
Get-ExchangeServer | FL Name,AdminDisplayVersion
The Microsoft documentation does not talk about it, but unless you have a single database, you have more than one OnPremisesInboundProxy monitor. There is an OnPremisesInboundProxy monitor for each database and is unique for the health mailbox associated with each database and you need create an override for each one. On this system with four mailbox databases, the identity of each monitor was:
- FrontendTransport\OnPremisesInboundProxy
- FrontendTransport\OnPremisesInboundProxy_2
- FrontendTransport\OnPremisesInboundProxy_3
- FrontendTransport\OnPremisesInboundProxy_4
(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy*"}
After creating an override for each instance of OnPremisesInboundProxy, all of the Inbound Proxy Probe messages were disabled.
Note:
To ensure that the monitoring overrides take effect, you need to restart the Microsoft Exchange Diagnostics and Microsoft Exchange Health Manager services on all Exchange 2013 servers.
Additional resources:
Thanks for the great blogpost!
ReplyDeleteThanks for your great article !
ReplyDeleteExcellent article you have saved me more hours of frustration.
ReplyDeleteApparently with Exchange 2013 CU9, the test messages are no longer captured by journaling due to a difference in transport routing. However, I've not yet had time to confirm. If true this is a good thing.
ReplyDeleteI can confirm that as per below article, after applying cu9 to my environment. Emails are still getting generated and showing up in journaling, but they don't have receipient address, so it won't get delivered anywhere, which is waste of time for journaling point of view
Deletehttp://blog.vamsoft.com/2015/07/13/exchange-2013-cu9-health-probe-woes/
I can confirm that as per below article, after applying cu9 to my environment. Emails are still getting generated and showing up in journaling, but they don't have receipient address, so it won't get delivered anywhere, which is waste of time for journaling point of view
ReplyDeletehttp://blog.vamsoft.com/2015/07/13/exchange-2013-cu9-health-probe-woes/
Microsoft: We have seen multiple cases on it , currently there is no fix on it. We can only suppress it, or ignore it until the fix is available there is no ETA on when the fix will be available.
ReplyDeleteIt worked for me. Exchange 2013 CU11. Big thanks for this solution.
ReplyDeleteThanks, great Tip
ReplyDeleteA simple FYI for anyone running GFI MailEssentials - this procedure also stops the "inboundproxy@contoso.com" and "healthmailbox" messages from appearing in, and cluttering, the "Logs" view from within the Dashboard. Additionally, if the above GlobalMonitoringOverride rules already exist (likely if you added them after a previous cumulative update), you will need to first run the following commands:
ReplyDeleteRemove-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesSmtpClientSubmission" -ItemType Probe -PropertyName Enabled
Remove-GlobalMonitoringOverride -Identity "MailboxTransport\Mapi.Submit.Probe" -ItemType Probe -PropertyName Enabled
Remove-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesInboundProxy" -ItemType Probe -PropertyName Enabled
Thanks for the article. It prevented me from going bald, and I have clean GFI MailEssentials logs.
Thanks for the great Article. I am having difficulty with FrontendTransport\OnPremisesInboundProxy command as it says FrontendTransport module is not loaded. When i try to install it says not found. Can anyone please help?
ReplyDeleteI would try running the get-winevent command listed above to verify the names. Also, make sure it's a CAS server. The instructions above are assuming it's a multirole server.
DeleteSet-ContentFilterConfig -BypassedSenders inboundproxy@inboundproxy.com
ReplyDeleteSet-ContentFilterConfig -BypassedSenders inboundproxy@contoso.com
This procedure has helped me stop these messages from getting caught up in my spam filter and cluttering up the logs. But, it got me thinking. Is there a way to tell the managed availability to send these emails to an smtp server running on a different port?
ReplyDeleteMy current config has my spam filter software and exchange running on the same machine. The filter's smtp server running on 25, then forwards to the front end receive connector running on 2501. Is there a way to get these messages to be sent directly to the front end's smtp server on 2501?