Outlook 2016 and Exchange 2007

Just a quick heads-up regarding Outlook 2016 which was released recently. If you are running Exchange 2007 and you want to use Outlook 2016 I’ve got some bad news for you, this is not going to work. If you try this, you’ll get the following error message:

“The resource that you are trying to use is located on an unsupported version of Microsoft Exchange. Contact your e-mail administrator for assistance.”

The reason is simple: Outlook 2016 does not support Exchange 2007. A workaround could be to use POP3 or IMAP4, but this won’t give the user experience you want, I’m sorry.

The official Microsoft announcement regarding this issue can be found here: Error: Unsupported version of Microsoft Exchange when you use Outlook 2016 to connect an Exchange 2007 account

Exchange 2013 CU10

Microsoft silently released Exchange 2013 CU10 on September 15th 2015, right on track with their quarterly cadence, and as expected. There are no new features in this Cumulative Update, but besides a lot of hotfixes there’s also a change to RBAC which require changes to the Configuration Partition in Active Directory.

So, no changes to the Active Directory Schema, but you have to run Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms before you start the actual setup. Please note that you have to do this, even if you run the GUI version of setup. If you omit this step the changes won’t be applied to Active Directory. As a result, the RBAC changes might not be available after your upgrade. A similar issue happened with CU9 as written down in this blog post MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled not available in CU9.

Before installing Exchange 2013 CU10 in your production environment I recommend testing it thoroughly in a lab environment. The last couple of CU’s have been pretty successful without too many issues, but there might be specific issues in your own organization that Microsoft is unaware of.

When upgrading DAG members please remember you disable all the Exchange server components as explained in my blog about deploying Exchange 2013 CU9.

You can download CU10 here, and the CU10 Language packs here. A complete list of issues resolved can be found in Knowledge Base Article KB3078678.

At the same time Microsoft released released Exchange Server 2010 Service Pack 3 Update Rollup 11 (KB3078674).

When Exchange 2016 is released in the (near) future, you will need Exchange 2013 CU10 or Exchange Server 2010 SP3 Update Rollup 11 for coexistence. This will be hardcoded in the product, so if you’re planning to deploy Exchange 2016 in the future you have to install these version.

Also, when you’re running an Exchange 2013 Hybrid scenario with Office 365 you have to use the latest version, so in this case Exchange 2013 CU10 is mandatory.

The requested HTTP URL was not available

While trying to setup Remote PowerShell to an Exchange 2013 Server I ran into a couple of issues. The most obvious was that the Exchange server only accepts SSL request, so you have to specify ‘https’ in the ConnectionUri, so I used these commands:

$Credential = Get-Credential administrator@posh.local
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://webmail.posh-workshop.com/PowerShell -Authentication Basic -Credential $Credential -AllowRedirection
Import-PSSession $Session

The following error was returned:
New-PSSession : [webmail.posh-workshop.com] Connecting to remote server webmail.posh-workshop.com failed with the following error message : The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For mor e information, see the about_Remote_Troubleshooting Help topic.


When checking the PowerShell virtual directory using the Get-PowerShellVirtualDirectory | fl command I got the following response:


When you want to use Remote PowerShell from a non domain member (or via the Internet) you have to use Basic Authentication (as specified in my request), you also have to set Basic Authentication on the Virtual Directory as well, like this:

Get-PowerShellVirtualDirectory –Server MAIL01 | Set-PowerShellVirtualDirectory –BasicAuthentication:$TRUE

Once changed Remote PowerShell works as expected.