Queues Building to inboundproxy.com Domain

Posted on Posted in 2013, exchange

In Exchange 2013 there are a series of probes that monitor the health of the different components of the servers. One of these probes monitors the health of each Frontend Transport server and its ability to proxy messages to each of the 2013 mailbox databases in the Exchange organization.

The monitoring happens by sending emails to a specific mailbox on each mailbox database in the organization. This mailbox is called HealthMailboxguid The guid matches the guid of the mailbox database that the mailbox is located in.

Get-Mailbox HealthMailbox* –Monitoring | FT Name,Database
Get-MailboxDatabase | FT Name,GUID

If you have a problem with the configuration of any of these mailboxes then you will get Non-Deliverable messages generated, and these messages will get sent out the most appropriate send connector as the Exchange probe emails “come from” inboundproxy@inboundproxy.com. At the time of writing, the inboundproxy.com domain is registered, but the MX record does not exist – so the messages queue on your Exchange Servers or on any smart host device that you use.

To work out what you need to fix to stop these messages queuing (or worse, have them sent to the inboundproxy.com domain if the owners of that domain publish an MX record to the internet) then you need to suspend some of the messages in the queue and export the messages to a file on the disk. You can then open the message and see what the error is and fix it.

Get-Queue server\idForInboundProxy.comQueue
Get-Message -Queue server\idForInboundProxy.comQueue | Suspend-Message -Confirm:$false
Export-Message server\idForInboundProxy.comQueue\MessageID | AssembleMessage -Path c:\temp\Health1.eml

Repeat the above for a random selection of the messages in the queue (as you might have more than one issue to fix) changing the .eml file name and MessageID each time.

Once you have a few .eml files exported, open them up and see what the reason for the NDR i and fix it.

In my Exchange organization I had some of my HealthMailboxes with the wrong SMTP proxy address (@domain.local) rather than the only accepted domain I had (@domain.com), so I just ran Update-EmailAddressPolicy again and the problem went away once the HealthMailboxes had their SMTP proxy address changed to a valid address.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.