StatusException: ExportChangesICS->InitializeExporter(): Error, mapi_exportchanges_config() failed: 0xFFFFFFFF8004010F
-
Alright. I removed the account from the device and then from the server, rebooted the device and created the account again on the device. I sent you that log again as a message.
Looking forward to your analysis.Thank you.
-
Hi kg,
@kg said in StatusException: ExportChangesICS->InitializeExporter(): Error, mapi_exportchanges_config() failed: 0xFFFFFFFF8004010F:
Alright. I removed the account from the device and then from the server, rebooted the device and created the account again on the device. I sent you that log again as a message.
By “then from the server” do you mean that you removed the device using z-push-admin? If not, please do that before creating the account again.
It looks like you’re trying to sync 1 week back and there are more than 7000 items in the inbox for that time, is it correct? Did you try to reduce the sync window to 3 days or 1 day?
How many users are on the system?
Manfred
-
Hey Manfred,
@Manfred said in StatusException: ExportChangesICS->InitializeExporter(): Error, mapi_exportchanges_config() failed: 0xFFFFFFFF8004010F:
By “then from the server” do you mean that you removed the device using z-push-admin?
Yes, thats exactly what I did.
It is correct, the device tries to sync one week of emails, but that one week of emails is only ~100 emails (I checked it in the Webapp). The 7000 items is the total number of emails in the inbox which are from May 2017 onwards.I haven’t tried to reduce the window to less days, but will do so and report back.
There are 14 users on that system: Most of them have a total store size of less than 10MB, 6 of them have a total store size between 200 and 1000MB.
The user that I sent you the log of has a total store size of 400MB.Thank you
-
I reduced the sync window on the client to 1 day (the lowest possible one), but the picture is still the same: The same error is reported for every request and the wbxml log looks the same (at least to me) as well.
z-push-admin is still reporting that it tries to sync the whole folder:
Synchronization progress: Folder: Posteingang Sync: Initialized Status: 0% (0/7135)
For reference: the complete output of z-push-admin -a list -u USER
----------------------------------------------------- DeviceId: androidc769649512 Device type: Android UserAgent: Android-Mail/8.11.25.224448671.release Device Model: TA-1053 Device friendly name: TA-1053 Device OS: Android 8.1.0 ActiveSync version: 14.1 First sync: 2019-01-24 13:37 Last sync: 2019-01-24 15:10 Sync Period: unlimited (0) Total folders: 33 Short folder Ids: Yes Synchronized folders: 1 (1 in progress) Synchronized data: Emails Synchronization progress: Folder: Posteingang Sync: Initialized Status: 0% (0/7135) Additional Folders: none Status: OK WipeRequest on: not set WipeRequest by: not set Wiped on: not set Policy name: default Attention needed: No errors known
-
Hi kg,
As mapi_exportchanges_config() call is failing, it might be the core or the store issue. Maybe you could try to unhook his store and hook it again.
Also maybe the ICS log in KC would help. In the server.cfg of kopano set
log_level = 0x00200000
If you already have some log_level set, then sum the values (e.g. if log_level is 3, then set it to 0x00200003).
Manfred
-
I unhooked the store and hooked it in again - no change.
I also enabled the ICS log, which is very verbose. It produces a lot of lines like these:Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43279A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43279A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43269A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43269A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43259A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43259A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43249A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43249A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43239A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43239A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43229A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43229A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43219A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43219A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C43209A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C43209A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C431F9A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C431F9A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C431E9A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C431E9A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C431D9A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C431D9A00000000, changetype=4097 Thu Jan 24 16:22:43 2019: [ 200000] Processing: 03C31F4DB8E84DA0B6108B4EA93D8C431C9A00000000, match=1 Thu Jan 24 16:22:43 2019: [ 200000] FirstSyncAccepted: sourcekey=03C31F4DB8E84DA0B6108B4EA93D8C431C9A00000000, changetype=4097 Thu Jan 24 16:22:44 2019: [ 200000] K-1200: sourcekey=, syncid=425074, changetype=1, flags=46 Thu Jan 24 16:22:44 2019: [ 200000] MatchRestrictions: matching 1000 rows
Anything specific that I can look for in there?
-
Hi kg,
I’m not very familiar with the internals of the core, so unfortunately I can’t help you with that.
If you have a valid subscription, you can open a support case with Kopano.
Otherwise you can open a thread at https://forum.kopano.io/category/15/kopano-groupware-core section as I’m not sure how often the core devs check posts here.
Manfred
-
Thank you @Manfred for your help on this one.
I opened a topic in the Kopano Core section. Let’s see, if somebody is able to help me to debug this further.
-
Hi, is the problem already solved? Any information about the root cause? I have exactly the same behavior on my system.
-
Same problem here. On my mailbox it is reproducable with the sent items folder. I removed all but 300 mails and it syncs fine. Putting some older mails into this folder (e.g. 2.500 mails) z-push errors out despite setting timeframe to 1 week, 3 days or even 1 day.
Same seems to be the case for calendar.
Still investigating this.On my site this is latest z-push with latest kopano core.
-
I was able to resolve it by replacing the underlying database of the Kopano-Core. We’ve been using a MariaDB Galera Cluster and after replacing it with a single instance of MySql, it started working fine again.
-
Finally it seems that unhooking and hooking the store of the user again solved these kind of error - crossing fingers…
-
Unfortunately after a few days the same problems reoccurred :-(
Yesterday i did move my database from mariadb to mysql which (it seems again) did fix all these kind of errors.
See here: https://forum.kopano.io/topic/2269/z-push-2-4-5-sync-issue-0xffffffff8004010f/3
(Dont want to cross post). -
Hello,
I ran into the same problem and I can confirm switching to MySQL 8.0.15 solves this issue.
Debian_testing, MariaDB 10.3.13, z-push 2.6.0.alpha , Kopano 8.7.80.926.
So I guess raising a ticket makes sense here.BR.
-
I configured in kopano’s server.cfg
from: enable_enhanced_ics = yes
to: enable_enhanced_ics = noand restarted kopano-server. Now it works with maria-db.
-
Please continue discussion in https://forum.kopano.io/topic/2269/z-push-2-4-5-sync-issue-0xffffffff8004010f