🧩Root cause description

Lately, I heard about several cases related to delegation issues with Teams, Exchange On-Prem and Delegates in Hybrid Config. Actually, this issue is described in 🔗Troubleshoot Microsoft Teams and Exchange Server interaction issues article in “A delegate cannot schedule a Teams meeting on behalf of a delegator” section.

In all cases everything was straightforward – delegate, who is using the Teams Add-in for Outlook cannot schedule a Teams meeting on behalf of the delegator. In my case behavior was different than described in article – meeting was created, but no Teams specific information was inserted to the meeting, all happened without any pop-up errors. You can also send meeting successfully from delegator. But from Teams point of view delegate wasn’t configured correctly.

Of cause, there are a lot of other prerequisites, described in 🔗Troubleshoot Microsoft Teams and Exchange Server interaction issues, like:

• 🔗Hybrid Exchange server deployment
• 🔗Configure OAuth authentication between Exchange and Exchange Online organizations. 🔗Configure Integration and OAuth between Skype for Business Online and Exchange Server
• Appropriate permissions for delegate (SendOnBehalf and Calendar permissions)

And others per article above.

But considering these specific issues, administrators stated that everything worked fine before. I will not make any conclusions in here, but it could be related to recent changes with REST API, that isn’t supported in Exchange Hybrid anymore.

This is not the main root cause of Teams integration with Exchange (network issues are more commonly experienced). But from troubleshooting perspective I hope if will be useful for everyone, who works with such configurations.

So let’s go further and investigate this issue a little bit more.

🔄Reproduce the issue

In my environment I will use Exchange 2019 Cu13 with latest updates, Outlook 2019 with latest updates, hybrid in full mode, no modern authentication. I would say, this is not so important as this can be reproduced in older versions.

🔗Troubleshoot Microsoft Teams and Exchange Server interaction issues article says, there’re two main options that should be configured for delegator on mailbox level to enable this functionality (assume, that other pre-reqs are fullfilled).

2. As second step we need to provide send on behalf permissions:

🛠️Analyzing Teams issue from Exchange Server side

When delegate tries to create a meeting with Teams plugin on behalf of another user, Teams scheduling service tries to connect Exchange on-prem servers and identify, if this user has correct permissions for that operation. In fact, we can see this error in EWS backend logs (example is shortened for visibility):

From this error we can see, that Teams scheduling service tries to identify if user has correct permissions by calling EWS function called GetDelegate.

🛠️Reproduce this issue with Exchange Web Services

In 🔗Exchange Web Services scripts in Exchange Server post we discussed how to connect to Exchange Web Services with powershell and how to configure impersonation.

Assumed, that we’re logged in with user, configured for impersonation, we can try to get delegates information for onpremuser1:

We can clearly see, that no information about delegates was returned, although we configured recommended properties:

We could also get the whole list of delegates.

Depending on configuration error can be different. For example, both permissions were configured, but Send on behalf was removed later via powershell:

🔍How users usually configure and enable delegates

If onpremuser1 would like to enable onpremuser2 as delegate, in Outlook he would go to

File -> Account Settings -> Delegate Access.

Added onpremuser2 and configured appropriated permissions.

Select corresponding user and click “Permissions“:

As we already configured everything in powershell, we can verify appropriate settings in Outlook. And, as you can see above, everything looks good. After we verified all the settings without changing anything, just close both windows by pressing OK button.

Let’s verify delegates via EWS:

Works fine. Onpermuser2 can create Teams meeting in onpremuser2 calendar.

You can also view corresponding permissions. User will be listed as delegated, even if he has send on behalf permissions and no calendar permissions.

⚠️So, what’s the difference?

In reality, when Outlook applies changes regarding delegates it modifies hidden message in delegator’s mailbox. We can verify this with MFCMAPI utility. More information for MFCMAPI can be found in this blog post.

This property of IPM.Microsoft.SceduleData.FreeBusy class with LocalFreeBusy subject has attributes, related to delegates.

Looks like this property is updated by Outlook and used by EWS. If you already configured permissions via Outlook, but that wasn’t done with appropriate permissions, you can change them via powershell as highlighted in 🔗Troubleshoot Microsoft Teams and Exchange Server interaction issues article – that would work. But if you’ll do initial configuration with powershell from the scratch, most likely you will  experience issue above. .

Since a long time, we can find a lot of resources in internet related to delegates and their configuration. And a lot of issues are related to mailbox properties that does not correctly reference a hidden message in the mailbox. The hidden message contains information that is related to any of the following features:

• free/busy publishing
• delegate
• direct booking

It depends on the specific issue, how to resolve that one. You can start Outlook with /cleanroamedprefs switch, remove specific messages with MFCMAPI, re-run powershell cmdlets (in Exchange online we have specific switches for that). In case, you need some more information on that you can reference 🔗You experience issues in Outlook when you try to configure free/busy information or when you try to delegate information article.

💡Send on Behalf vs Send As

In Exchange environment we have two options we can use, to be able to send messages from another account:

• Send As  – Allows the delegate to send messages as if they came directly from the mailbox or group. There’s no indication that the message was sent by the delegate.

• Send On Behalf  – Allows the delegate to send messages from the mailbox or group. The From address of these messages clearly shows that the message was sent by the delegate (” <Delegate> on behalf of <MailboxOrGroup>“).

As described in 🔗Manage permissions for recipients article.

So, what, if our delegate wants to send meetings in such a way, that original sender will not be visible on recipient side.

Meeting sent with send as permissions:

In comparison to meeting sent with sent on behalf permissions:

So, we already learned that for Teams send on behalf permissions are required. If you want to hide initial sender, you will also require to enable send as permissions:

But how Outlook will behave if both Send As and Send on Behalf are enabled for the same user?

I can confirm this scenario in my lab with Teams meetings.

✅Conclusion

Just a short follow up on a huge amount of information written above.

If you have issues with delegate, who is using the Teams Add-in for Outlook and cannot schedule a Teams meeting on behalf of the delegator:  

• Verify prerequisites, described in 🔗Troubleshoot Microsoft Teams and Exchange Server interaction issues
• If you are able to confirm via powershell that calendar and send on behalf permissions are set correctly, ask your user to verify these settings via Outlook and press OK to close dialog boxes even if no settings were modified
• Verify EWS backend logs if issue persists

Thanks for attention and have a nice day!

End.