Product SiteDocumentation Site

ZCP 7.1 (build 48315)

Zarafa Collaboration Platform

Release Notes

Edition 7.1

The Zarafa Team


Legal Notice

Copyright © 2015 Zarafa BV.
The text of and illustrations in this document are licensed by Zarafa BV under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at the creativecommons.org website. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Red Hat®, Red Hat Enterprise Linux®, Fedora® and RHCE® are trademarks of Red Hat, Inc., registered in the United States and other countries.
Ubuntu® and Canonical® are registered trademarks of Canonical Ltd.
Debian® is a registered trademark of Software in the Public Interest, Inc.
SUSE® and eDirectory® are registered trademarks of Novell, Inc.
Microsoft® Windows®, Microsoft Office Outlook®, Microsoft Exchange® and Microsoft Active Directory® are registered trademarks of Microsoft Corporation in the United States and/or other countries.
The Trademark BlackBerry® is owned by BlackBerry and is registered in the United States and may be pending or registered in other countries. Zarafa BV is not endorsed, sponsored, affiliated with or otherwise authorized by BlackBerry.
All trademarks are the property of their respective owners.
Disclaimer: Although all documentation is written and compiled with care, Zarafa is not responsible for direct actions or consequences derived from using this documentation, including unclear instructions or missing information not contained in these documents.
Abstract
The Zarafa Collaboration Platform (ZCP) combines the usability of Outlook with the stability and flexibility of a Linux server. It features a rich web-interface, the Zarafa WebAccess, and provides brilliant integration options with all sorts of clients including all most popular mobile platforms.
Most components of ZCP are open source, licensed under the AGPLv3, can therefore be downloaded freely as ZCP's Community Edition.
Several closed source components exist, most notably:
  • the Zarafa Windows Client providing Outlook integration,
  • the Zarafa BES Integration providing Blackberry Enterprise Server connectivity,
  • the Zarafa ADS Plugin providing Active Directory integration, and
  • the Zarafa Backup Tools.
These components, together with several advanced features for large setups and hosters, are only available in combination with a support contract as part of ZCP's Commercial Editions.
Alternatively there is a wide selection of hosted ZCP offerings available worldwide.
This document, the release notes, will describe all new features and architecture changes in the ZCP.

1. Introduction
1.1. Intended Audience
1.2. Additional information resources
2. Changes for end users
2.1. Outlook changes
2.1.1. Delivery status notifications
2.1.2. Outlook offline storage engine
2.2. WebAccess changes
2.3. WebApp changes
3. Changes for Administrators
3.1. Subscription keys
3.2. Packaging layout change
3.3. Zarafa Search
3.4. Support for multiple LDAP servers
3.5. Python Dagent & Spooler hooks
3.5.1. Dagent plugins
3.5.2. Spooler plugins
3.6. Removal of the Perl API
3.7. Zarafa backup optimizations
3.8. Deduplication filter for group recipients
3.9. Reverse Proxy Support for multi-server clusters
3.9.1. Setup Prerequisites
3.10. Restrict admin permissions
3.11. SMTP Delivery notifications
3.12. Zarafa Out of Office configuration
3.13. New zarafa-admin changes
4. Upgrading to ZCP 7.1
4.1. Config file changes
4.1.1. server.cfg
4.1.2. backup.cfg
4.1.3. indexer.cfg
4.1.4. search.cfg
4.1.5. licensed.cfg
4.1.6. dagent.cfg
4.1.7. spooler.cfg
4.1.8. gateway.cfg
4.1.9. ical.cfg
4.1.10. ldap.propmap.cfg
4.1.11. ldap.openldap.cfg
4.1.12. ldap.active-directory.cfg
5. Changes in 7.1.1
5.1. Configuration file changes 7.1.1
6. Changes in 7.1.2
6.1. Configuration file changes 7.1.2
7. Changes in 7.1.3
7.1. Configuration file changes 7.1.3
8. Changes in 7.1.4
8.1. Configuration file changes 7.1.4

Chapter 1. Introduction

The Zarafa Collaboration Platform (ZCP) is an open source software suite capable of replacing Microsoft Exchange. It’s architecture is very modular, makes use of open standards wherever possible, and integrates with common open source components.
This release notes will give an overview of the new features and improvements as well any changes in the architecture of the ZCP version 7.1. The ZCP 7.1 release contains mainly backend improvements and changes, especially to the indexer and Dagent/Spooler. The 7.1 release does not contain large database upgrades. As part of its philosophy Zarafa backports 95% of all bug report fixes to supported production versions in the general and extended support lifecycle phase. Please review the Zarafa Lifecycle Document in the client customer portal on http://portal.zarafa.com
These release notes focus on the differences beween the last 7.0.8 and the new 7.1.0 major version, for the many features and changes added in the 7.0 track please review the 7.0 Release Notes. All features and changes of 7.0.x are also present in 7.1.0 but may be more optimized.

Important

Although we, Zarafa, try our best to keep the information in these notes as accurate as possible, we withhold the right to modify this information at any time, without prior notice.

1.1. Intended Audience

These release notes are intended for end users and system administrators responsible for installing, maintaining, and supporting the ZCP software and it’s deployment.

1.2. Additional information resources

Chapter 2. Changes for end users

2.1. Outlook changes

2.1.1. Delivery status notifications

In ZCP 7.1 the ability has been added to request delivery notifications. When requesting a delivery notification the user will get a email report when the sent email is delivered.
Request a delivery notification in Outlook
Figure 2.1. Delivery Status Notification requests in Outlook

2.1.2. Outlook offline storage engine

The Zarafa client was updated to contain the latest MySQL embedded edition for offline usage. The new storage engine was replacing the older version which removes a number of smaller internal storage issues for larger offline profiles, some older Unicode issues and provides performance improvements.
Offline users must expect an upgrade of their profile when starting Outlook the first time after the installation of the new Zarafa client. The upgrade time will take from 10 minutes to 2 hours depending on the size of the offline data profile and the PC performance. During the upgrade the user can work online with the Zarafa Server to continue the work.
The upgrade process may be interrupted by sleep mode or hibernation and will continue then at the next start. Offline mode is not available until the upgrade is completely finished.

Note

An upgraded 7.1 offline profile can not be downgraded for use with a 7.0 server. This would require removing and recreating the profile after the server and client downgrade.

2.2. WebAccess changes

The ZCP 7.1 release doesn’t contain any additional webaccess user features.

2.3. WebApp changes

The latest webapp 1.1 is included in ZCP-7.1. This release contains:
  • Support for email delegation and multiple FROM addresses
  • Several user interface improvements
  • Native support for Internet Explorer 9
  • New plugin framework to manage (community) plugins and widgets
WebApp 1.1 delivers delegation, permissions and Send-From functionality
Figure 2.2. WebApp 1.1 delivers delegation, permissions and Send-From functionality

Chapter 3. Changes for Administrators

3.1. Subscription keys

When upgrading a supported ZCP version to a new major release, like 7.0.x to 7.1.x, the subscription key has to be converted. Converting subscription keys can be performed on our portal.

Note

During the Beta period and for the RC1 release the 7.0.x subscription key will remain valid. After this release the subscription key has to be converted.

3.2. Packaging layout change

To make it easier for system administrators to deploy specific components of ZCP on the servers, the packaging layout was refined in ZCP 7.0. In 7.1 the packaging has been altered to accommodate the new search engine functionality. The packaging layout change is displayed in the following table:
Table 3.1. Package layout
Package name Description
libkyotocabinet16
NEW: Contains the library of routines for managing the full text search database
zarafa-search
NEW: Contains the full text search service
zarafa-indexer
REMOVED

3.4. Support for multiple LDAP servers

As requested by many customers ZCP 7.1 offers support for multiple LDAP servers for better redundancy and higher availability. The Zarafa Server is using the standard libldap library for parsing the list of available LDAP servers and do all the failover logic. It is required to assure that both LDAP servers are fully updated and in sync when using the feature, as it can result is data loss when the LDAP servers are not fully in sync.
Zarafa server will use the primary LDAP, then the secondary when it fails
Figure 3.1. Zarafa server with LDAP requests failover

Instead of using ldap_host, ldap_port and ldap_protocol in the ldap.cfg, the option ldap_uri can be used to specify the different LDAP servers. If ldap_uri is set, the values of ldap_host, ldap_port and ldap_protocol are ignored.
ldap_uri = ldaps://ldapserver1:636 ldaps://ldapserver2:636

3.5. Python Dagent & Spooler hooks

The Zarafa Spooler and the Zarafa Dagent have been extened with a Python plugin framework. This framework makes it easier for advanced system administrators and developers to integrate systems with the spooler and dagent. System administrators and developers can easily add new functionality or change some behaviors of the existing system.
If the plugin framework in the spooler or dagent is enabled, it will search for python files in the directory plugin_path and look for a specific type of plugins. If the plugins are found in this directory, they will be verified and loaded. Every time the spooler or dagent is called it will execute the hooks based on priority. Plugins can validate and change a message on different stages of the spooler and dagent process. The Python plugin framework has an internal log system which forwards the log information to the Zarafa spooler and Zarafa dagent log.
To kickstart the usage of these hooks and expand functionality, Zarafa has included ready-for-use scripts.

3.5.1. Dagent plugins

The Zarafa Delivery Agent plugin processflow overview
Figure 3.2. Zarafa Dagent Plugin hook locations

3.5.1.1. Move to public Dagent plugin

The move to public plugin moves incomming messages to a folder in the public.
Enable the move to public plugin, run the following command:
ln -s /usr/share/zarafa-dagent/python/plugins/movetopublic.py /var/lib/zarafa/dagent/plugins/movetopublic.py
For this plugin is a config file required. Make a copy of the configuration file with the following command:
cp /usr/share/zarafa-dagent/python/plugins/movetopublic.cfg /etc/zarafa/movetopublic.cfg

3.5.1.2. BMP2PNG converter Dagent plugin

The BMP2PNG plugin converts a BMP to PNG in the incoming email. This plugin can be used to reduce the image size of the delivered email. Enable the BMP2PNG plugin, run the following command:
ln -s /usr/share/zarafa-dagent/python/plugins/BMP2PNG.py /var/lib/zarafa/dagent/plugins/BMP2PNG.py

Note

The package python-imaging is required to use this plugin.

3.5.2. Spooler plugins

The spooler plugins make manipulation possible of the messages in MAPI format before conversions, however this does not include RTF formatted emails.
The Zarafa Spooler plugin processflow overview
Figure 3.3. Zarafa Spooler Pluginhook locations

3.5.2.1. Disclaimer Spooler plugin

The disclaimer plugin add a disclaimer to every email sent with the Zarafa spooler.
The disclaimer plugin supports plain text and HTML emails. RTF emails are not supported at the moment. To use the disclaimer plugin it’s necessary to create the directory /etc/zarafa/disclaimers which must include the disclaimers text files. The plugin is using the following files for the disclaimer:
Table 3.2. Table Disclaimer files
Filename Description
default.txt
The plain text version of the disclaimer
default.html
The HTML version of the disclaimer
<companyname>.txt
The plain text version of the disclaimer of a company when running in multi-tenancy mode
<companyname>.html
The HTML version of the disclaimer of a company when running in multi-tenancy mode

Important

All files must encoded in utf8
Enable the disclaimer plugin, run the following command:
ln -s /usr/share/zarafa-spooler/python/plugins/disclaimer.py /var/lib/zarafa/spooler/plugins/disclaimer.py

3.6. Removal of the Perl API

As Zarafa has set a preference to expand on the Python API over the Perl API the Perl API has been removed. The API was quite basic and not that heavily use, this allows Zarafa to focus fully on the Python API.

3.7. Zarafa backup optimizations

The throughput of the Zarafa Backup has been greatly improved by the additional option to run the backup with multiple threads and in addition to the removal of message body content in multiple formats. The number of concurrent threads can be set in the backup.cfg file and should be adjusted to an optimal setting related to the server load and backup time. Initially set to threads = 1, the setting should be increased +1 per run to avoid system load issues. A full backup baseline should be used for this.

3.8. Deduplication filter for group recipients

The new deduplication feature in the Zarafa Dagent filters the recipients in addressed groups to unique users. This will no longer cause duplicated emails when a user in member of multiple groups that were addressed.

Note

This feature will only work when using Zarafa Dagent in LMTP mode.

3.9. Reverse Proxy Support for multi-server clusters

Certain setups require that Zarafa Server is not exposed directly to the internet. When offering Outlook access, it is sometimes needed to configure a reverse proxy so that Outlook users can connect to the reverse proxy and not directly to zarafa-server. Setting up a reverse proxy with a single zarafa-server is quite easy and can be found in chapter 5.1.3 of the Zarafa Administrator Manual, however in a multi-server setup this is not possible due to the redirection protocol within Zarafa. Therefore Zarafa Server has some new options in ZCP 7.1, which will make it easier to setup a reverse proxy for a multi-server environment.
In the new setup the reverse proxy will add extra header information, so the zarafa-server will detect that a connection is being made through a reverse proxy. When a connection is made through a reverse proxy (when the extra header is detected) Zarafa will not reply with the normal redirection string, but it will fetch the connection string from a new LDAP attribute ZarafaProxyUrl.
Outlook will then still connect to the reverse proxy, even when a redirect command is given:
  1. Outlook connects to the reverse proxy, and the reverse proxy adds the extra header and connects to node Z1
  2. Node Z1 detects the extra header and will send a redirect for User2 to node Proxy/Z2
  3. Outlook will now connect again to the proxy, but with a different path /Z2. The proxy will now connect to Z2 so the store of User2 can be opened
zarafareverseproxy
Figure 3.4. Zarafa Reverse proxy support principle for the Zarafa Outlook plugin.

3.9.1. Setup Prerequisites

When setting up a reverse proxy for a multi-server setup using the new ZCP options, the following prerequisites need to be met:
  1. ZCP 7.1 or newer
  2. OpenLDAP or ADS with the schema extensions from ZCP 7.1 or newer
  3. A reverse proxy server which fully supports HTTP/1.1 (make sure that also the transport encoding "Chuncked Encoding" is supported)
zarafareverseproxyADS
Figure 3.5. Zarafa Reverse proxy support can be configured in the Zarafa ADS plugin.

Note

For Configuration examples and instructions please consult the Administration manual. http://doc.zarafa.com/trunk/Administrator_Manual/en-US/html-single/#_running_zcp_multi_server_behind_reverse_proxy

3.10. Restrict admin permissions

To enforce the privacy of the system users towards system administrators in daily usage the option was added to restrict the permissions that admins receive to permissions on folders only, not the messages in the folders.
Normally, admin users are granted all permissions on all stores in the server or for stores in the tenant’s company (in multi-tenant mode). Enabling this option restricts permissions to folder operations: Folder viewing, folder creation and importantly, folder permissions. This means that an administrator can grant himself full permissions on a folder. However, in combination with auditing, it provides an extra level of security protection against unwanted access.
Note that some applications may require full access to all stores, which would be restricted by this option. Also, this option cannot be reset by sending a HUP signal, so a full server restart is required to change the setting.
restrict_admin_permissions = no

3.11. SMTP Delivery notifications

The administrator has the option to globally disallow the requests of DSN messages originating from the end users, this is conveniently done via a setting in the spooler.cfg file. Without this setting the clients can request such DSN, but it will not go out.

3.12. Zarafa Out of Office configuration

As response to popular demand we added the zarafa-set-oof Python script that allow administrators to configure the "Out of Office" status, subject and message for a user or a shared mailbox.
The Usage is:
zarafa-set-oof %s <username> <1|0> [<oof_subject>] [<path/to/oof/message.txt>]"

3.13. New zarafa-admin changes

The unhook store command was altered to provide the GUID of the store for easy usage in next commands or scripts.
zarafa-admin --unhook Tuser8@Company
Store unhooked store guid is D2801181A21D48FD8CF0F9EDC7057829
The reset folder counter command was added to reset counters in WebAccess, WebApp and Outlook. In the event a folder counter is out of sync its possible to fix this by the system with server config counter_reset but cause some performance issues and many system administrators disable this. To fix the out of sync of folder counters an option was created in the zarafa-admin to reset the folder count per user. The server config counter_reset is disabled by default. To use this option you can use the below command:
zarafa-admin --reset-folder-count <username>

Chapter 4. Upgrading to ZCP 7.1

As described in the previous chapter ZCP 7.1 contains no significant database architecture changes.
The database updates are done automatically by the Zarafa server process at start time when already running the general version 7 previous releases. When you upgrade from a 6.40 version please review the 7.0 release notes additionally to this one. Systems with a version prior to 6.40 are recommended to be upgraded first to the last 6.40 minor versions available (6.40.17).
Upgrading the Zarafa database will take a short time, please keep in mind that the Zarafa system can’t be used during this upgrade.
The upgrade process to ZCP 7.0 is a medium size update, please read carefully the upgrade chapter in the Administrator Manual before doing the upgrade.
Notes: When using CALDAV in order to open a shared calendar with 7.1.x you need view folder permissions on the root folder. People who upgrade from 7.0.x miss these permissions and they should be set.

Important

Especially note when replacing config files with the newer versions to review each of your former settings.

4.1. Config file changes

The following config files changes are done after the start of 7.0.0 and the final 7.1.0. Please review these lines for their values and presence in your current config file set as these also contain new advised defaults that work in relation to internal software.

4.1.1. server.cfg

# 7.0.3
The server.cfg is extended with two new configuration options.
max_deferred_records
The server has a list of deferred writes to the tproperties table, to improve overall I/O performance. The number of deferred writes is kept below this value; setting it high will allow writes to be more efficient by grouping more writes together, but may slow down reading, and setting it low will force writes to complete directly, but speed up reading of tables.
max_deferred_records_folder
Same as the max_deferred_records variable, but per folder instead of total.
# 7.0.4
The server.cfg is extended with new configuration options for the auto update logging and a new recommended defaults for attachment storage and cache parameters.
# Where to place attachments. Value can be 'database' or 'files'
attachment_storage      = files
# Sync lifetime, removes all changes remembered for a client after x days of inactivity
sync_lifetime           = 90
# Size in bytes of the 'cell' cache (should be set as high as you can afford to set it)
cache_cell_size                         = 268435456
# System is a special internal user, which has super-admin privileges
# You may want to disable this user from the Global Addressbook by setting
# this option to 'yes'. Administrators will still be able to see the user.
hide_system = yes
# Recieve update information from the client (0 = disabled, 1 = only on error, 2 = log always)
client_update_log_level = 1
# Log location for the client auto update files
client_update_log_path = /var/log/zarafa/autoupdate
# 7.0.6
The server.cfg was changed with ZCP-8518 to allow setting minimum length for prefix searches.
# Minimum length of a search term in characters to enable prefix searching
index_services_prefix_chars = 3
# 7.0.7
In ZCP 7.0.5 and 7.0.6 had an issue with the zarafa-licensed in large scale multi-server environments where the process could go out of file descriptors. To solve this issue a priority queue is introduced. The priority queue will handle incoming requests directly before other requests are handled.
For this option a new configuration option is introduced in the server.cfg.
server_pipe_priority    = /var/run/zarafa-prio
As this is a default setting, the priority socket is also available when the above setting is not available in the server.cfg.
# 7.1.0
# Enabling this option requires the zarafa-search service to
# be running.
search_enabled = yes
# SQL Procedures allow for some optimized queries when streaming with enhanced ICS.
# This is default disabled because you must set 'thread_stack = 256k' in your
# MySQL server config under the [mysqld] tag and restart your MySQL server.
enable_sql_procedures = no
# Path to the zarafa-search service, this option is only required
# if the server is going to make use of the indexing service.
search_socket = file:///var/run/zarafa-search
# Time (in seconds) to wait for a connection to the zarafa-search service
# before terminating the indexed search request.
search_timeout = 10
# Restrict the permissions that admins receive to folder permissions only. Please
# read the server.cfg manpage before enabling this option so you really understand
# the implications
restrict_admin_permissions = no
# The maximum level of attachment recursion; Defines the number of
# attachment-in-attachment in-attachment levels are allowed when saving and
# replicating objects in the database. If you really want a higher level of
# recursion than about 20, you probably have to increase MySQL's stack_size
# to allow replication to work properly.
embedded_attachment_limit = 20
# Header to detect whether a connection has been received through a proxy. The
# value of the header is not inspected. If the header exists then the connection
# is taken to be received via a proxy. An empty value disables proxy detection
# and the value of '*' is used to indicate that all connections are proxied
proxy_header =

4.1.2. backup.cfg

# Use multiple threads when backing up multiple stores.
threads = 1

4.1.3. indexer.cfg

# 7.0.4
The indexer.cfg has a new default entry.
# Should attachments be indexed
index_attachments       = no
# 7.1.0
The indexer config is depricated as of 7.1.0 and replaced by the new search.cfg file

4.1.4. search.cfg

A new file for 7.1.0 containing all previous general settings like the indexer.

4.1.5. licensed.cfg

# 7.0.7
The default location of the server_socket in the licensed.cfg is changed to use the priority socket.
server_socket = file:///var/run/zarafa-prio

Important

The setting in the licensed.cfg is not automatically changed during the upgrade to ZCP 7.0.7. For customers running in a multi-server or archiving setup it’s recommended to change manually the server_socket in the licensed.cfg.

4.1.6. dagent.cfg

# 7.0.1
# messages on delivery.
# This will do nothing if no archive is attached to the target mailbox.
archive_on_delivery = no
# 7.0.5
The dagent.cfg changed the log location and timestamp
#change log_file in dagent.cfg to full patch instead of -.
log_file = /var/log/zarafa/dagent.log
# Log timestamp - prefix each log line with timestamp in 'file' logging mode
log_timestamp   =       1
# 7.1.0
##############################################################
# DAGENT PLUGIN SETTINGS
# Enable the dagent plugin framework
plugin_enabled = yes
# Path to the dagent plugin manager
plugin_manager_path = /usr/share/zarafa-dagent/python
# Path to the activated dagent plugins.
#   This folder contains symlinks to the zarafa plugins and custom scripts. The plugins are
#   installed in '/usr/share/zarafa-dagent/python/plugins/'. To activate a plugin create a symbolic
#   link in the 'plugin_path' directory.
#
# Example:
#  $ ln -s /usr/share/zarafa-dagent/python/plugins/BMP2PNG.py /var/lib/zarafa/dagent/plugins/BMP2PNG.py
plugin_path = /var/lib/zarafa/dagent/plugins

4.1.7. spooler.cfg

# 7.0.1
##############################################################
# SPOOLER ARCHIVING SETTINGS
# Enable archive_on_send to automatically archive all outgoing
# messages.
# This will do nothing if no archive is attached to the source mailbox.
archive_on_send = no
# 7.0.3
The spooler.cfg is extended with the following option.
allow_send_to_everyone
Setting this option to no will disallow sending to the everyone group. The entire message will be bounced if this is attempted. When the option is set to yes, this allows sending to all users in the everyone group.
# 7.0.6
The spooler.cfg changed with ZCP-9481 to catch high chars in messages that have no charset defined.
# The us-ascii charset will be upgraded to this charset, to allow more
# use of high-characters. Not used when always_send_utf8 is enabled.
charset_upgrade = windows-1252
# 7.1.0
# Request SMTP Delivery Status Notifications if the MTA support it
enable_dsn = yes
# SPOOLER PLUGIN SETTINGS
# Enable the spooler plugin framework
plugin_enabled = yes
# Path to the spooler plugin manager
plugin_manager_path = /usr/share/zarafa-spooler/python
# Path to the activated spooler plugins.
#   This folder contains symlinks to the zarafa plugins and custom scripts. The plugins are
#   installed in '/usr/share/zarafa-spooler/python/plugins/'. To activate a plugin create a symbolic
#   link in the 'plugin_path' directory.
#
# Example:
#  $ ln -s /usr/share/zarafa-spooler/python/plugins/disclaimer.py /var/lib/zarafa/spooler/plugins/disclaimer.py
plugin_path = /var/lib/zarafa/spooler/plugins

4.1.8. gateway.cfg

# 7.0.3
The gateway.cfg is extended with the following option:
imap_store_rfc822
By setting this option to no, the imap gateway will not store the whole rfc822 message on the filesystem. This option can be used when migrating data using the zarafa-gateway, where the users won’t use IMAP/POP3 after the migration.

4.1.9. ical.cfg

# 7.0.3
The ical.cfg is extended with the following option:
enable_ical_get
This option enables the ical GET method to download an entire calendar. When set to yes, the GET method is enabled and allowed. If not, then calendars can only be retrieved with the CalDAV PROPFIND method, which is much more efficient. This option allows you to force the use of CalDAV which lowers load on your server.

4.1.10. ldap.propmap.cfg

# 7.0.4
The ldap.propmap.cfg has additional entries for the Archiver 1.2 functionality
# ldap relations to the archiver 1.2 functions for automatic archiver store mappings
# PR_EC_ARCHIVE_SERVERS
0x67C4101E      =       zarafaUserArchiveServers
# PR_EC_ARCHIVE_COUPLINGS
0x67C5101E      =       zarafaUserArchiveCouplings

4.1.11. ldap.openldap.cfg

# 7.0.4
The ldap.openldap.cfg has additional entries for the Archiver 1.2 functionality
# Users will have a private archive store on these names servers.
# Optional, default zarafaUserArchiveServers
ldap_user_archive_servers_attribute = zarafaUserArchiveServers
# Users will have a many-to-one archive on these store:folder pairs.
# The expected result is a list of <username>:<foldername> pairs, where each
# username will be used to resolve the store in which the folder named
# foldername will be used as the archive.
# Optional, default zarafaUserArchiveCouplings
ldap_user_archive_couplings_attribute = zarafaUserArchiveCouplings
# 7.0.6
The ldap.openldap.cfg was altered with ZCP-9554 to better suite an used default of the LDAP group members relation.
# LDAP: uid, matching users in ldap_loginname_attribute
ldap_groupmembers_relation_attribute = uid
The +ldap.active-directory.cfg / ldap.openldap.cfg+ was altered
# Default ADS MaxPageSize is 1000.
ldap_page_size = 1000
# 7.1
To support multiple LDAP servers, the ldap_uri option is added to the ldap.openldap.cfg.
ldap_uri

4.1.12. ldap.active-directory.cfg

# 7.0.4
The +ldap.active-directory.cfg has additional entries for the Archiver 1.2 functionality # Users will have a private archive store on these names servers. # Optional, default zarafaUserArchiveServers ldap_user_archive_servers_attribute = zarafaUserArchiveServers
# Users will have a many-to-one archive on these store:folder pairs.
# The expected result is a list of <username>:<foldername> pairs, where each
# username will be used to resolve the store in which the folder named
# foldername will be used as the archive.
# Optional, default zarafaUserArchiveCouplings
ldap_user_archive_couplings_attribute = zarafaUserArchiveCouplings
The +ldap.active-directory.cfg was altered
# Default ADS MaxPageSize is 1000.
ldap_page_size = 1000
# 7.1
To support multiple LDAP servers, the ldapuri option is added to the ldap.active-directory.cfg.
ldap_uri

Chapter 5. Changes in 7.1.1

This .1 minor is the first after the brand new general release of version 7.1 and is a maintenance release for this 7.1 Zarafa Collaboration Platform. The focus of the release in the primary support phase is on stability and security and compatibility with evolving 3rd party software clients and browsers.
In this minor especially stability and usability items, including documentation items to existing functions and the new functions of 7.1 were addressed related to all parts of ZCP. This minor included issues found during upgrades from 5.2 ZCP versions or up and performance optimisations related to PHP, corrections to maintenance tools for the ZCP database and distribution related minor adjustments. The Zarafa offline mysql engine settings have been reviewed and for compatibility reasons now set to 128M on installs and upgraded. The caldav function for opening shared folders had been restored, and works also for Ical6. Ical6 is now a supported version in combination with ZCP 7.1. Users are urged to read the user manual section on caldav for proper usage and understanding.
The minor feature additions in this release are:
  • Include OCF scripts to use with Pacemaker in a new pacemaker-zarafa package
  • Increase max_allowed_packet to 128M on offline clients
  • Use boost filesystem v3 if available

5.1. Configuration file changes 7.1.1

No new or altered configurations were made in 7.1.1

Chapter 6. Changes in 7.1.2

This .2 minor is a maintenance release for this 7.1 Zarafa Collaboration Platform.
In this minor has a focus on stability and functionality items to existing functions of ZCP. Residual DST issues have been addressed that are caused by nations changing the DST offset time last year. The Zarafa WebApp 1.2 had been made standard as base version as of this ZCP release as well.
The minor feature additions in this release are:
  • WebApp 1.2 inclusion
  • Zarafa server will always write a coredump file by default when it segfaults
  • zarafa-admin unhook-store will print the store guid of a found user

6.1. Configuration file changes 7.1.2

The server.cfg is changed to always create coredumps
# create memory coredumps upon crash in the running_path directory
coredump_enabled = yes
The Zarafa schema file for OpenLDAP is slightly modified to have direct support for the default attributes in example ldap configuration files. The uidNumber attribute is added to MAY list of the zarafa-user objectClass and the gidNumber attribute is added to MAY list of the zarafa-group objectClass.

Chapter 7. Changes in 7.1.3

This .3 minor is a maintenance release for this 7.1 Zarafa Collaboration Platform.
The working of the zarafa client on Windows 8 was addressed as well as a number of issues preventing the offline Cached mode in Outlook to work optimally in different setups, when canceling a sync action that is ongoing. The sync process stopped too soon with network interruptions and errors and has been changed to recover from this better.
Also the inclusion if ics files in HTML emails could cause the body not to be displayed as the message was regarded as a meeting request. The extra spooler logging was repaired to work again with SYSLOG, and the zarafa-set-oof was adjusted to work with umlauts and to properly turn off again via the command line. Various Zarafa Archiver issues regarding logging are changed to include the used commands and the version of the Zarafa product as well. The option to search in read only archives has been restored.
The minor feature additions in this release are:
-The addition to use smime certificates in ldap. -Emailing to a usergroup including hidden users.

7.1. Configuration file changes 7.1.3

The server.cfg, gateway.cfg, ical.cfg, spooler.cfg are changed to disable SSLv2 and other less secure ciphers in different zarafa daemons
# Accept SSLv2 only connections. Normally v3 connections are used.
server_ssl_enable_v2 = no

Chapter 8. Changes in 7.1.4

This .4 minor is a maintenance release for this 7.1 Zarafa Collaboration Platform during the primary support phase of this production version.
A good quality improvement on the code has been done by resolving a series of hard to find segfault causes that could be resolved now by the contributions of community and collection of the data, issues were found in the use of a not thread safe library in Red hat and in the Zarafa stats routines. This last release a focus has been made again as part of a re-occurring effort on the verification of Meeting request logic with interactions of various end user clients to enhance the proper functionality and recheck the compatibility of clients, this has resulted in issues found and resolved in this release, as well as in upcoming releases. As part of this a series of time zone changes have been implemented which will also get a follow up in the next major release of Zarafa ZCP. The integration of Zarafa in Outlook 2010 has again been improved by the enabling of the delegate users button, allowing easier access to the open shared stores.
The minor feature additions in this release are:
-Enabled the delegate users button in Outlook 2010.

8.1. Configuration file changes 7.1.4

No changes were made to the default configuration files during this release.