That was the guide that I had been following. I’m not sure if my implementation was incorrect, but adding the line:
AliasMatch (?i)/Autodiscover/Autodiscover.xml "/usr/share/z-push/autodiscover/autodiscover.php"
to my Apache configuration did not work. Once I created the autodiscover.domain.com DNS entry, then it started working for mobile devices.
The Windows 10 Mail client still does not work, but I think this is caused by a bug as outlined here:
EDIT: The Outlook 2016 client works with z-push autodiscover once I install the Kopano Outlook Extension. All is well!
I don’t know what to say… In the meantime i’ve reinstalled the Kopano Core, Kopano WebApp and Z-Push for Kopano. Now all users are working well. I think there was a problem at installation?
Before the reinstall i’ve made a snapshot of the virtual machine. But, what happened? After the rollback to the UCS with the old, not reinstalled Kopano, the same user, which had a problem with ActiveSync works now? Every mail, every contact, every calendar entry was synched.
I don’t believe in ghosts, until now. But there was only an update for the iOS Outlook app. I don’t have the exact update time, but the update was released 18 hours ago. I think the iphone have installed the update in the last 1-2 hours and MS fixed a bug in relation to ActiveSync. That’s my only explanation for the problem. That would explain the successful test with the testuser.
Thanks for the replys.
For all with such a problem:
i’ve got a script via subscription support to pruge the items outside of kopanos triggers and internal actions.
its a script called “purge-softdelete.py”, and deletes the items directly from db.
seems to work in test environment - i will provide info if this is also for the productive env.
one thing to mention: availible ram is getting lower and lower within the process and needs some time (about 1d to release the ressources or requires rebooting the server)
//EDIT: A bit late, but here info for productive Systems:
It works and solved the problem, but NEVER EVER start the purge with 30 days or something if you didnt purge for over half a year and the script want to delete over 1,8 mio elements ;)
start with 360 days and decrase 30 days with every purge.
Ignore the MAPI_E_DISK_ERROR’s, the script is searching for them and will try to redo the action afterwards. if you reached your desired days run it 3 till 4 times to eleminate all items, even with MAPI_E_DISK_ERROR…
And to mention, dont run the initial purge if users are active, the performance of db will decrase and the users will blame you ;(
It also might depend on the number of syncs running in parallel. When switching to kopano, we always had several syncs running and a 10 GB mailbox took a night for the initial sync. Now I had to resync a 14 GB mailbox in normal operation and this took about 2 hours.
I use “Task & Notes for MS Exchange” UniqTec Inc.
It’s actually great!
It costs a tiny amount of money, but I can use it on how many Android devices I want.
And it works perfectly well with Kopano z-push.
The issue is much more complex than just send-as, also because the calendar item ends up in the wrong calendar.
There is probably no real way to fix it other than preventing a user to accept a meeting request in a shared folder.
I’ve created https://jira.kopano.io/browse/KOE-143 to look at this.
This will work when we implement https://jira.kopano.io/browse/KOE-124.