On 23/10/16 15:51, Graham Cobb wrote:
I don't think that is a regression in this version (I guess the
version has the same problem), although until I can work out exactly
what is happening I can't be sure. I will look into it a little further
but I may not be able to fix it before I go on holiday. It might even
require proper protocol version handling (which we have avoided so far
-- see an earlier thread about EAS versions some time ago).
The problem turned out to be PolicyKey related (I hate "provisioning").
This exchange server seems to handle the need for provisioning
differently and doesn't send the 449 status unless you send a bad PolicyKey.
The workround is to make sure that the policy-key is configured in the
account gsettings. Any non-null value will do, including 0. This
triggers provisioning, which will end up eventually with a valid PolicyKey.
I have updated the wiki page to include setting that.
There are a few things that it might be nice to do one day (i.e. will
never happen :-) )...
1) The whole gsettings stuff should be hidden from the users, with some
way to pass the necessary parameters from syncevolution.
2) I suspect that provisioning is now being triggered every time
activesyncd is restarted as loading the account details from gsettings
means activesyncd thinks the policy key has changed when it hasn't
really. We rely on this to get it set correctly the first time, but we
ought to find a way to work out that it hasn't actually changed.
3) The creation of Office365 means that for users using that service,
all the required parameters (except password) can be defaulted sensibly
if we know the email address. Maybe we should allow the case of
specifying an account which has not been set up in gsettings to use the
account name as an email address and then use the Office365 defaults.