On Sun, 2016-10-23 at 19:11 +0100, Graham Cobb wrote:
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.
Thanks for the wiki update, that has already helped one person - myself!
I've signed up for a hosted Exchange 2016 service and (re-)enabled that
in the nightly testing, replacing gconftool-2 commands with gsettings
commands as per your instructions in the wiki.
I am using the policy-key workaround, but haven't actually verified
whether it is needed. With the work-around, I am running into a problem
basically any attempt to create some item on the Exchange server fails with an error code
12 = GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync error:
Mailbox folders are not synchronized, need FolderSync first
Here's a snippet from the activesyncd.log:
(process:111:0xf61d090): libeas-DEBUG:> POST
(process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033
(process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 (0xf623b90),
SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0)
(process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00
(process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK
(process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034
(process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 (0x147a7170)
(process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private
(process:111:0xf61d090): libeas-DEBUG:< Content-Type: application/vnd.ms-sync.wbxml
(process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++
=== dump start: xml_len  ===
<!DOCTYPE ActiveSync PUBLIC "-//MICROSOFT//DTD ActiveSync//EN"
=== dump end ===
That is with your "workround folder sync when server loses state" patch
Any idea how to proceed with this? Is the policy-key workaround perhaps
not working as intended?
There are a few things that it might be nice to do one day (i.e.
never happen :-) )...
I have a similar list ;-}
1) The whole gsettings stuff should be hidden from the users, with
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.
The envisioned solution was some kind of external account setup, with
SyncEvolution completely hidden. All of these points would fit into such
a setup helper.
As it stands now, SyncEvolution is just some infrastructure component of
a larger system, with a command line for power users. The only problem
is that this larger system has never been implemented for most desktop
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.