- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
I, like a lot of 4sysops readers, have been dealing with customer migrations from on-premises email and messaging into the cloud using Office 365. For the most part, they’ve gone pretty smoothly. But, like any other big project or migration, issues are inevitably going to come up post-migration. In one migration, I had customers report two different, seemingly unrelated, issues that ultimately traced back to something we should have caught before the migration completed.
Problem #1 – missing shared mailboxes ^
Missing shared mailboxes in Outlook 2013 was the first issue reported to us after the migration. Shared mailboxes allow several users to access a secondary mailbox for sending/receiving mail from a different address without the need to have a second username and password to manage. These are really nice if you need generic sales@yourdomain or info@yourdomain addresses that are staffed by more than one person or that may need to be transferred to another person at some point in the future.
Normally, shared mailboxes in Office 365 Exchange Online should automatically show up in Outlook 2013. It’s actually really cool to watch… If you set one up, it usually shows up in the end user’s Outlook before you can call them back to let them know it is set up.
In previous versions of on-premises Exchange, it was necessary to manually map the shared mailbox in Outlook. Hoping that would solve the issue, I tried manually mapping the shared mailbox. In Outlook 2013, click the File tab, then click Account Settings > Account Settings. Click the Microsoft Exchange account that is supposed to have access to the shared mailbox, and click Change. Click More Settings… and then go to the Advanced tab. You can click the Add button and search for the mailbox.
Specifying additional mailboxes to open in Outlook 2013
In my customer’s case, the result was that users were prompted for their credentials even if they had previously saved them. Re-entering the username and password only caused them to be re-prompted over and over again.
As a fallback, we had users access the shared mailboxes by clicking their user picture in Outlook Web Access and then clicking Open another mailbox. The mailboxes functioned perfectly in webmail—just not in Outlook 2013.
Problem #2 – calendar sharing errors ^
The second issue revolved around calendar sharing in Outlook 2013. Users were going into their calendar in Outlook 2013, clicking the Share Calendar button, and then sharing their calendars with co-workers. Recipients of the calendar share were receiving the email but were getting the error “The folder you selected is not available” when they clicked the Open this Calendar button.
Microsoft Outlook - “The folder you selected is not available” message
Once again, our fallback option of using Outlook Web Access (webmail) worked without issue. As long as users were sharing their calendar with another person who was also accepting the share in OWA, there were no problems.
Client configuration background ^
In this environment, all the clients were running Windows 7 (domain-joined) with a normal install of Office 2013 (with very few customizations). Outlook had not previously been used on the computers so there was no old profile to clean up. All the clients pointed to AD DNS servers and were fully patched up to February 2015. I was also able to replicate the issue in Outlook 2013 on Windows 8.1 and Windows 10, both pointing to AD DNS and external (Google) DNS.
On the server side, I was working with 2008 R2 Domain Controllers (2008 R2 functional level), DirSync, and ADFS 2.0. However, I’ve been able to replicate the issue in a few different configurations, so this wasn’t the cause.
I think the biggest configuration issue for us was the configuration of the email addresses for the end users. All users were logging in with a User Principal Name (UPN) that was different from their email address. As an example, my UPN could have been firstname.lastname@example.org, whereas my email address was email@example.com.
Like any other problem I have to troubleshoot, I started by trying to eliminate things that could be causing the problem. The biggest thing standing out to me was the fact that everything worked fine as long as we were using the web interface. That led me to believe that the issue might be on our side. I started by reproducing the issue on standalone VMs that weren’t in Active Directory as well as not using the customer’s internal DNS. Neither resolved the issue.
I also tried enabling troubleshooting logging in Outlook. You can enable this yourself by going to the File tab, Options, Advanced. Scroll down to the Other heading and click the check box next to Enable troubleshooting logging (requires restarting Outlook).
Enable troubleshooting logging in Outlook 2013
Restart Outlook and reproduce all the issues you’re having. Then, go to %temp% to recover the log files that are generated. In my case, the logs didn’t show any clear errors or problems.
We also checked to see if automapping had been disabled for the shared mailboxes, but it had not.
Interestingly, other users that had already been migrated from the previous mail solution to Office 365 Exchange Online didn’t have this issue after their migration months earlier. Those users could also access shared mailboxes and share their calendars with users in this new group without issue.
The fix ^
I ended up running through the whole process of migrating an organization in a lab environment so I could compare the process to users in this group to see if steps could have been missed. I discovered that DNS records required for Office 365 were missing—specifically for the subdomain of the department.
In an environment where a domain such as @contoso.com is used along with subdomains such as @sales.contoso.com or @marketing.contoso.com, all of the subdomains must also have the required Office 365 DNS entries. In our case, the @sales.contoso.com domain was missing the CNAME DNS record autodiscover.sales.contoso.com that points to autodiscover.outlook.com.
Users could still log in to Outlook 2013 normally because Outlook was able to access autodiscover for their UPN that was in the format username@domain. Outlook couldn’t find the information for the shared mailboxes in the format sharedaccount@subdomain because of the missing autodisover DNS entry. Outlook was also unable to resolve the calendar information for the same reason.
Creating the missing DNS record, autodiscover.sales.contoso.com, resolved the issues within a few minutes as clients started finding the missing DNS records.