On 23/10/16 15:51, Graham Cobb wrote: > I don't think that is a regression in this version (I guess the previous > 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
