Can't access shared mailbox?

Copper Contributor

Anyone have any idea why a user wouldn't be able to open a shared mailbox ("Can't expand Folders" error message) in Outlook 2016 or Outlook 365 on a non-domain machine?  The user can access the shared mailbox in OWA just fine, they can access it Outlook 2013 just fine, and if the machine they are logged into is joined to the same domain as the exchange server they can access it with Outlook 2016+ just fine.  But, if they are on a home machine or other machine that's off the domain (even if it is on the same corporate network) they can't access the shared mailbox using Outlook 2016+. 


I don't see any GPO or missing certificates that would explain this behavior, and there are no ipsec policies that I can see. I don't get what's happening.  Any ideas?

5 Replies

How exactly is he trying to access the mailbox, as there are several methods? If the issue is only happening outside of the domain environment, it's most likely related to restrictions you've placed on external autodiscover or authentication.

@Vasil Michev  Well, as stated, the users can always access their own mailbox no matter where they are (on or off the network), no matter what the client  they are using (OWA, Outlook 2013, Outlook 2016+), and no matter whether their computers is bound or unbound.


What they can't do is access shared mailboxes (same exchange environment) using Outlook 2016+ UNLESS they are on a computer bound to the same domain the exchange server resides in.  computer.  OWA and Outlook 2013 work fine in all cases to access the shared mailboxes (bound to the same domain or not), but Outlook 2016+ does not.


That said I don't see how this could be an autodiscover or authentication issue as access the shared mailboxes  works just fine with the other clients.  It seems to be specifically a 2016+ "thing". 


Further bit of background in case it helps, but these users are using linked accounts. Their user account exists in one domain, while their mail in another, and there is a bilateral trust between the two domains.  Again not sure that's relevant since it works in OWA and Outlook 2013 just fine, but I thought I'd mention it. 


I can also confirm that the users have full control access to the shared mailboxes and the fact that the mailboxes can be opened in OWA and Outlook2013 lead me to believe there are no permission issues between the users and the mailboxes.   


@jab9417 Hi Jab, I'm having the exact same problem that you're describing here. A linked account in a subsidiary domain isn't able to access certain shared mailboxes on Outlook versions newer than 2013. They're able to use OWA and Outlook 2013 just fine, but cannot open the box on 2016 or O365 versions of outlook. 
Have you found any solution to this issue yet? 

@JJones1216  Sorry for the late reply.  Here's what I found in my case:  In my scenario the shared mailboxes on the remote domain (lets call it  had been assigned an email address from my domain (  This address was set as the reply address for the shared mailbox and all the usual server and SPF stuff was done so they could send using our domain name.


As we migrated users from over to, the former users that needed access to these mailboxes couldn't access them anymore.  I knew it wasn't an access issue, because  their old accounts worked fine while on a computer, it just didn't work from a computer.   In my brain, this really only left some sort of name resolution issue.    As a test, I removed the shared mailbox from outlook, switched the shared mailbox's reply address back to the address, re-added it Outlook, and VIOLA!  it worked. So, I reset my email address policy on to set the address as the reply, resolving the resolution issue and giving my a feasible workaround while I got the users migrated, and then I just double timed my migration of the shared mailboxes once that was complete.


Ultimately, I think the issue has to do with how outlook, autodiscover, and DNS work together.  When Outlook was trying to open these domain shared mailboxes that were using addresses  it either couldn't figure out where to go to access the mailbox, or couldn't figure it out quick enough and just timed out.   There is probably a better, more elegant fix for this, but this workaround worked for me.




@jab9417 Thanks! In my case it ended up being that our (to use your terminology here) domain had setup and not ever actually created autodiscover records for it (this was the only mailbox ever used on that domain)... for some reason Outlook 2010 was still able to resolve these correctly on domain-joined systems, but outlook 2016/365 was not. Outlook 2016 only worked on domain-joined systems. The fix for us ended up being to just add a autodiscover dns forward pointing to in our domain controllers.