[horde] Activesync | WP7 cannot sync

[Michael J Rubinsky]

Quoting Martin Hochreiter <linuxbox at wavenet.at>:

> We see problems of the newer WP phones on other active sync  
> (alternative) implemenations too.
> I dont know where microsoft is heading with that, but unfortunately  
> (for you guys) the number of newer wp7 phones rises ...

Yeah, the whole ActiveSync landscape is pretty messed up if you ask  
me. Different vendors supporting slightly different implementations of  
the protocol, with even Microsoft doing things differently than what  
is documented in their own documentation. Still, IMO, it's probably  
the best sync option we have at the moment.

I tried to allow turning off all of what I call the "extended"  
policies - things like requiring alphanumeric pins vs numeric, number  
of attempts before wipe - and just sending the "require a PIN" policy  
but this screws up ALL of my Android test devices, including the  
Galaxy Nexus with ICS - as they won't require a PIN at all if they  
don't receive a specifier as to what type of PIN to require. So I have  
reverted this change. This, by the way, is also not quite to spec  
either. FWIW, as you have found, other non Microsoft EAS  
implementations have major issues with provisioning. ZPush, for  
example, only send a very bare-bones policy string for EAS 2.5 - which  
also breaks Android requiring a PIN and has issues with remote wipe on  
a number of newer devices. At least with our current implementation,  
we get *most* devices to properly provision and wipe.

So, I see two options here:

(1) Try to track down *exactly* what policies we are sending that WP7  
is unhappy about and device-sniff. We already do a small amount of  
device sniffing to deal with early Android version issues. If you have  
tried the previous suggestion I gave you to set the codewordfrequency  
value to 0 (numeric, not string) and it still did not work, then there  
is obviously more that WP7 does not like than what is listed in the KB  
article. If we can find out exactly which policies are causing the  
problem, I can work around it.

(2) Add WP7 to the list of "hasBrokenProvisiong" devices. This will  
cause all WP7 devices to NEVER be provisioned if using  
PROVISIONING_LOOSE. If set to PROVISIONING_FORCE, the devices that  
exibit this behaviour will never be able to connect (as you are seeing  
now). Of course, using PROVISIONING_NEVER will work with any device -  
but will not allow for remote wipe or security policies.

(2) is definitely the easiest to implement and is the right thing to  
do if we want to only support exactly what the documentation says.  
That being said, we already work around a *lot* of vendor specific  
client issues. Otherwise, we would have a very, very small list of  
working clients.

So, I'd really like to do (1), but other than the fact that I don't  
have a WP7 device to test against, it feels like in our current code  
base, it would be a slipperly slope that could end in all types of  
ugly device/version checks throughout the code.

I think what I'm going to do is implement (2) for now, and then  
implement (1) in the future, after I've refactored things a bit. I've  
already started some rudimentry planning on implementing a device  
class to wrap all of these types of device-specific behaviour.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org