Exchange Cross-Forest Resource Booking

Symptom

In a co-existence scenario where resource mailboxes are in one forest and user mailboxes are in another. The user attempting to book a resource (using GALSynced Contact & hidden namespace SMTP) does not get a confirmation that the resource was booked.

When looking a the resource mailbox we see the booking request is received, marked tentative on the calendar, the message is then moved to deleted items, no reply is sent.

Enabled processing of external meeting messages by setting “processexternalmeetingmessages” property on the resource mailbox to $true. This allowed the meeting request to be accepted and booked, but still no reply message is sent to the requesting user.

Cause

It has to do with Exchange trusting (or authenticating) the source of the meeting request.

Resolution

Configure/create Receive Connector to be put in place to allow the external resource booking as detailed below:

Make your new scoped connector an Externally Secured connector

This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world.

Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties, go to the Permissions Groups tab and select Exchange servers.


Next, continue to the authentication mechanisms page and add the “Externally secured” mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization.


Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing.

Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default “Externally Secured” permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Reference Material

The following sites were referenced: