Re: Configuring Activesync in SyncEvolution 22.214.171.124
On Sat, 2014-10-18 at 15:36 +0100, Graham Cobb wrote:
> On 15/09/14 16:19, Patrick Ohly wrote:
> > About 126.96.36.199
> > ==============
> > This is the first release candidate for 1.5. No further changes are
> > planned except for fixing yet-to-be-discovered bugs - so find them
> > now!
> The (new in this release, I think) checking for mixing shared/unshared
> properties is causing me some logical confusion. Here is (the outline
> of) how I used to configure my Exchange server config:
> 1) Remove the existing configurations
> 2) syncevolution --configure --template none backend=eas-contacts
> database=Contacts username=my-account-name <at> Exchange contacts
> 3) syncevolution --configure --template none username=my-account-name
> password= printChanges=1 loglevel=4 target-config <at> Exchange
> 4) syncevolution --configure sync=two-way uri=contacts loglevel=4
> target-config <at> Exchange contacts
> The second step now gives the error:
> [ERROR] per-peer (unshared) properties not allowed: username
> If I remove the username, it gives the error:
> [ERROR] contacts: backend failed: fetching folder list:
> GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find
> account 
That's the expected behavior, and hasn't changed in the 188.8.131.52 release
candidate. The new terminology did not change the implementation, just
In this case the problem is that " <at> Exchange" refers to a context, not a
sync config, and only sync configs have a username property. You could
use "databaseUsername" instead (however, I am not 100% sure whether the
ActiveSync backend supports that - WebDAV does), if you don't mind
repeating that for each source, ahem, datastore.
Or you do as you said yourself and configure the
"target-config <at> Exchange" sync config. When invoking item operations,
remember to use "target-config <at> Exchange" and not just " <at> Exchange",
because SyncEvolution will not automatically use the "target-config"
sync config to find username/password.
> The only way I can get it to work is if I bring step 3 to be in front of
> step 2. That works, but feels wrong (it also breaks my scripts in a
> hard to fix way, but that is my problem).
Are you sure it used to work?
I checked with 1.4.1, and it fails the same way.
> It feels like there should be
> one of two cases:
> i) The context ( <at> Exchange) is associated with a particular account. In
> that case, the account id should be a property on the context, not on
> some peer.
No, contexts are primarily a collection of sources. These sources can be
used in combination with a sync config which then can have additional
properties (username/password, proxy settings), but that's not required.
> ii) The context ( <at> Exchange) is generic for several activesync accounts
> (different users), in which case the folder mappings cannot be checked
> at the time they are set up. Not very user friendly.
The context could be used like that, starting with 184.108.40.206. Instead of
"target-config", user "user1", "user2", etc. with different account
settings, then pick those when configuring sources and local sync. The
new thing in 220.127.116.11 is that local sync works with target configs not
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.