Why turning a Deskless license mailbox into a shared mailbox is a bad idea

Even if from a technical support perspective the above statement might be self explanatory, for quite some time now, we’ve had Office 365 customers facing this issue.

They were unable to open a shared mailbox in the Outlook client, while OWA access for the same shared mailbox worked flawlessly. The error message received when trying to open the shared mailbox as an additional mailbox was the following: "Cannot display the folder. It will not open folders. Logon to Microsoft Exchange has failed.” Also, you can try to remove the auto mapping and adding the shared mailbox manually, but it will fail to work as well.

Here are some basic troubleshooting steps that can be done in order to solve this type of issue:

First, run a simple Test Email-AutoConfiguration, following the below steps:

1. On the taskbar in Windows, on the lower-right corner, CTRL+right click on the Outlook system tray icon;
2. Click on Test E-mail AutoConfiguration;
3. In the new windows that will show, uncheck Use Guessmart and Secure Guessmart Authentication;
4. Enter the email address of the user and the password and click TEST;
5. Once the test is finished, from the XML tab, please select everything, copy it and paste it in a Notepad file;

In the results, check for Autodiscover connection settings for EXCH or EXPR or EXHTTP to see if they are returned for that shared mailbox. If they are not returned, it means that MAPI protocol is not enabled for the shared mailbox, like in the belwo output:

<OWAUrl AuthenticationMethod="LiveIdFba, OAuth">https://outlook.office365.com/owa/</OWAUrl>

<Protocol>

<Type>EXCH</Type>

<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>

</Protocol>

</Internal>

<External>

<OWAUrl AuthenticationMethod="Fba">https://outlook.office365.com/owa/structordala.se/</OWAUrl>

<Protocol>

<Type>EXPR</Type>

<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>

</Protocol>

</External>

</Protocol>

<Protocol>

<Type>EXHTTP</Type>

<Server>outlook.office365.com</Server>

<SSL>On</SSL>

Also, when checking more details about the shared mailbox, you’ll find the following:

Get-mailbox sharedk1| fl IsShared, UserPrincipalName, MailboxPlan, RecipientType, RecipientTypeDetails, PersistedCapabilities, SKUAssigned

IsShared                               : True

UserPrincipalName                      : sharedk1@telium.onmicrosoft.com

MailboxPlan                            : ExchangeOnlineDeskless-cdedfb65-fad3-4034-8ed8-83c6d12244d0

PrimarySmtpAddress                     : sharedk1@telium.onmicrosoft.com

RecipientType                          : UserMailbox

RecipientTypeDetails                   : SharedMailbox

PersistedCapabilities                  : {BPOS_S_Deskless}

SKUAssigned                            : False

The above suggests the previous existence of a Deskless license.

Most probably, it was afterwards turned into a shared mailbox. This is why the mailbox plan is associated with that of the Deskless license, hence the lack of MAPI protocol.

At this point, it might seem intuitive that a PowerShell command can be run in order to set the mailbox plan. The fact is that it will not work so easily:

The following steps can be tried:

Option 1: Get an Exchange Online trial license higher than the Deskless one.

Option 2: Back-up an existing user mailbox (that doesn’t have a Deskless license).

1. For the second option above, the mailbox content can be preserved using a simple PST export from the Outlook client, where the stand alone mailbox is configured.
2. Turn this user mailbox into a shared mailbox.
3. Wait around 20 minutes and then remove the existing license.
4. Assign the newly removed license to the affected shared mailbox and wait for the mailbox plan to change:
5. Assigning license also enabled the MAPI protocol:
6. After this, you can revert the changes to the above mentioned user mailbox turned into a shared one.

Ta-dam! Issue is now solved and the shared mailbox will be accessible from Outlook again!