Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support

kopiko

I’ve upgraded our Zarafa Server 7.2.6 to Kopano Server 8.4.6 recently. There were no surprises really. Mostly because the core functionality of the Zarafa/Kopano server has not been changed much. MAPI is still MAPI. Only thing to be aware of is that there are some Microsoft Office security patches that break Zarafa Client integration with Outlook. Other thing is that we still have the Zarafa Scheme Extension in our Active Directory. Copy the Zarafa server ldap config files to the Kopano Server ldap config and you will be fine.

Works, we use Windows 10 Pro with Kopano Server 8.4.6, Outlook 2013 and Zarafa client 7.2.6.
You don’t need to install KOE, Zarafa Client 7.2.6 still works fine (Don’t install all the latest Outlook security updates though).
Outlook 2010 + Zarafa Client 7.2.6 still works on Kopano Server 8.4.6
I recommend upgrading Z-Push first, then update Zarafa to Kopano. Although I don’t think it matters, core functionality has not been changed.
Easiest is to use a seperate server for Webapp and Z-Push. Install a new one with the latest Z-Push and WebApp, connect it to your Zarafa server and see if it works…
Nope

eli

We upgraded one Zarafa server to Kopano 8.4.6 and it works fine with the clients (Outlook 2007/2010) and the other ZCP 7.2.5 servers in the company.

The main problems in the migration where based on Postfix. Ubuntu 16.04 comes with postfix 3.1 and the postfix-ldap is not longer working with 3.x postfix versions. We are using the ldap queries in postfix to find the right target server.
I found only the solution to install the postfix/postfix-ldap 2.11 packages from Ubuntu 14.04 instead.

The zarafa-client 7.2.6 works fine, with less problems then on Outlook 2016/z-push 2.3.8/KOE. Several users requested a downgrade from Outlook 2016 to Outlook 2007.

We have also Webapp/z-push separated on an own server. It made it easy to stay at the latest versions and there was no need to change something on the client side while we changed the backend server.

mkromer

I also want to bring up that the 8.5.x issue with that the classic MAPI provider has been fixed with the release of 8.5.4, made available yesterday.

micro

Hello all,

thanks to everyone providing such helpful information. I want to give some feedback after a successful migration to Kopano. Maybe my following experience results could be helpful for others, too. In addition I will post some questions to some issues that came up since we’re working with Kopano.

Before starting the migration process I had interrupt the network paths so all incoming connections to the server running Kopano/Z-push were blocked, except my own test workstation. That means that all workstations or mobile devices were disconnected from the server. After successful migration I opened the firewall rules so all clients re-established their connection with the server.

About migration process to Kopano

Old environment / New environment
Server:
GNU/Linux Debian Jessie 8.10 64bit / unchanged
zarafa-server: 7.2.4.29-99.1 / kopano-server: 8.5.9.0-0+6.1
zarafa-webapp: 2.2.1.43-199.1 / kopano-webapp: 3.4.13.1464+59.1
apache2: 2.4.10-10+deb8u7 / apache2: 2.4.10-10+deb8u12
z-push: 2.2.10 / z-push: 2.4.1+0-0
php5-mapi: 7.2.4-29-99.1 / php5-mapi: 8.5.9.0-0+6.1

I did not change the ActiveDirectory schema yet. So it’s still being the Zarafa schema used in our Samba4 AD.

Clients:
Outlook 2013 (15.0.4989.1000) 32-bit
Outlook 2013 (15.0.4911.1002) 32-bit
Outlook 2010 (14.0.7190.5000) 32-bit

All employees have Zarafa Client version 7.2.6.52189 installed on their workstations.

Due to that last fact (Zarafa client installed on each workstation and client workstations were not modified at all) all employees were able to use Outlook in the morning after starting their computer, without realizing that Zarafa was upgraded to Kopano. The same is true for all mobile devices which connected seamlessly to the new z-push server and synced successfully.

I had to download the latest Nagios Script that will check our Kopano server. It’s the same author and quite the same script I used before, just light modifications made by author. You can find it HERE

Hurdles encountered AFTER migration

Here are the hurdles and issues I encountered after some testing and reporting from various employees and at the same time my question for any helpful hint how to solve them:

(1) Shared Calendars not showing any data any more
Some employees contacted me in the morning and told me that the shared calendars they have attached within their Outlook client are not working any more. There is an exclamation mark and the message “could not be refreshed”. For example user “Alice” needs to use the calendar of “Bob”. Bob has given the permission to Alice to use his calendar. Alice attached Bobs’ calendar in her Outlook by actions [CALENDAR] --> [Add a calendar from the adressbook] --> [Bob].

After investigating some research on the net I ran into this knowledge base information:
(https://kb.kopano.io/display/WIKI/Setting+up+the+Kopano+OL+Extension#SettinguptheKopanoOLExtension-Icanonlyseefree/busydatainsharedcalendars/Igetamessagethatthe"calendarcouldnotbeupdated")
I remove this non-working calendar from Alice’ Outlook, then I use the ZARAFA ribbon (she is still using Zarafa client because using Outlook 2010) to attach a shared mailbox. As I don’t want to have a temporary solution, I need to choose “whole mailbox (permanent)” in that step. Now the calendar of Bob is displayed correctly but the bad thing is that Alice also sees an entry in the MAIL view on the left pane “Inbox - Bob” and all his 10 subfolders. To prevent this (Alice should NOT see any relevant folder names from Bobs mail folders!) I need to build following ACL on Bobs folder structure:

root folder ob Bob --> No right, except of LIST FOLDER (I need this to inherit permissions for using calendar object)
Email folders and subfolder --> No rights; I need to ensure the check mark “List folder” is unchecked !!

That’s complex, because Bobs using dozens of (sub-)folders. Imagine I have to do this for 100 employees, that will be a pain in the *** :) How do I solve that?

(2) weird messages in z-push-error.log
I realized lot of lines such:
[…]
20/05/2018 17:19:28 [ 2045] [WARN] [johndoe] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
20/05/2018 17:19:28 [ 2045] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“AlleMitarbeiter” <>’. Address is removed.
[…]
[…]
20/05/2018 17:22:15 [ 2044] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“Mustermann, Max” <>’. Address is removed.
20/05/2018 17:22:15 [ 2044] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“Beispiel, Sabine” <>’. Address is removed.
20/05/2018 17:22:15 [ 2044] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“Wurst, Hans” <>’. Address is removed.
[…]
20/05/2018 17:23:26 [ 2043] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“AlleMitarbeiter” <>’. Address is removed.
20/05/2018 17:23:28 [ 2043] [WARN] [johndoe] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
20/05/2018 17:23:28 [ 2043] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“AlleMitarbeiter” <>’. Address is removed.
20/05/2018 17:23:44 [ 2042] [WARN] [johndoe] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
[…]

The name “AlleMitarbeiter” is a groupname which is valid in our Active Directory and also listed correctly when executing kopano-admin -L. Similar error messages also appear often in server.log

kopano-server.log:
[…]
Sun May 20 17:22:12 2018: [warning] ECFileAttachment: /var/lib/kopano/attachments/8/5/968858.gz seems to be an unsupported multi-stream gzip file (KC-104).
Sun May 20 17:22:14 2018: [warning] K-1515: Object not found unknown user “AlleMitarbeiter”: AlleMitarbeiter not found in LDAP
Sun May 20 17:22:52 2018: [warning] Previous message logged 2 times
Sun May 20 17:22:52 2018: [error ] Error while connecting to search on “file:///var/run/kopano/search.sock”
Sun May 20 17:22:59 2018: [warning] K-1515: Object not found unknown user “AlleMitarbeiter”: AlleMitarbeiter not found in LDAP
[…]

is that something to worry about?

(3) missing file /etc/default/kopano
There was no file there, why? I compared to another private machine where I have installed the community edition version 8.6.80.493-0+50.1 When I execute dpkg -L kopano-common I see that this file comes with that package. But when I run this command on the company server the file is also missing there. What’s going on there, any clues?

(4) error message [warning] SSL_accept() failed in soap_ssl_accept()
is appearing sometimes in server.log file. I have no clue as everything seems to work fine. Where does it originate from and is it something to worry about ?

(5) Adress Book missing information and sorting changed?
On my own client (Outlook 2013) I am connected directly with Kopano-Server through ActiveSync, that means I have no zarafa client installed. I have also the latest KOL installed on my machine. I realized when watching at the GAB, the field “Department” is empty with no data. Although all our employees have this field filled in Active Directory. Anything changed here ? How can I adjust that to see the information on the adress book ? I am also missing the option to have the names sorted by “Name”. Actually my own contacts but also the GAB entries all are sorted by “Surname”.

Questions on To-Do’s

(A) Is there any benefit actually to change the ActiveDirectory Schema from Zarafa --to–> Kopano as explained HERE at point [User Backend] --> [Active Directory] ? Currently I still have the Zarafa scheme in use and on my administrating Windows machine I still need to keep “Zarafa ADS” installed. When managing users & groups with Microsofts’ ADUC (ActiveDirectoryUsers&Computers) tool, I have the ribbon called [ZARAFA] to manage the appropriate settings.

In case I would switch to “Kopano AD schema”, in my understanding it would need to uninstall “Zarafa ADS” from the managing windows workstation and install “Kopano ADS” instead. But that is requiring the migration to Kopano Schema, correct? Can I just run this script HERE or isn’t that the right way for performing a schema update ?

(B) to-be-continued :)

Finally

Nevertheless I am quite happy that it went so well and smooth. Thanks to everyone from Zarafa/Kopano for their hard work and the nice product(s) they develop.

µicro

fbartels

@micro said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

Here are the hurdles and issues I encountered after some testing and reporting from various employees and at the same time my question for any helpful hint how to solve them:
(1)

I guess no errors then? Or are you still editing your text?

Edit: ok by now there have been 23 edits to your post. Thats quite a long list to discuss it here in the forum. I’d recommend opening up a support case and following it up there.

PS: this forum uses markdown formatting. I’ve seen that you tried to make your text more readable.

Coffee_is_life

@micro said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

20/05/2018 17:19:28 [ 2045] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“AlleMitarbeiter” <>’. Address is removed.

this message is cause by z-push not look up groupnames. it will be replaces by the actual members of the group - i got a bunch of these messages myself even if kopano-admin -L lists the group.

@kopanoteam, @z-push-team, does this behaviour changes in the future? - so if the userlookup fails, the grouplookup does check if the group exists and if yes, just no warn message?

for the message:

20/05/2018 17:22:15 [ 2044] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“Wurst, Hans” <>’. Address is removed.

i bet the recipient will get the mail, but the displayname (Wurst, Hans) )is not the address (hans.wurst@company.de)

about the soprting-option in outlook, see Datei -> Person -> Namen und Ablage
this is handed locally on every OL.

changing from zarafa to kopano ADS:
im working with zarafa ads aswell - the only change i did was to edit the ldap.cfg where the names are mapped to the properties. - so i replaced everything in the file namend Kopano-something to zarafa-something
so this change you have to do backwards to use the kopano-schema in your mailserver.
i cant tell you if the schema update script will do the job on your AD, cause im using Microsoft AD server and no samba (will changes in the future)

coffee_is_life

micro

@fbartels said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

Edit: ok by now there have been 23 edits to your post. Thats quite a long list to discuss it here in the forum. I’d recommend opening up a support case and following it up there.
PS: this forum uses markdown formatting. I’ve seen that you tried to make your text more readable.

Thank you for the hint. I tried to make use of it.

Today is the first day after the migration. I will collect some more information (and maybe hurdles) and will do so. Thank you.
Meanwhile I am looking forward to any further helpful information from anyone else. Thanks for listening and good luck to those needing this migration step to be done.

Manfred

Hi micro,

@micro said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

20/05/2018 17:23:28 [ 2043] [WARN] [johndoe] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)

This is probably a calendar item with attendees or a meeting request and one of the participants was deleted in the meantime, so Z-Push can’t find the user’s information on the server. There is a fall back to solve this and in z-push.log on the following line of the WARN entry you should see an INFO level entry:

"MAPIProvider->getEmailAddressFromSearchKey(): fall back to PR_SEARCH_KEY or PR_SENT_REPRESENTING_SEARCH_KEY to resolve user and get email address"

@coffee_is_life said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

@micro said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

20/05/2018 17:19:28 [ 2045] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“AlleMitarbeiter” <>’. Address is removed.

this message is cause by z-push not look up groupnames. it will be replaces by the actual members of the group - i got a bunch of these messages myself even if kopano-admin -L lists the group.

@kopanoteam, @z-push-team, does this behaviour changes in the future? - so if the userlookup fails, the grouplookup does check if the group exists and if yes, just no warn message?

This error message has the same reason as the one below: ‘“AlleMitarbeiter” <>’ is not a valid email address. Z-Push doesn’t do the user lookup here, it just checks whether the email address is valid. As we’re not doing user lookup, we also won’t add the group lookup.

for the message:
20/05/2018 17:22:15 [ 2044] [WARN] [johndoe] SyncObject->Check(): object from type SyncMail: parameter ‘to’ contains an invalid email address ‘“Wurst, Hans” <>’. Address is removed.
i bet the recipient will get the mail, but the displayname (Wurst, Hans) )is not the address (hans.wurst@company.de)

Yes, the email is being synchronised to the mobile, otherwise there wouldn’t be this log entry. However as the “to” field is being removed by Z-Push because it is not a valid email address, some clients might consider this message broken and not display it.

Manfred

micro

Servus Manfred,

thanks for your feedback. Interpreting it, that’s nothing to worry about, right? What about these lines ?

22/05/2018 14:10:48 [ 8138] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:10:48 [ 8138] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:10:48 [ 1368] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:20:12 [ 1368] [WARN] [bob] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:45:40 [ 3006] [WARN] [john] SyncAppointment->Check(): Parameter ‘organizername’ and ‘organizeremail’ should be set for a meeting request
22/05/2018 15:18:57 [ 6131] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 15:18:57 [ 6131] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 15:24:05 [ 4738] [WARN] [charlie] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)

Related to the “shared calendar” stuff:
To my surprise I did find out by trial-and-error that a non-admin user can view the free/busy times of every user he likes, although he has no privilege to do so. I cross-tested with another usual employee user account (non-admin) and on various workstations (Win7, Win10, Outlook2010, Outlook2013). Although he cannot see the calendar details IMHO this is a privacy issue According the principle o least privilege such a user should not see any confidential information of another user he was not permitted to. Here’s how it works:

User Alice is a non-admin account.
User Bob is a non-admin account.

There is no privilege on their mailboxes, neither on their root domain nor on the calendar object itself. Theoretically User Alice cannot access anything at User Bob and vice-versa. But this is not the case in exclusively following single constellation and breaks the privacy / security model:

Alice (or Bob) is using Outlook (2010 or 2013) with Zarafa-Client (in my particular testing case 7.2.6.52189). In CALENDAR view click onto “add a shared calendar” and from GAB choose any user. This will display the free/busy times of that user, but it shouldn’t.

I can reproduce this with each non-admin user on the mentioned platforms and versions. At the beginning I thouhg it could be due to KOL installed in parallel with Zarafa client. So I uninstalled KOS and tested again. I also testes on workstations that never had KOL installed, only Zarafa client.

Maybe you could test on your own and report back? I don’t think this is ‘normal behaviour’, isn’t it?

Manfred

Hi micro,

@micro said in Migrating Zarafa ZCP 7.2.4.29 with Z-Push 2.2.10 server to latest Kopano with Outlook support:

Servus Manfred,

thanks for your feedback. Interpreting it, that’s nothing to worry about, right? What about these lines ?

Yes, that’s nothing to worry about.

22/05/2018 14:10:48 [ 8138] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:10:48 [ 8138] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:2258 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:10:48 [ 1368] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:20:12 [ 1368] [WARN] [bob] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 14:45:40 [ 3006] [WARN] [john] SyncAppointment->Check(): Parameter ‘organizername’ and ‘organizeremail’ should be set for a meeting request
22/05/2018 15:18:57 [ 6131] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 15:18:57 [ 6131] [WARN] [alice] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)
22/05/2018 15:24:05 [ 4738] [WARN] [charlie] /usr/share/z-push/backend/kopano/mapiprovider.php:274 mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2)

All mapi_zarafa_getuser_by_name(): Unable to resolve the user: 8004010F (2) WARNs are related to the fact that one of the participants is not kopano/zarafa user anymore, most probably deleted.

22/05/2018 14:45:40 [ 3006] [WARN] [john] SyncAppointment->Check(): Parameter 'organizername' and 'organizeremail' should be set for a meeting request

The above is pretty self explanatory. If there’s a meeting, someone has organised it, but it’s not set in this item for some reason. The item will be synced to the mobile device / Outlook, but it depends on them if they will display it correctly.

Related to the “shared calendar” stuff:
To my surprise I did find out by trial-and-error that a non-admin user can view the free/busy times of every user he likes, although he has no privilege to do so. […]
Maybe you could test on your own and report back? I don’t think this is ‘normal behaviour’, isn’t it?

That’s the whole point of free busy that you’re able to see when a user is available. When you’re organising a meeting it’s pretty convenient to know when the attendees are free instead of going back and forth to find out a free time slot of everyone. Even Z-Push implements free busy so that you get that information on your mobile. So this indeed is a normal behaviour.
Unless of course a user is able to see sensitive information of another user’s appointments without having permissions, like subject or notes.

Manfred

micro

Manfred, thanks for clarification.