Hello @isol ,

from what I’ve heard from our support I would not recommend to use Samba 4 LDAP for user groups larger than 100 users. The Univention App used the internal OpenLDAP from the start, so in the sense of “don’t fix what isn’t broken” it never switched over to the Samba 4 auth.

@isol said in Kopano Auth against Univention:

if the customer later migrates to a real Windows DC I assume it is less work on the kopano side !?

changing the auth source almost always comes with different unique user keys, so if i don’t think it matters which kind of ldap implementation you are running now, from the Kopano side of things both will be equally intensive.

Maybe except for the fact that it may be a bit easier to migrate tree data into an ads from samba, than it is from openldap.

That’s beyond my scope unfortunately, thanks for letting me know though. I’ll see if I can change this from with the ticketing system.

Hi @cburghardt,

good to hear that you managed to solve your issue. I would suggest that you contact the package maintainer so that they could incorporate this fix into their packages.

This time it worked!
The elevated prompt did it!
Thank you very much!

I now have the tabs in the MMC on my Win10 (member with RSAT) and on my W2012R2 DC.

hello @fbartels,

i’ve upgraded some time ago, cam back from holiday and the server runs smoothly - was this mem leak

thanks for the help -closed-

Coffee_is_life

sadly not…

it worked. thank you very much.

in a now [deleted topic]([component=“topic/reply/container”] .btn.dropdown-toggle {
display: none;
}) @elkaplan said that he got it working, presumable by using the latest release.

Excellent thank you

This worked. I was installing one by one. Now I’ve installed Thanks.

Perfectly legal. The email belongs to the company not the individual.
And there are plenty of other cases, like what if personnel (or anyone) send an email with someone else’s personal information? What about threatening or abusive emails?
By law we need to keep a record of these emails, but the company is free to delete from the user’s mailbox.

@fbartels
Thanks for the quick reply and the explanation. I guess I really should have noticed this in the changelog.
Any new user coming to kopano does however not have a chance to notice it in the old changelogs.

Perhaps you could include your excellent explanation in future dagent.cfg config files? Then at least anyone configuring it will be aware of the implications. I don’t think there is a warning anywhere else (like in the Kopano Administrators manual)…

Hello @franktron,

i would recommend to send informations about your KC-version, php and your system.

on top you could:

check your /var/log/message and search for some errors at the same time.
check /etc/kopano/autorespond and make sure the path to sendmail is correct. //wrote before i’ve seen your respond
check permissions on /var/lib/kopano/autorespond - kopano will create a temp-file there.

coffee_is_life

Hi Bob,

this seems to be a limitation introcuded in the newer version of GSOAP. We already have a fix for this; https://jira.kopano.io/browse/KC-683
Can you open up a support ticket for this?

As a workaround you can reindex a single user’s store should that user request it. Full reindex would work as well, but we would not recommend it with that many users as a upgrade will also fix this

WONDERFULL! It worked! Thank you very much!

Hi,

I don’t know why, but now it runs with:

mailbox_transport=lmtp:127.0.0.1:2003

Maybe an update in Dagent?

Tommi