Exchange 2016 has been officially released! Read the official announcement here: http://aka.ms/msexchange2016 More to come soon.

This week I was helping a customer figure out why their Windows 8.1 with Outlook 2013 clients couldn’t connect to Exchange 2010 over Outlook Anywhere with Smartcard Authentication, but their Windows 7 with Outlook 2010 clients could.  After a couple days of looking at network traces on firewalls, Process Explorer, and Process Monitor on several clients, we finally figured it out. Keep reading for more details on symptoms, cause, and resolution.

Symptoms
Outlook Profile creation either fails after a single PIN prompt with a message stating that encrypted communication with the Exchange Server could not be established, or profile creation never progresses past the first stage with repeated PIN prompts.

Additionally, using the “Test E-mail AutoConfiguration” feature in Outlook (CTRL + Right Click on the Outlook icon in the system tray) returns error 0x80090014 on the log tab for Autodiscover. (Note: If no profiles exist on the problem computer, you can open Outlook without creating a profile to access this functionality).​

Cause
0x80090014 = NTE_BAD_PROV_TYPE, “Invalid provider type specified”. This occurs when an application tries to use a Cryptographic Service Provider (CSP) that Windows isn’t aware of. This may be the result of the version of Windows not supporting a CSP, or Smartcard Middleware not properly installing a 3^rd Party CSP required by the certificate on the Smartcard.

Resolution
Verify that the version of Windows you are running supports the CSP used by the certificate on your Smartcard, and that any 3^rd Party CSPs/Middleware required by your certificate are installed and properly functioning.

You can see the available CSPs by viewing the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Providers

In this case, the customer had 3^rd Party (ActivIdentity’s ActivClient) Middleware installed. We found that version 7.x was installed on the Windows 8.1/Outlook 2013 clients that couldn’t connect, and version 6.2.9200 on the Windows 7/Outlook 2010 clients that were able to connect.

We found that the non-functioning clients were missing the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Defaults\Provider\ActivClient Cryptographic Service Provider

They were also missing a DLL identified by one of the values under that key:
C:\Program Files\ActiveIdentity\ActivClient\accsp.dll

Without that registry key and DLL, Windows couldn’t find the CSP from the certificate we selected on our Smartcard when prompted, which is why we saw the 0x80090014 error.

Updating to the latest 7.x version we could find did not resolve this issue. We had to uninstall 7.x and install 6.2.9200 (WARNING! This requires an account with local administrative privileges that is allowed to logon with username and password! After the required reboot to uninstall the 7.x version, you will not be able to logon with a Smartcard. You must install the working 6.2.9200 version in order to use Smartcard logon again.)

After downgrading the Middleware to a version that included the necessary registry entries and DLL file, the Windows 8.1 w/ Outlook 2013 clients were able to successfully connect to Exchange over Outlook Anywhere with Smartcard Authentication.

Exchange 2013 CU8, Exchange 2010 SP3 RU9, and Exchange 2007 SP3 RU16 have all been released!

Exchange 2013 CU7, Exchange 2010 SP3 RU8,  Exchange 2007 SP3 RU15, and UM Language Packs for CU7, were all released yesterday.  These include important security fixes for vulnerabilities outlined in MS14-075.

There have been reports of RU8 breaking Outlook connectivity.  Because of this, RU8 is being recalled, so expect an RU8v2.  For more information, see the Exchange Team blog post that was updated today.

Due to traveling and the holidays, I'm a little late on getting this out there…  Exchange 2010 SP3 RU7 and Exchange 2013 CU6 were both released last week (August 26th 2014). 

Exchange 2010 SP3 RU7 has a handful of bug fixes, and so far is rather unintersting and uneventful.

Exchange 2013 CU6 on the other hand, has had a couple major issues.  The first issue only happens if you're in Co-Existence with Exchange 2007 and have a Database Availabilty Group (DAG).  After installing CU6, Databases in your DAG may failover unexpectedly.  An interim update is available to fix this issue. You'll have to contact Microsoft Support to obtain it if you need it.

The second issue only happens if you're in a Hybrid deployment with Office 365.  CU6 includes the fix for KB2988229 where running/rerunning the Hybrid Configuration Wizard would fail in CU5 or earlier due to a change made on the Office 365 side.  Great news! Except that it breaks some basic functionality for your Hybrid deployment, like creating a mailbox. There's a script to fix this, but the script will fail if you've installed Exchange anywhere BUT the default install path.  You can fix it by changing the baseDirectory in the script (found in 3 spots) to this: $baseDirectory =  "$Env:ExchangeInstallPath" + "ClientAccess\ecp\DDI"