Tuesday, August 01, 2006

Problems with Exchange server Activesync and Windows

Workaround - Problems with Exchange server Activesync and Windows
Mobile 5.


Windows Mobile 5.0 ActiveSync connection to Exchange 2003 via Orange or O2 GPRS network in the UK (may also be seen on other networks)

Error code 0x8503001A appears during sync and sync fails Exchange SP2 applied Sync works fine locally using Wifi or remotely via cradle/usb/internet link
Windows Mobile 2003 works fine in all cases Forms Based Authentication has been enabled at some point, with http compression.

After many hours of troubleshooting, I have found a workaround to the 0x8503001A sync problem that many people are experiencing.

The answer is that HTTP compression is enabled for Activesync in the IIS Metabase when SP2 is installed, and in conjunction with a (presumed) bug in Exchange where the IIS Metabase configuration is not
restored to previous settings after turning off FBA High compression,
causes the above problem.

These instructions will restore Activesync functionality for those
experiencing the issue.

First make a backup of the MetaBase:

Open IIS Manager Right click on server->AllTasks->Backup/Restore Configuration...
Click Create Backup
Give the backup a name (e.g. 'Backup before fix')
Click OK, Close

Then enable direct Metabase Edit

Open IIS Manager Right click on server and go to Properties
Check "Enable Direct Metabase Edit"
Click OK


Look for

IIsWebVirtualDir Location="/LM/W3SVC/1/ROOT/Microsoft-Server-ActiveSync"
and just below it, you will see:


Change both of these to FALSE (NB there are more of these throughout the METABASE.XML file, be sure only to change these two)

Save the Metabase.xml file back and restart IIS: Start->Run->IISRESET



Further information... In Metabase.xml, SP2 changes the above settings from FALSE to TRUE for ActiveSync. Presumably Compression is disabled overall until you enable FBA with Compression. The following line in
the METABASE.XML file acts as an overall ON/OFF switch for compression and also has the effect of providing a workaround (at the expense of losing http compression elsewhere, e.g. for OWA):

Look for the line HcNoCompressionForHttp10="FALSE"
Change FALSE to TRUE (the setting before enabling FBA with compression)

If you don't want OWA/FBA with any compression, I would safely assume you want to change the above line.

In fact, I would suggest that the Compression setting under Forms Based Authentication should be independently settable (not as a sub-option to FBA!)

There is a bug in all versions of Exchange which means once that
compression is enabled, disabling via the FBA screen doesn't reverse
the changes completely (as an SP2 install on a system that NEVER had FBA/compression enabled, will still function correctly).

The question for Microsoft is, how are compressed HTML packets getting corrupted by the mobile networks - obviously some NAT/Transparent Proxy in the way, but it's a weird one... And needs fixing (as well as the
"disabling compression doesn't actually do it" bug)!

No comments: