Wednesday, April 20, 2016

What is the new Office 365 SPO address type?

Since a couple of days Office 365 customers are reporting that they notice a new SPO address type appearing at some of their user’s mailboxes.


The SPO initialism indicates the new address type is related to SharePoint Online features, the fact that it only appears on objects with a SharePoint Online license confirms this.

At this time there’s no public documentation that describes the function of this new addresses. If you happen to know more, please leave a comment.

Thursday, March 10, 2016

Exchange Hybrid? Microsoft has no plans to make creating shared mailboxes easy.

In two earlier posts (one, two) I wrote about the limited options to provision shared mailboxes in a hybrid environment. Or more specific, in an environment with directory synchronization. In short, it’s not possible to create shared mailboxes or convert regular mailboxes to shared in Exchange Online.

While both New-RemoteMailbox and Set-RemoteMailbox support the -Type parameter,  but it will only accept Regular, Room or Equipment as values and not Shared. We asked Microsoft to reconsider and add support to create remote shared mailboxes. Unfortunately the Design Change Request (DCR) was rejected. No specific reason was given but indicated was that our request was the first and only ask for this feature.

imageEarlier, when we suggested to remove the Convert to shared button from EAC Microsoft stated they considered customers wanting to convert a mailbox to shared a ‘niche scenario’. If you disagree and think customers should be able to provision and convert to shared mailboxes, make sure to let Microsoft know. Managed customers should ask their TAM, for smaller customers I’m afraid they need to burn a $499 support call as I’m not aware of another channel to add your request to Microsoft’s database.

For now this means that new shared mailboxes need to be provisioned on-premises and then be moved to Exchange Online. To convert a mailbox in Exchange Online we need to move it back to on-premises, convert the mailbox and then move it to Exchange Online again. Or read my work-around: Convert a user mailbox to shared in a hybrid environment.

Thursday, February 25, 2016

PowerShell 5.0 re-released. Do not install on Exchange!

Two weeks ago Microsoft decided to offer the latest version of .Net Framework as a recommended update. Many Exchange admins found out the hard way that it’s not wise to install every single update without checking if it is actually supported to run them in combination with Exchange. In case of .Net Framework 4.6.1 there were in fact known issues, as some people soon discovered.

Today Microsoft re-released Windows Management Framework (WMF) 5.0 RTM. WMF included PowerShell 5.0 which brings many new features. Advanced administrators are probably looking forward to install WMF 5.0 on all their systems as soon as possible. But don’t do that, not before you’re absolutely sure that it is supported with Exchange.

This information can be found in the Exchange Server Supportability Matrix, one of the most important Exchange resources that’s often overlooked. In the ESSM we find for instance that .Net Framework 4.6 is not supported:


And the same applies to WMF 5.0:


And for customers with Outlook 2007 who consider Exchange 2016:


By the way, it’s perfectly fine to use PowerShell (WMF) 5.0 to connect to Exchange Online. In fact, if you’re on the November update of Windows 10 (Version 1511) this means that PowerShell 5.0 is already installed on your system.

Tuesday, February 23, 2016

Exchange Hybrid Configuration Wizard log file locations

The Hybrid Configuration Wizard (HCW) is an incredibly powerful tool. A single wizard both updates the hybrid configuration object as well as configures your on-premises Exchange environment, Exchange Online and Exchange Online Protection (EOP). The first part is usually not the problem, but the following phases of the process sometimes fail.

If you run into an error there’s usually a referral to the log file included but if you work more often with the HCW you may automatically navigate to the following path:


While this worked for the legacy HCW, the log for the new ‘cloud application’ HCW has a different location:

$ENV:appdata\Microsoft\Exchange Hybrid Configuration

The new HCW includes a link to the log files in the wizard, but if you need to consult the logs when you’re not actually working in the HCW it’s good to know the location.

Friday, February 19, 2016

Convert a user mailbox to shared in a hybrid environment.

In a hybrid environment it’s not supported to convert user mailboxes to regular, even there is a link in EAC to do this. It seems to work, but the changes that are made in Exchange Online won’t properly sync back to on-premises. I wrote about this in an earlier post: Do not convert synced mailboxes to shared in a hybrid environment.

After that I kept working with Microsoft to obtain a better understanding of the issue and ultimately develop a process to do this conversion.

Disclaimer: This process was developed in a lab environment under the guidance of Microsoft Premier Support. Before doing this in your environment, make sure you check with your Microsoft contact if they support this procedure until any official guidance has been published.

To convert a mailbox to shared, we need to perform three steps:

  • Convert the mailbox to shared in Exchange Online
  • Modify the on-premises AD attributes accordingly
  • Revoke the Exchange Online license

In Exchange Online simply convert the mailbox to the correct type:

Set-Mailbox MyMailbox -Type Shared

Now in Active Directory Users and Computers, make sure you enabled Advanced Features under the View menu option. Next navigate to the AD object (mail user), open it’s properties and go to the Attribute Editor tab.

Tip: Write down the values before making any changes. Or even better, dump all AD attributes and their values to a text file:
Get-ADUser MyMailbox -Properties * > before.txt.

Now update the following attributes with these values:

  • msExchRemoteRecipientType: 100
  • msExchRecipientTypeDetails: 34359738368


Last step is to revoke the Exchange Online license. This is optional but in most cases something you want to do as a shared mailbox does not require a license. Simply use the Office 365 portal and find the user under Active Users. Remove the Exchange Online license.

After we revoked the license it’s important to validate the license status in Azure AD:

Get-MSOLUser -UserPrincipalName | fl *lic*


Pay attention to the LicenseReconciliationNeeded attribute, this should be False. If LicenseReconciliationNeeded returns True Exchange Online thinks this mailbox requires a license and entered the 30 day grace period. A fix

Tuesday, February 9, 2016

Edge Transport: Access Denied error on most cmdlets

Working with Edge Transport servers you may notice that cmdlets fail with an Access Denied error.


More specifically his happens with cmdlets that interact with the underlying application and operating system. Cmdlets as Get-ExchangeServer that just query the ADAM instance seem to be working fine.

The issue as well as the solution is User Account Control. Open an elevated EMC shell (right-click, Run as Administrator) and notice that all cmdlets work. For a permament fix the shortcut can be modified to alwas run elevated. Open the properties of the Exchange Management Shell and click Advanced, check Run as administrator.


Thursday, December 31, 2015

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

Thursday, December 17, 2015

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:

Tuesday, December 15, 2015

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.

Monday, December 14, 2015

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?