Z-Push 2.6.1 - Outlook 365 not synching any more ( stuck)

Pax

@fbartels said in Z-Push 2.6.1 - Outlook 365 not synching any more ( stuck):

@pax did you see the reply in https://forum.kopano.io/post/19174?

The mentioned fix is https://stash.z-hub.io/projects/ZP/repos/z-push/pull-requests/873/overview (as this cannot be seen in Jira without being logged in)

Hey Felix i’ve ssen your post but unfortunately reverting back to Z-Push 2.5.2 doesnt make a difference.
Is there a way to revert, edit, or correct the “mapiprovider.php” mentioned? Do you know where it is stored under Ubuntu?

fbartels

@pax did you also trigger a resync? I am not really involved in the topic, but had the feeling Manfreds reply got under as in my eyes it lists what needs to be done.

The file is by default located in /usr/share/z-push/backend/kopano.

petervbeck

Hi there,

We’re also having issues with stucked calendar syncs (Kopano Stable/supported, just downgraded from Z-Push 2.6.1 to 2.5.2, Outlook 2013/2016 on premise).
What has to be changed in mapiprovider.php to fix that issue ?

Thanks
Peter

Pax

--------Solution: --------
a simple edit of z-psuh mapiprovider
Ubuntu users will find the mapiprovider.php in /usr/share/z-push/backend/kopano as mentioned by Felix.

make a backup of that file

cp /usr/share/z-push/backend/kopano/mapiprovider.php /usr/share/z-push/backend/kopano/bak-mapiprovider.php

Edit the mapiprovider.php.
Look for:

if (isset($row[PR_RECIPIENT_TYPE])) {
                $attendee->attendeetype = $row[PR_RECIPIENT_TYPE];

change it to:

if (isset($row[PR_RECIPIENT_TYPE])) {
                $attendee->attendeetype = $row[PR_RECIPIENT_TYPE] != 0 ? $row[PR_RECIPIENT_TYPE] : MAPI_TO;

simply close and restart Outlook afterwards (a full resync was not necessary but hey it doenst do any harm either)

voila its working now (tested with Z-Push 2.5.2 and 2.6.1)

FUNFACT: I made this change with my downgraded Z-Push 2.5.2 after that I installed the updated 2.6.1 with apt-get install. The update reverted my edit on the mapiprovider.php and I had to redo them. So be aware of that.

@fbartels @Manfred
Sorry this was a big misunderstanding. I hadnt a Jira account so I didnt see the changes of that file. And I didnt know where to find it either.
But for you information. Reverting to Z-Push 2.5.2 and doing a full resync of Outlook isnt the solution. You have to edit the mapiprovider.php as mentioned.

AnotherAndy

Hi @pax ,
I also had no jira account and didn’t see the fix :-( - thanks so far, I am not sure what I will do now, because currently its working…
br
Andreas

HPH_ZForum

Hello,

many thanks for the fix!

Other possible solutions, such as deleting items that were hanging in loop detection, deleting possibly problematic contacts or appointments via WebApp, setting up Outlook with a new profile again, resync etc. did not lead to anything.

After changing the PHP file, however, we actually had to trigger a complete resync via KOE, because otherwise the connection indicator in Outlook showed connection problems.

A permanent fix will also be available for Kopano4UCS with the directly integrated Kopano repos, I assume?

BR,
HP

Manfred

Hi @anotherandy said in Z-Push 2.6.1 - Outlook 365 not synching any more ( stuck):

my z-push.log shoes this entries while he tries to sync the calendar:
17/01/2021 14:27:13 [29419] [WARN] [andreas] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve user: not found (8004010f)
…
my kopano-server.log shows:
Sun Jan 17 14:16:22 2021: [warning] K-1515: Object not found unknown user “andreas@xxx.de”: andreas@xxx.de not found in LDAP

I guess it happens because your login name is “andreas” while mapi_zarafa_getuser_by_name tries to resolve “andreas@xxx.de”. From Z-Push point of view that’s not a big issue as there’s a fallback code to get the user. I guess the warning in server.log was also caused by mapi_zarafa_getuser_by_name.

Manfred

Manfred

Hi all,

it looks like even with Z-Push 2.5.2 the fix from https://jira.z-hub.io/browse/ZP-1603 is required (which makes sense as there already might be calendar items in the store for which this is required), so we’ll discuss the possibility to push this change into the final repository and provide the hot-fixed 2.6.1 version so that the downgrade is not necessary.

Manfred

AnotherAndy

thx @manfred you’re right, my login name is andreas.
Can I fix this setting that he does not search for the email but for the username?

Info @ all - if you make an upgrade from z-push 2.5 to 2.6 the fix need to be done again!
The update overwrites the
/usr/share/z-push/backend/kopano# vi mapiprovider.php
br
Andreas

Manfred

Hi all,

we have released Z-Push 2.6.2 which should fix the issue.

Manfred

AnotherAndy

@manfred Thanks! I just upgraded to 2.6.2 and everything works fine.
br
Andreas