Mar 25 2019 08:28 AM - edited Mar 25 2019 08:31 AM
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?
Mar 25 2019 01:09 PM
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.
Mar 25 2019 03:22 PM
@VasilMichev 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.
Jun 06 2019 06:52 AM
@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?
Aug 01 2019 03:38 PM
@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 child.com) had been assigned an email address from my domain (parent.com). This @parent.com 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 child.com over to parent.com, the former child.com users that needed access to these mailboxes couldn't access them anymore. I knew it wasn't an access issue, because their old child.com accounts worked fine while on a child.com computer, it just didn't work from a parent.com 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 @child.com address, re-added it Outlook, and VIOLA! it worked. So, I reset my email address policy on child.com to set the child.com 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 @child.com domain shared mailboxes that were using @parent.com 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.
Aug 02 2019 06:07 AM
@jab9417 Thanks! In my case it ended up being that our (to use your terminology here) child.com domain had setup grandchild.com 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 child.com domain-joined systems, but outlook 2016/365 was not. Outlook 2016 only worked on parent.com domain-joined systems. The fix for us ended up being to just add a grandchild.com autodiscover dns forward pointing to parent.com in our child.com domain controllers.