You can take a geek out of a data center, but you can’t take the data center out of a geek. Earlier this week a support call for the favorite HTTP_500 error (ActiveSync error 0×85010014) floated up to me in Maui, HI. Here is the scenario, cause, solution, etc.

Microsoft Windows 2003 Enterprise Server SP1

Microsoft Exchange 2003 Enterprise Edition SP2

Single-server deployment, both front-end and back-end Exchange & ActiveSync on the single server.

Symptoms

0×85010014 is basically an indication of a few dozen server errors that Exchange can throw your way (via Exchange, OMA, exchange-oma, Microsoft-Server-ActiveSync) and other directories. This error can be encountered on SBS in many permutations but is usually related to a corrupted Outlook/ActiveSync profile. Not the case here as these are all virgin servers, devices and emulator images. Chris De Herrera, MVP and defacto god of Microsoft mobility problems, has a great article detailing all ActiveSync error codes.

The problem: Devices and emulator were not syncing with the server. Via SSL or without SSL, same error – 0×85010014. The server reported two error codes:

OPTIONS /Microsoft-Server-ActiveSync User=vlad&DeviceId=1012&
   /DeviceType=PocketPC 80 – 1.1.1.1 MSFT-PPC/5.1.2200 401 2 2148074254
OPTIONS /Microsoft-Server-ActiveSync User=vlad&DeviceId=1012&DeviceType=PocketPC&
   Log=VNATNASNC:0A0C0D0FS:0A0C0D0SP:0C0I0S0R0S0L0H 80
   X\vlad 70.217.166.196 MSFT-PPC/5.1.2200 200 0 0
POST /Microsoft-Server-ActiveSync User=vlad&DeviceId=1012&DeviceType=PocketPC&
   Cmd=FolderSync&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:
   1C1I491S336R0S0L0H0P 80 X\V 1.1.1.2 MSFT-PPC/5.1.2200 500 0 0

Slightly obfuscated but you get the picture. OPTIONS request kicks back an HTTP_401 error which is an authentication issue. This is where most KB articles will make you believe that IIS had Kerberos disabled. Not the case here.

Causes

Because with a single server deployment all Exchange roles sit on a single box, there is only one /Exchange directory. This directory is used by devices and clients to access mailboxes. Server based ActiveSync (/Microsoft-Server-ActiveSync) cannot function if FBA (Forms Based Authentication) is enabled… which on a standalone server it is in order to provide pretty OWA logins. So, catch 22.

Microsoft’s solution (kb 817379) to this is to create a secondary /Exchange virtual directory and hack the registry and point it to this new alias. The KB article gives an excellent summary on how to do this. However, if you have just the right mix of steps you can really shoot yourself in the foot and it can take a long time to find the solution to the HTTP_500 error.

Solution

Make sure you turn off FBA BEFORE you export the /Exchange configuration.

Because the FBA conflicts with Microsoft-Server-ActiveSync, exporting the configuration and importing it as another Virtual Directory really does not do much more than create the identical problem, just with another alias 

So, check, before you get to the step of exporting your /Exchange settings, make sure you first clear the FBA checkbox. This box is under:

Start > All Programs > Microsoft Exchange > Exchange System Manager

Servers > (Your Server) > Protocols > HTTP

Right click on Exchange Virtual Server

Click on Settings, uncheck Enable Forms Based Authentication.

Follow the rest of kb817379 article to create exchange-oma, setup a new MasSync registry key, etc. FYI, SBS uses the same aliased virtual directory as mentioned in the kb article so if you’re having issues with this error you might want to follow the KB with this slight tweak to recreate it.  

Both comments and pings are currently closed.