Hi,

case closed.
Deleting all permissions for shared calendar and also deleting permission “folder visible” for the mailbox folder.
Restart of complete kopano server and create the appropriate permissions it works.

Ulrich

zarafaclient-7.2.6-52190.msi: https://www.dropbox.com/s/anjwaks279n23fj/zarafaclient-7.2.6-52190.msi?dl=0
zarafaclient-en-7.2.6-52190.msi: https://www.dropbox.com/s/1ldto4s8ikzvmgo/zarafaclient-en-7.2.6-52190.msi?dl=0

@piechota1989

it is stated at the top of the community forum

https://forum.kopano.io/topic/3738/packages-and-services-available-under-new-locations

that the location for z-push changed last year

rg
Christian

@divb We get that from time to time and it is usually due to an expired password. Go to Control Panel, search for the mail widget and click on accounts. After you are in the accounts page, just double click on the kopano account and the sever configuration window will open. Just type in the password, save and close the window. Close control panel app and go to outlook. It should work.

@externa1 thanks for that right hint!!!

To workaround this problem you can add the string variable

general.useragent.override

in the Thunderbird config editor. A value with

Lightning

somewhere in it will solve the problem.

Hi @klausf,

yes, the project is still active. There just isn’t a lot of feedback anymore.

The debian package is on our todo list, but I don’t have any estimation for its official release yet.

Manfred

I had the same problem when using roaming profiles. I made the profile ‘local’ on the second (least used) pc and created a new Outlook profile for that PC.

Hi, Manfred,

thank you for your reply and sorry for the long time I didn’t reply.
At this time in August we used partially ActiveSync/ KOE with z-push and the still working MAPI in old Zarafa mode in parallel.
Meanwhile we changed a lot and now its working correctly, although we’re not aware which change was the reason for the result. I even wouldn’t be able to reconstruct the former situation.
Regarding the title, you are right: Of course, a from-address was shown, but in fact the primary mail address of the user, which was supposed to be the wrong one.

Peter

Hi @t-wirmer,

sadly that is a functionality that Microsoft did not implement for ActiveSync accounts.

A potential workaround that I have used in the past is to define individual “quick steps” for the individual followup steps.

The 500 Internal Server Error is the general catch all error when the server throws an exception. The first thing you need to know about an “Internal Server Error” is that the error can only be resolved by fixes to the Web server software. It is not a client-side problem meaning that the problem is not with your browser, your computer, or your internet connection. There are a number of causes for a 500 Internal Server Error to display in a web browser. Consider some debugging tips to help diagnose and fix common causes of this problem.

Refresh the URL that you have requested. The error may be for the short term. Clear all the website cache from your web browser Delete website cookies because error 500 can be obstructed by clearing the website cookies. Restart your web browser after clearing cookies. Create a new .htaccess file. Sometimes the incorrect code and command in .htaccess file cause error 500 on the website. Rename the file with another name; it will automatically become invalid. Then create a new .htaccess file and upload it to the server. Finally, Ask your Hosting Provider

Hello @nils50122 ,

have you made an internal test?

https://hostname-or-ip-address:8444/caldav/user
https://hostname-or-ip-address:8444/caldav
https://hostname-or-ip-address:8444/ical

You can also check from another another (internal) computer with:

nc -v -z hostname-or-ip-address 8444

Should result: “Connection to localhost 8444 port [tcp/*] succeeded!”

Maybe temporarily increasing the log-level in /etc/kopano/ical.cfg will also give you more hints.

Regards
Martin

@borzel said in Kopano 8.7 and Outlook 2016 with MAPI:

here is the part that is a bit misleading

I think its a rather straight statement that we had to do since a lot of older users saw KOE as a direct replacement for the old MAPI connection, which it simply isn’t.

I personally do not have problems with using KOE, but there are indeed scenarios especially with very large folder trees and shared folders where it does not work as good. Normally I would always try to push for WebApp/DeskApp as this also allows for easier use of other parts of Kopano.

If that is no option for you, you could still try to add the inbox via imap.

I found something in the logs i turned on debug and it says missing authorise data:

10.30.0.199:49262 - - [13/Feb/2020:10:25:31 +0200] “PROPFIND /caldav/v2 HTTP/1.1” 401 0 “-” “Mac+OS+X/10.15.3 (19D76) accountsd/113”
2020-02-13T10:25:31.708899: [kopano-ical|T5671] [debug ] End Of Request
2020-02-13T10:25:31.916930: [kopano-ical|T5671] [debug ] New Request
2020-02-13T10:25:31.917253: [kopano-ical|T5671] [debug ] Receiving headers:
2020-02-13T10:25:31.917425: [kopano-ical|T5671] [debug ] < PROPFIND /principals/users/testuser/ HTTP/1.1
2020-02-13T10:25:31.917576: [kopano-ical|T5671] [debug ] < Host: kopano.domain.com:8080
2020-02-13T10:25:31.917741: [kopano-ical|T5671] [debug ] < Content-Type: text/xml
2020-02-13T10:25:31.917885: [kopano-ical|T5671] [debug ] < Depth: 0
2020-02-13T10:25:31.918024: [kopano-ical|T5671] [debug ] < Brief: t
2020-02-13T10:25:31.918163: [kopano-ical|T5671] [debug ] < Accept: /
2020-02-13T10:25:31.918304: [kopano-ical|T5671] [debug ] < Connection: keep-alive
2020-02-13T10:25:31.918444: [kopano-ical|T5671] [debug ] < Prefer: return=minimal
2020-02-13T10:25:31.918587: [kopano-ical|T5671] [debug ] < User-Agent: Mac+OS+X/10.15.3 (19D76) accountsd/113
2020-02-13T10:25:31.918728: [kopano-ical|T5671] [debug ] < Content-Length: 181
2020-02-13T10:25:31.918936: [kopano-ical|T5671] [debug ] < Accept-Language: en-us
2020-02-13T10:25:31.919085: [kopano-ical|T5671] [debug ] < Accept-Encoding: gzip, deflate
2020-02-13T10:25:31.919243: [kopano-ical|T5671] [debug ] Request missing authorization data
2020-02-13T10:25:31.922651: [kopano-ical|T5671] [info ] Sending authentication request
2020-02-13T10:25:31.922992: [kopano-ical|T5671] [debug ] > HTTP/1.1 401 Unauthorized
2020-02-13T10:25:31.923165: [kopano-ical|T5671] [debug ] > WWW-Authenticate: Basic realm=“Kopano CalDav Gateway”
2020-02-13T10:25:31.923307: [kopano-ical|T5671] [debug ] > Content-Length: 0
2020-02-13T10:25:31.923441: [kopano-ical|T5671] [debug ] > Server: Kopano
2020-02-13T10:25:31.923573: [kopano-ical|T5671] [debug ] > Date: Thu, 13 Feb 2020 08:25:31 GMT
2020-02-13T10:25:31.923706: [kopano-ical|T5671] [debug ] > Connection: Keep-Alive
2020-02-13T10:25:31.923839: [kopano-ical|T5671] [debug ] > Keep-Alive: 300

The latest known Outlook clients are the linked one. The zarafaclient-7.2.6-52189.msi I can not find up to now. Also the changelog between the versions 189 and 190 is not available. Have anybody stored the version 190 and data about the changes?