Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 3)

If you would like to read the other parts in this article series please go to:


In part 2 of this article series revolving around cross-organization mailbox permissions in an Exchange hybrid deployment, we set the different mailbox permissions on mailboxes located in an on-premises Exchange 2013 environment and Exchange Online configured with an Exchange hybrid deployment established to verify things worked as expected.

Let’s get going.

Testing Send As & Send on Behalf Permissions Granted to an On-Premises Mailbox

Let’s see if Joe Howard who, as you remember, has an on-premises mailbox and has been granted send as permissions to Samantha Smith´s mailbox and send on behalf permissions to Sandra Martinez mailbox both which have been migrated to Exchange Online.

As we verified in the previous article, the granted “Send as” and “Send on behalf” permissions were migrated successfully with the mailboxes, however, from a supportability standpoint, they should only work if John Howard´s mailbox is stored in Exchange Online and not on-premises, which is currently the case.

Let´s launch John Howard´s Outlook 2016 desktop client and send an email message as Samantha Smith and one on behalf of Sandra Martinez. As we verified in the previous article and as can be seen in Figure 1, John Howard can still see and access the two mailboxes in his Outlook profile and is not required to re-add the additional mailboxes.

Figure 1: Joe Howard still have full access to the two migrated mailboxes

Let´s compose a new message and set the sender to Samantha Smith. If the “From” field is not shown, you can enable in under the “Options” tab in the “Compose new message” windows.

Figure 2: Enabling the “From” field for a new message in Outlook 2016

By clicking on the “From” field, we can select “Other E-mail Address” as shown in Figure 3.

Figure 3: Selecting “Other E-mail Address” in the drop-down menu

In the “Send From Other E-mail Address”, we then enter the alias or email address of Samantha Smith.

Figure 4: Specifying the sender of the e-mail message

Now let´s compose the message and hit the send button. So the message went to the “Outbox” for a second and from there was copied to the “Sent items” folder meaning it left the mailbox itself.

Figure 5

But did it, against the expectation, arrive in the inbox of the recipient? In fact it did! As you can see in Figure 6, I replied to it and the reply also arrived in the inbox of Samantha Smith.

Figure 6:
Reply to an email sent as Samantha Smith

Next up is testing “Send on behalf” behavior.

Again, let´s compose a new message and this time set Sandra Martinez as the sender of the message. Just as in the send as scenario, the email that was senf on behalf of arrived in the inbox of the recipient and a reply from the recipient also arrived to the inbox of Sandra Martinez as shown in Figure 7.

Figure 7: Reply to an email send on behalf of Sandra Martinez

Testing Send As & Send on Behalf Permissions Granted to an EXO Mailbox

Alright, so we tested “Send as” and “Send on behalf” permissions granted to an on-premises mailbox. But what about the other way around. Does it work for a mailbox in Exchange Online that has been granted these permissions for two mailboxes located in the on-premises Exchange environment?

Let´s find out. I granted Nancy Buchanan “Send as” to Nate Sun´s mailbox and “Send on behalf” on Neil Charney´s mailbox. Before moving Nancy Buchanan´s mailbox to Exchange Online, I verified that these permissions worked properly.

I then moved her mailbox to Exchange Online and using the Outlook 2016 desktop client, I first tried to have Nancy Buchanan send an e-mail as Nate Sun. The message left the outbox but the following non-delivery report (NDR) quickly arrived in her mailbox:

Your message did not reach some or all of the intended recipients.
Subject:    Sending an e-mail as Nate Sun Cross Exchange Organizations
Sent:       4/3/2016 2:47 PM

The following recipient(s) cannot be reached:

'[email protected]' on 4/3/2016 2:47 PM
This message could not be sent. Try sending the message again later, or contact your network administrator. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-0x0004dc-0x000524].

Figure 8: Non-Delivery Report (NDR) returned when trying to send an e-mail as Nate Sun

No dice! This behavior matches perfectly with Microsoft´s support statement. Now, let´s try “Send on behalf”, which probably comes up with the same result.

Nancy Buchanan fires up one more new message and sends it on behalf of Neil Charney. It leaves the outbox and… Voila! It arrives in the inbox of the recipient and likewise a reply to the e-mail message ended up in the inbox of Neil Charney. Success!

Although we did some very interesting findings that contradicts with the Microsoft support statement, it should still be noted that even though I have it working in my specific lab environment, this does not change Microsoft´s support statement and does not mean it necessarily works in your environment. However, it means that you could do the proper testing prior to communicating with your end users and based on the result inform them what to expect.

Remember my lab environment is a pure Exchange 2013 organization with an Exchange hybrid with centralized mail flow configured. If you deal with an Exchange organization with a mix of Exchange versions, there are no guarantees you will see the same results as mine.

So why did Microsoft not state some permissions work and others do not? Well, my educated guess is that by sticking with a generic support statement, you will avoid a lot of extra Microsoft support cases created based on misinterpretations. Nevertheless, we have come a long way on the journey of cross-organization mailbox permissions.

This concludes part 3 of this article series.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top