Do not convert synced mailboxes to shared in a hybrid environment

Recently I ran into an issue with shared mailboxes in Exchange Online. In the Office 365 Admin portal I created a custom view in the Active users section to track issues with our licensing process:


Some users were displayed here which where moved from on-premises as regular mailboxes and then converted to shared with the button in EAC. Which is odd because a license isn’t required for a shared mailbox.


At a first glance everything seemed okay, the mailbox moved to the Shared view in EAC. The only thing off was the fact that LicenseReconciliationNeeded was set to True for this user which is why it showed up as mailbox without a license in the portal.


Next I compared the mailbox properties as well as the on-premises AD attributes with another shared mailbox, that happened to be shared before it was moved to Exchange Online.


So for the shared mailbox that was converted before the move msExchRemoteRecipientType was set to 100 (Shared mailbox in Exchange Online) while the other still displayed a value of 4 (Migrated mailbox).



Next step was to involve Microsoft Premium Support. Their first recommendation was to change the value from 4 to 100 in the on-premises AD and have it synced back to Azure AD. This didn’t make sense to me and by that time I already discovered that I could easily reproduce the issue in the test environment by converting a moved mailbox with the button in EAC so it was not caused by an issue in our on-premises AD.

Next the engineer provided the following KB article and explained that the behavior I’m seeing is ‘by design’: Shared mailboxes are unexpectedly converted to user mailboxes after directory synchronization runs in an Exchange hybrid deployment.

The article describes a scenario where a mailbox has been moved to Exchange Online, is converted to Shared and with the next directory sync is converted back to regular. Interestingly that last part is not happening in our environments and I was not able to reproduce the described behavior, not with a highly customized FIM nor with a default AAD Connect sync engine.

Anyway, accoring to the article it is not supported to convert a regular mailbox for a synced user to the shared mailbox type. The technical explanation is that directory synchronization currently doesn’t support the syncing back of all attributes that change during the conversion.

Microsoft recommends to move the mailbox to on-premises, convert it to shared and then move it back to Exchange Online. For some customers this may present an acceptable work-around, for others it is cumbersome and requires additional planning and communication to end-users.

And the real question of course is why Microsoft allows their customers to convert a synced mailbox to shared when the underlying technical issue can result in the mailbox being deleted after the grace period ends. I left feedback through the support channel and on the Office 365 Uservoice site. Please vote here if you agree this should change: Support conversion to shared mailbox for synced users

My take on the Star Wars The force awakens story line

Just kidding, this is a test post with version 5.1.2 of Open Live Writer. In case you missed it, Open Live Writer is the open source successor of the popular blogging tool Windows Live Writer. WLW once was part of the Windows Live Essentials bundle of tools and has a large share of fans, even though development and improvements are absent since 2012.

Read more about OLW here: http://openlivewriter.org/

Exchange 2013 CU11 and Exchange 2007/2010 Update Rollups released

Microsoft today announced the release of the 11th Cumulative Update for Exchange 2013. That's not all, Exchange 2010 SP3 receives Update Rollup 12 and there's even one for Exchange 2007: UR 18. The latter is basically a DST update so don't expect any other issues to be fixed after you install this update.

Click the link to read more. One more thing, make sure you read this article on the Exchange Team Blog too: Exchange Management Shell and Mailbox Anchoring. This change in behavior may impact the way you manage Exchange with PowerShell. There's been some concern in the community about the benefits of this change, some people suggest that it introduces more problems than is solves. More about this subject on Reddit: Major change to how PowerShell works with Exchange

Now the wait is for Exchange 2016 CU1 which will be released with the next set of semi quarterly updates at the end of 2016Q1.

December 8, 2015, update for Outlook 2010 causes Outlook to start in safe mode

I noticed several people reporting weird issues with their Outlook 2010 clients. For instance the loss of signature and other settings. The cause seems to be installation of update KB3114409. This update adds a new feature:

Adds administrative support to prevent Outlook 2010 from booting into safe mode. Administrators set this function in some scenarios when they have add-ins that must be enabled.

Admins can use a registry key or GPO to prevent the users from starting Outlook in safe mode. The issue is, without those controls Outlook now starts in safe mode by default.

The fix is relatively easy, simply uninstall update KB3114409. Alternatively admins can use the aforementioned registry key to control Outlooks behavior. Some smart people on Reddit figured out the correct entries for both x86 and x64 systems: KB3114409 breaking Office 2010, forcing it to start in Safe Mode, which is the exact opposite of what's supposed to happen.

Microsoft pulled the update so I expect no new occurrences. Anyway, this is why we roll-out patches to a small test group before rolling them out to the entire enterprise, don't we?

What every Office 365 admin should know about supported Outlook versions

Working with customers that are beginning to consume Office 365 services I see a lot of confusion about whether their old Office version should work with Office 365. Especially when we’re talking Office 2010 or even 2007. What certainly not helps is that Microsoft restructured their Office 365 documentation in such a manner that it is hard to find all relevant information.

The general Office 365 for Business requirements states the following:

Make sure that your Office clients are compatible with Office 365. Office 365 works with any version of Office in mainstream support: the latest version of Office, Office 2013, and Office 2011 for Mac. Previous versions of Office clients, such as Office 2010 and Office 2007, may work with Office 365 with reduced functionality.

The requirements for Exchange Online are more restrictive and definitely clearer, although they are hidden in the Exchange 2016 system requirements page:

Exchange 2016 and Exchange Online support the following versions of Outlook:

• Outlook 2016
• Outlook 2013
• Outlook 2010 with KB2965295
• Outlook for Mac for Office 365
• Outlook for Mac 2011

Outlook clients earlier than Outlook 2010 are not supported. Email clients on Mac operating systems that require DAV, such as Entourage 2008 for Mac RTM and Entourage 2004, are not supported.

So your users are still on an older Outlook 2010 build without SP2 and the April 15, 2014 update? Not supported. Outlook 2007? Not supported. From experience I can tell that these requirements are not a joke, your users will not be able to connect to Exchange Online with Outlook 2010 RTM. Another customer saw Outlook 2007 crashing after moving the mailboxes to Exchange Online and was able to work-around this by removing the language pack.

So if we like it or not, consuming a cloud service equals losing control about what client software you’re using. It’s the cloud provider that dictates the supported versions and when they think you should upgrade. That brings me to the final point, that these requirements not static and change over time. So make sure you visit the sources regularly to see of there have been updates.