@ckruijntjens said in kopano-backup restore:

hi when will the issue be resolved for

we are currently prepping some new releases and therefore I did not yet have time to further look into this.

@ckruijntjens said in kopano-backup restore:

i only have problems using the nightly builds

Please have in mind that the nightly builds are (as the name implies) nightly builds of our development branches. These are not meant to be 100% stable but simply there to give early access to development in the hopes to get feedback before these features hit a release.

For production setups we recommend to get a subscription. Subscription holders have access to release builds as well as package repositories and archives of older releases (in case you want to go back to an earlier version). Apart from that there is of course access to our support.

Packages are back available. -> Solved.

@mcostan

For the moment: Every time.

The easiest way to see this is via Z-Push. Just have any mobile set-up to to this store, fully sync it.
Then enable WBXML logging in Z-Push and modify the event you want to see the data (info on how to do this here).
Sync mobile. In the log you will see the recurrence data and all the exceptions.

@markct

i find an other issue. when i am moving a lot of emails to an other folder it cant deliver any mail anymore. It starts to complaine about duplicate items in sql database?

@dbuggmbh said in delegation/sendas - disable copy of sent mail:

In the manual it states:
“Also in the standard configuration each mail that is send as a user or on behalf of a user will also be placed in the sent items of this user.”

I’m not able to find this exact sentence in our documentation. Out of curiosity: where are you referring to?

The component that sends out message is kopano-spooler, hence when looking into man kopano-spooler.cfg

copy_delegate_mails Make a copy of the sent mail of delegates in the sent items folder of the representee. This is done for both delegate and send-as e-mails. Default: yes

@walterhof said in User Company quotas problem:

In this case we need quotas on public store too

We are further going away from the initial topic.

While automatic limitation of the public store is nothing that is going to happen, its quite easy to monitor x tenants and just remind them friendly to reduce their public store size (with the soft limit this should actually already be the case). And if they don’t reduce, then send them a non automated mail.

This is IMHO not an issue that needs to be solved in Kopano.

mariadb has two libs on offer (libmariadb-2.3.2, libmariadbclient-10.1) of which the former is the broken one (fixed in -3.0, but UCS does not ship that). We switched it out now.

Hi @acha ,

thanks for the feedback.

Hi @joost001 ,

In Kopano the two LDAP backends got merged and hence the old ldapms example configuration was deprecated a while ago.

But when you’re coming from Zarafa you want to keep your old LDAP configuration in most cases anyways

@robing Thank you …it is ok now…

It does not have to be two separate systems. But if you want the archive database to be separate from the main database, you will need to run two kopano-server instances, at different TCP and socket ports naturally. Two or more kopano-server instances mean multiserver, and that requires appropriate LDAP entries for said servers, plus a DNS name. It all can run on the same system, but performance is said to be only won by spreading it out onto different hardware.

Yes, the internal build mechanisms were updated for the new package name(s).

Not really. .rpmnew files get, in essence, created whenever the defaults change. Since config files exist for the purpose of conscious overrides of these built-in defaults, bothering the admin at every upgrade is pointless.

@mapo said in simple multi domain setup?:

(it seems username must be the same as email in multidomain system)

No, that is not try. You must either need to deliver emails with either the username of the desired user or his primary email.

In your case it already seem to have failed to resolve the user on the MTA level.

@lendl said in The message could not be opened:

8.4.90.914

have not checked version, but if you are having the problem that is fixed by the script you mentioned, then you should also upgrade to a build that contains the fix for the actual problem (the script just repairs messages affected by the problem).

Hey,
I will read on that site then.
Before tryed import my pst file was os version 4.2-xxx after upgrade is 4.3
but I will take an look later is not no hurry.
Are new on linux learn new thing every day.

Hi Felix,
thanks for your answer!

Damn I did not remember this!

Finally a serverrestart fixed it - which is in fact a dagent restart too!