Exchange 2013/2016 IMAP/EWS and service accounts

 

You might have an LOB application at your company that uses IMAP to pull data from specific mailboxes. In order to access those mailboxes you don’t need necessarily to have a mail-enabled user or a mailbox assigned to the account. In general it was enough to grant FullAccess on the shared mailboxes to the account, which might be a service account.

Well, it was sufficient. This changed with Exchange 2013/2016.

Scenario

In this scenario we have a shared mailbox Shared Services and a service account SA Account CRM, which has no mail related properties at all. The service account is namely used in the LOB application and to pull data from the shared mailbox using IMAP.

Pre Exchange 2013/2016

Before Exchange 2013/2016 you just needed to grant FullAccess to the service account on the mailbox:

And you were all set.

With Exchange 2013/2016

When you introduced Exchange 2013/2016 and you try to login to the mailbox, you will receive an error for failed login:

Note: It’s not necessary that you have moved the mailbox. In an upgrade scenario you first put the Exchange 2013/2016 servers in front of the legacy servers. Already then you suffer the issue.

Before you can start analyzing logs you need to enable logging like described in this article.

Note: Don’t forget to restarte FE and BE IMAP services in order to have logging active!

Now you can reproduce the error and check the logs

“Msg=NoPrimarySmtpAddress”

This error sounds strange, but in the end the team, which is responsible for IMAP, introduced a check:

The account, which wants to logon using IMAP protocol needs to be a mail-enabled user or has a mailbox associated.

Note: After troubleshooting you should disable logging. Some considerations about this has Paul outlined in this post.

Solution

If you run into such a scenario you have to either change the account to a mail-enabled user or give it a full mailbox.

If there are some reasons that forces you not to do one of the two options:

In the end it is absolutely sufficient to add a primary SMTP address to the proxyAddresses attribute.

I just added a primary SMTP address and now it’s working. To make sure it is really the shared mailbox I’ve created a folder beneath the Inbox one called SharedServices.

Note: You can add any as long as it is a primary SMTP address!

What about EWS?

Maybe you have an LOB application, which uses EWS. Do you have the same issue? No!

Normally you run into an issue when you are using explicit access instead of ApplicationImpersonation. How to access a mailbox via explicit access is here described.

The problem here is that most of the developers for those implementations didn’t read carefully this sentence:

“Simply put, explicit access is the entry way for delegates to perform actions on a mailbox owner’s folders or items. Explicit access is granted to a delegate when they include the well-known folder name for a mailbox owner’s folder along with the mailbox owner’s SMTP address in a request to the server.”

But besides this it works. Here are the steps with EWSEditor:

Create new Exchange Service

Click no as your account has no mailbox

Add Root Folder of the shared mailbox

Et voilà

Conclusion

Always keep your eyes open for changes in major versions not only in terms of features. Maybe there are also some changes in the existing protocols.

I hope that helps.