Annoying problem with two new windows mobile 2005 devices. One a pocket pc xda exec (htc universal) and one a smartphone (imate sp5).
Talking about the pocketpc here but they both give the same error when I try and sync with exchange over gprs.
Result: synchronization could not be compelted. try again later support code: 0x8503001A
I can't find that support code anywhere on the microsoft site :/ The verbose logs on the device don't show anything odd and the logs on the exchange server aren't yielding any clues.
I've tried saying dont sync contacts or calendar etc.. all combinations to rule out bad data but no luck.
What's even more odd is that a) it works over wifi and b) all my windows mobile 2003 devices work absolutely fine with the same settings :/
anyone any ideas? at the moment I have to say windows mobile 2005 syncing seems *very* flaky :/
>Annoying problem with two new windows mobile 2005 devices. One a pocket >pc xda exec (htc universal) and one a smartphone (imate sp5).
>Talking about the pocketpc here but they both give the same error when >I try and sync with exchange over gprs.
>Result: >synchronization could not be compelted. try again later >support code: 0x8503001A
>I can't find that support code anywhere on the microsoft site :/ The >verbose logs on the device don't show anything odd and the logs on the >exchange server aren't yielding any clues.
>I've tried saying dont sync contacts or calendar etc.. all combinations >to rule out bad data but no luck.
>What's even more odd is that a) it works over wifi and b) all my >windows mobile 2003 devices work absolutely fine with the same settings >:/
>anyone any ideas? at the moment I have to say windows mobile 2005 >syncing seems *very* flaky :/
I've had no problems. Have you tried giving them a soft reset? Are you using any self-signed security certificates (ie those not issued by one of the commercial companies, but by yourself or your corporation)? Can you connect to the site using Pocket IE over GPRS?
-- Rob Borek Microsoft MVP - Mobile Devices Want *ONE ON ONE* support? http://www.pocketpcone2one.com Please place all replies into the newsgroup so that others can benefit.
Hi, Please make sure that the host name (fqdn) is the same for the internal network as it is for the external network. That way the O2 XDA Exec can find the Exchange server using the same name in both cases.
> Annoying problem with two new windows mobile 2005 devices. One a pocket > pc xda exec (htc universal) and one a smartphone (imate sp5).
> Talking about the pocketpc here but they both give the same error when > I try and sync with exchange over gprs.
> Result: > synchronization could not be compelted. try again later > support code: 0x8503001A
> I can't find that support code anywhere on the microsoft site :/ The > verbose logs on the device don't show anything odd and the logs on the > exchange server aren't yielding any clues.
> I've tried saying dont sync contacts or calendar etc.. all combinations > to rule out bad data but no luck.
> What's even more odd is that a) it works over wifi and b) all my > windows mobile 2003 devices work absolutely fine with the same settings > :/
> anyone any ideas? at the moment I have to say windows mobile 2005 > syncing seems *very* flaky :/
I DO have a self signed cert on exchange but I knew that would be an issue with WM5 and so at the moment I'm simply trying non-ssl syncing.
I CAN connect to owa with pocket IE over gprs I can also sync WM5 over wifi, over usb cable into my desktop (and from there to exchange) WM2003 all works fine too.
the only thing that doesn't work is wm2005 syncing over gprs to exchange
The fqdn is indeed the same internally and externally. Proper old fashioned routed IP behind the name.
I'm struggling to see what else could be different between syncing over wifi and syncing over gprs unless something changed on wm2005 that the gprs providers don't allow through :/
> The fqdn is indeed the same internally and externally. Proper old > fashioned routed IP behind the name.
> I'm struggling to see what else could be different between syncing over > wifi and syncing over gprs unless something changed on wm2005 that the > gprs providers don't allow through :/
On 6 Nov 2005 03:20:38 -0800, Keit...@gmail.com wrote:
>Hi Rob,
>I DO have a self signed cert on exchange but I knew that would be an >issue with WM5 and so at the moment I'm simply trying non-ssl syncing.
>I CAN connect to owa with pocket IE over gprs >I can also sync WM5 over wifi, over usb cable into my desktop (and from >there to exchange) >WM2003 all works fine too.
>the only thing that doesn't work is wm2005 syncing over gprs to exchange
There are no errors showing up on the server? Can you connect from off-site wifi networks (ie your wifi network at home)?
-- Rob Borek Microsoft MVP - Mobile Devices Want *ONE ON ONE* support? http://www.pocketpcone2one.com Please place all replies into the newsgroup so that others can benefit.
Keit...@gmail.com wrote: > yep I've tried FQDN (that's what I've always used on wm2003) > Then I tried IP address etc. too... all of which gave the same error > message.
> It does seem to reach the server, it says:- > synchronizing folders > synchronizing contacts 0/63
> then throws up: > Result: > synchronization could not be compelted. try again later > support code: 0x8503001A
> If I tell it not to sync contacts (in case of bad data) then it says > email 0/200 and does the same. Basically it won't sync any data.
> Switch to wifi and everything works perfectly with all the same > settings. > Use win2003 ppc and again, perfectly even over gprs.
> Is there anywhere I can find an explanation of that 0x8 support code? > Talk about using obscure error codes :/
ok well after spending all night with several exchange servers trying all the options, a colleague sorted it out.
By applying different options and watching the difference between a working server and a non-working one, he isolated the settings in metabase.xml which when changed, caused this annoying support code.
It was activesync compression enabled via FBA in the first instance... so turn compression onto say high on fba, then sync.... worked over everything except GPRS (on UK networks O2 and Orange at least, which were the only ones we could test with).
Turning both static and dynamic compression to FALSE immediately fixed the issue.
It leaves the question why doesn't compression work? could it be a UK GPRS network issue perhaps.... don't know yet.
Anyway it all makes sense since compression was something that we know ms messed with for wm2005 and will start becoming more important with the always on http connection for push email.
So not perhaps fixed, but at least patched for the time being.
Thanks all for the help.... not an easy one to diagnose locally never mind remotely
Mauricio Freitas [MVP] wrote: > I am running WM5 (multiple devices) and SP2 without a problem.
> Are you sure your GPRS configuration allows HTTPS connections?
Hi, I'm the one (another Keith!) who's tracked this issue down with Keith's help..
This is not related to HTTPS.
Try this to see if it breaks your setup:
Enable FBA with High Compression. Restart IIS (start->run->iisreset)
Try connecting again, you may get 0x85010014 if you require ssl. Turn off FBA and restart IIS again. If High Compression remains enabled in IIS then (at least in the UK) WM5 server activesync fails with the 0x8503001A error.
I have full details to resolve this issue once it occurs.
Whats the best way for us to report this issue to Microsoft?
Keith Hall has a detailed log of what happens and when, how to fix etc. and knowing Microsoft are focussed on push email, wm2005 messaging and security package etc., it would be good to let them know about this.
> Whats the best way for us to report this issue to Microsoft?
> Keith Hall has a detailed log of what happens and when, how to fix etc. > and knowing Microsoft are focussed on push email, wm2005 messaging and > security package etc., it would be good to let them know about this.
Workaround - Problems with Exchange server Activesync and Windows Mobile 5.
Facts:
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->All Tasks->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
Load notepad and open C:\WINDOWS\SYSTEM32\INETSRV\METABASE.XML
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
Enjoy!
------------
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)!
This all sounds extremely familiar!!! I too switched on FBA and SSL and then switched them off. I am now getting the 85010014 error continuously, even after following the steps in this thread regarding editing the metabase. Any thoughts?
One other thing - the sync fails using USB syncing as well as GPRS
Keith Hall wrote: > Workaround - Problems with Exchange server Activesync and Windows > Mobile 5.
> Facts:
> 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->All Tasks->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
> Load notepad and open C:\WINDOWS\SYSTEM32\INETSRV\METABASE.XML
> 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
> Enjoy!
> ------------
> 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)!
Joe wrote: > I had same Error code 0x8503001A on a Sprint Windows 5.0 Phone and > Exchange 2003 Service Pack 2. I followed the directions and worked > like a charm!
> Regards,
> Joe
> Keith Hall wrote: > > Workaround - Problems with Exchange server Activesync and Windows > > Mobile 5.
> > Facts:
> > 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->All Tasks->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
> > Load notepad and open C:\WINDOWS\SYSTEM32\INETSRV\METABASE.XML
> > 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
> > Enjoy!
> > ------------
> > 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)!
With o2 (don't know about Orange) data is optimized as standard over the Mobile Web GPRS connection. Is it possible that both lots of compression are conflictiong? If you use bypass as the username and password as the password for your GPRS connection this will bypass the optimization. aybe this will solve the issue. I do not have the equipment to test but it is just a thought. -- Regards,
"Keit...@gmail.com" wrote: > ok well after spending all night with several exchange servers trying > all the options, a colleague sorted it out.
> By applying different options and watching the difference between a > working server and a non-working one, he isolated the settings in > metabase.xml which when changed, caused this annoying support code.
> It was activesync compression enabled via FBA in the first instance... > so turn compression onto say high on fba, then sync.... worked over > everything except GPRS (on UK networks O2 and Orange at least, which > were the only ones we could test with).
> Turning both static and dynamic compression to FALSE immediately fixed > the issue.
> It leaves the question why doesn't compression work? could it be a UK > GPRS network issue perhaps.... don't know yet.
> Anyway it all makes sense since compression was something that we know > ms messed with for wm2005 and will start becoming more important with > the always on http connection for push email.
> So not perhaps fixed, but at least patched for the time being.
> Thanks all for the help.... not an easy one to diagnose locally never > mind remotely
Ce problème s’applique uniquement aux utilisateurs Windows Mobile 5 qui veulent synchroniser avec un Exchange 2003 (qui a été mise à jour par le SP2) et ce via GPRS.. car via Wifi, il n’y a aucun problème.
Le code erreur est 0x8503001A et est du à un problème de compression. La compression dynamique ainsi que statique étaient désactivées avant l’application du SP2, mais le SP2 active ça et voilà notre problème !!
Peut-être encore un bug de WM5 d'après ce que j'ai compris, WM5 gère mal la compression HTTP..
Alors pour contourner le problème, voici la solution :
Tout d’abord, faire un backup de la Metabase Ouvrir IIS Manager Cliquez droit sur Server->All Tasks->Backup/Restore Configuration Cliquez « Create backup » Entrez un nom style « Backup avant fix » Cliquez OK, fermez
Ensuite activer la possibilité d’éditer la Metabase pendant qu’IIS tourne : Ouvrir IIS Manager Cliquez droit sur Server et choisissez « Properties » Activez « Enable Direct Metabase Edit » Cliquez ok
Ouvrir avec Notepad le fichier suivant C:WINDOWS;SYSTEM32;INETSRV;METABASE.XML
Cherchez <IIsWebVirtualDir Location="/LM/W3SVC/1/ROOT/Microsoft-Server-ActiveSync"> et juste en dessous vous verrez:
"Andrew Newell" wrote: > With o2 (don't know about Orange) data is optimized as standard over the > Mobile Web GPRS connection. Is it possible that both lots of compression are > conflictiong? If you use bypass as the username and password as the password > for your GPRS connection this will bypass the optimization. aybe this will > solve the issue. I do not have the equipment to test but it is just a thought. > -- > Regards,
> > ok well after spending all night with several exchange servers trying > > all the options, a colleague sorted it out.
> > By applying different options and watching the difference between a > > working server and a non-working one, he isolated the settings in > > metabase.xml which when changed, caused this annoying support code.
> > It was activesync compression enabled via FBA in the first instance... > > so turn compression onto say high on fba, then sync.... worked over > > everything except GPRS (on UK networks O2 and Orange at least, which > > were the only ones we could test with).
> > Turning both static and dynamic compression to FALSE immediately fixed > > the issue.
> > It leaves the question why doesn't compression work? could it be a UK > > GPRS network issue perhaps.... don't know yet.
> > Anyway it all makes sense since compression was something that we know > > ms messed with for wm2005 and will start becoming more important with > > the always on http connection for push email.
> > So not perhaps fixed, but at least patched for the time being.
> > Thanks all for the help.... not an easy one to diagnose locally never > > mind remotely
We have now tried this with server compression on and o2 GPRS Web compression off. This worked with no issues. The problem seems to occur when both lots of compression are on; they must be conflicting. So it works when you turn either off and leave the other on.
GPRS traffic is compressed as standard when using the mobile.o2.co.uk APN on the o2 network. To turn it off use 'bypass' as your username and 'password' as your password in the connection settings for the connection to the APN.
I am fairly sure Orange compress data when using there GPRS connection but I am not sure how to disable. -- Regards,
"Andrew Newell" wrote: > With o2 (don't know about Orange) data is optimized as standard over the > Mobile Web GPRS connection. Is it possible that both lots of compression are > conflictiong? If you use bypass as the username and password as the password > for your GPRS connection this will bypass the optimization. aybe this will > solve the issue. I do not have the equipment to test but it is just a thought. > -- > Regards,
> > ok well after spending all night with several exchange servers trying > > all the options, a colleague sorted it out.
> > By applying different options and watching the difference between a > > working server and a non-working one, he isolated the settings in > > metabase.xml which when changed, caused this annoying support code.
> > It was activesync compression enabled via FBA in the first instance... > > so turn compression onto say high on fba, then sync.... worked over > > everything except GPRS (on UK networks O2 and Orange at least, which > > were the only ones we could test with).
> > Turning both static and dynamic compression to FALSE immediately fixed > > the issue.
> > It leaves the question why doesn't compression work? could it be a UK > > GPRS network issue perhaps.... don't know yet.
> > Anyway it all makes sense since compression was something that we know > > ms messed with for wm2005 and will start becoming more important with > > the always on http connection for push email.
> > So not perhaps fixed, but at least patched for the time being.
> > Thanks all for the help.... not an easy one to diagnose locally never > > mind remotely
|
