Monday, November 17, 2014

Disable Inbound Proxy Probe Messages for Journaling

During a recent Exchange 2007 to Exchange 2013 migration, we ran into an issue with Managed Availability in Exchange 2013. Managed Availability provides health monitoring services.

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:
  1. Use a Journaling rule for specific users or group membership instead.
  2. Disable some monitors in Managed Availability.
I'm always reluctant to disable basic functionality in the system. So, our first attempt was by using a journaling rule with a dynamic distribution group for all users. When we did this we found that it was not reliably journaling the messages. So, we abandoned the journaling rule option and chose to disable the monitors generating the email messages instead.

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
To identify all of the OnPremisesInboundProxy monitors on your system, you can use the following command:
(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:

14 comments:

  1. Thanks for the great blogpost!

    ReplyDelete
  2. Thanks for your great article !

    ReplyDelete
  3. Excellent article you have saved me more hours of frustration.

    ReplyDelete
  4. Apparently 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.

    ReplyDelete
    Replies
    1. 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

      http://blog.vamsoft.com/2015/07/13/exchange-2013-cu9-health-probe-woes/

      Delete
  5. 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

    http://blog.vamsoft.com/2015/07/13/exchange-2013-cu9-health-probe-woes/

    ReplyDelete
  6. 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.

    ReplyDelete
  7. It worked for me. Exchange 2013 CU11. Big thanks for this solution.

    ReplyDelete
  8. Thanks, great Tip

    ReplyDelete
  9. A 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:

    Remove-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.

    ReplyDelete
  10. 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?

    ReplyDelete
    Replies
    1. I 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.

      Delete
  11. Set-ContentFilterConfig -BypassedSenders inboundproxy@inboundproxy.com

    Set-ContentFilterConfig -BypassedSenders inboundproxy@contoso.com

    ReplyDelete
  12. 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?
    My 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?

    ReplyDelete