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.

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:

$exinstall\Logging\Update-HybridConfiguration

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.

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 MyMailbox@mydomain.com | 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

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.