Sv translation

language	fr

Introduction

La version 4 de BlueMind intègre des évolutions majeures en terme d'architecture avec d'une part le support d'Outlook nativement et d'autre part une réplication des données pour préparer les données de messagerie pour Outlook et d'autres usages (nouveau webmail, périphériques mobiles en particulier).

La réplication

La réplication, une active par shard de mail (donc une par rôle mailbox-role), permet à Cyrus de transmettre une copie des messages au service bm-core. Le service bm-core va utiliser cette réplication pour récupérer des "métadonnées" des messages nécessaires pour bm-eas, bm-mapi et la recherche ElasticSearch. Ces "métadonnées" sont stockées en base de données (comme le fait Exchange) et dans ElasticSearch.

Ainsi, il est possible d'avoir repris la totalité d'un spool de mail (coté Cyrus), les mails étant visibles dans le webmail et Thunderbird, alors que la réplication est en échec. Dans ces conditions, les messages ne sont pas disponibles (tout ou partie) :

dans Outlook
via EAS (smartphones)
dans le moteur de recherche (webmail, smartphones)
pour la création des filtres dans les paramètres utilisateurs ou la console d'administration (les dossiers n'apparaissent pas)

Volet

Sur cette page :

Sommaire

maxLevel	2

En relation :

Monitoring Bm-Tick
Logs - Fichiers journaux

Mise oeuvre de MAPI pour Outlook

Reprise de données et réplication

Au stade actuel de stabilisation du protocole MAPI entre BlueMind et Outlook, la reprise des données par chargement PST depuis Outlook est à proscrire. De façon générale, une reprise de données par processus cadré coté serveur est plus sûre et sera plus cohérente en terme de résultat de reprise.

Les solutions de reprise conseillées sont :

l'outil de migration Exchange
l'outil de reprise PST coté serveur
les outils de synchronisation IMAP avec imapsync (voir préconisations ci-dessous)
l'outil de reprise Domino

La réplication extrait et stocke des informations du spool de mail dans des objets BlueMind qui doivent exister au préalable. Ainsi, pour le bon fonctionnement de la réplication, seules des données connues de BlueMind doivent être alimentées dans cyrus : les domaines et mailbox doivent donc être créés préalablement dans la console d'administration (ou via API), avant de remplir les boîtes mail.

Actuellement, en admin0 (super-administrateur BlueMind), il est possible de reprendre les données BlueMind sans tenir compte des objets et des règles de stockage des mails de BlueMind. En effet, avec les droits admin0, des données de messagerie peuvent être stockées sur le serveur Cyrus sans qu'aucune vérification de droit ou de cohérence ne soit faite. Pour cette raison, les données peuvent être vues comme incohérentes pour BlueMind et ainsi faire échouer la réplication. Nous déconseillons donc l'import de données par imapsync avec l'utilisateur admin0.

Pour éviter cela, si une reprise des données BlueMind par imapsync est prévue, il est important que l'imapsync soit effectué avec le login de l'utilisateur lui-même. En faisant les opérations en tant qu'utilisateur de la messagerie, on est assuré que le compte existe, que la partition est la bonne, etc...

Pour créer une clé API pour un utilisateur donné :

https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/python-api-examples/generateUserToken.py

Exemple de reprise de données à adapter selon le serveur source et les comptes / données à récupérer :

https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/migration/4.0/kerio

De manière générale et en particulier pour la 4, il est fortement recommandé de tester la reprise de données sur un serveur de test, qui sera ré-installé ou détruit ensuite. Le processus de reprise de données, une fois validé, doit être effectué sur un serveur (ou un domaine) vierge, sans trace des opérations effectuées en phase de test. La connexion LDAP / AD, les reprises de données par ImapSync ou reprise Exchange, une fois prototypées avec succès, peuvent être re-jouées sur le serveur de production.

Vérification du bon fonctionnement de la réplication

Dans la console de supervision bm-tick vous pouvez surveiller le tableau (dashboard) "Mailspool & Replication". Deux graphiques en particulier sont importants :

Nombre de messages répliqués par heure :

Nombre de réplications actives :

Ce nombre doit être de 1 par serveur ayant le rôle mailbox et donc le service bm-cyrus-imapd, si ce nombre chute c'est que la réplication ne se fait pas/plus.

A contrario, si ce nombre dépasse le nombre de backend IMAP, c'est dans la plupart des cas que le rôle a été attribué à un (ou plusieurs) serveur de stockage séparé mais que le service tourne toujours sur le serveur principal. Il convient alors de forcer la désactivation en créant les fichiers suivants sur le bm-core puis en stoppant les services :

Bloc de code
touch /etc/bm/bm-cyrus-imapd.disabled touch /etc/bm/bm-lmtpd.disabled systemctl stop bm-cyrus-imapd ; systemctl stop bm-lmtpd

A chaque instant, pour voir si la réplication est fonctionnelle, vous pouvez faire une opération sur un mail (par exemple le passer en non lu) et vérifier grâce à une commande tail si, au même instant, une ligne de ce type s'ajoute dans le fichier de log /var/log/bm/replication.log :

Bloc de code
{{APPLY MAILBOX (.... loginUtilisateur ) }}

Avancement du process de réplication

Des améliorations tick vont permettre dans les versions futures d'avoir une meilleure vision de l'avancement de la réplication.

En attendant, il est possible de comparer le nombre de mails des spools de mails et d'archives avec le nombre d'entrées dans la table stockant les messages. La correspondance n'est pas exacte, mais donne une bonne vision de l'avancement.

Ainsi, pour connaître le nombre de mail à synchroniser :

Bloc de code
# Nombre de mails du spool : find /var/spool/cyrus/data/ -type f\|wc -l # Nombre de mails des archives : find /var/spool/bm-hsm/cyrus-archives -type f\|wc -l

La somme des deux doit être proche du résultat de la requête sur la base bj-data :

Bloc de code
select count(*) from t_message_body;

A noter que le flux standard de réplication ne surveille que les boites aux lettres "vivantes". Cela signifie que si le delta de réplication reste significatif alors que la réplication est presque arrêtée, tous les utilisateurs actifs ont bien été répliqués et ont accès aux fonctionnalités associées (recherche webmail, EAS, etc.).
À noter aussi que le comptage est approximatif: si un mail est envoyé à N utilisateurs, il sera compté une fois dans t_message_body mais sera présent N fois dans le spool.

Pour lancer la réplication sur les boites passives (non utilisées), il faut positionner l'ensemble des boites dans la file de réplication avec la commande suivante, après avoir nettoyé certains logs de Cyrus :

Bloc de code

#nettoyage cyrus
service bm-cyrus-imapd stop
rm /var/lib/cyrus/sync/core/log*
service bm-cyrus-imapd start
#lancement de la réplication
bm-cli maintenance repair --ops replication.parentUid $DOMAIN_UID$

où $DOMAIN_UID$ est le nom du domaine, par exemple : bluemind.net

BlueMind sans MAPI

Outlook

Sans le service MAPI, Outlook continue de fonctionner avec connecteur de la même façon qu'en version 3.5. Les administrateurs doivent effectuer la même procédure de Mise a disposition du connecteur Outlook pour que les utilisateurs puissent le télécharger et l'installer sur leurs postes.

Cyrus

À partir de la version 4.1, une vérification de l'arborescence Cyrus est réalisée au démarrage de BlueMind et alerte (au moyen d'un warning dans les logs) si l'arborescence n'est pas cohérente.

BlueMind avec MAPI

Autodiscover

À partir de la version 4.1, une vérification de l'autodiscover est réalisée sur tous les domaines et alias de l'installation : si aucun autodiscover ne fonctionne alors le service MAPI ne démarre pas, si au moins un autodiscover est bon alors le service démarre afin de servir les domaines accessibles.

Ainsi pour chaque domaine et alias, le serveur mapi tente une requête vers domain.loc/autodiscover et autodiscover.domain.loc/autodiscover et vérifie qu'il reçoit bien lui-même la requête.

Une vérification est aussi effectuée sur le serveur DNS pour vérifier l'enregistrement _autodiscover._tcp.domain.loc et _autodiscover.<tous les alias>.

Remarque
Pour s'assurer que le serveur est correctement configuré et joignable sur ces urls, on pourra utiliser l'outil de diagnostique en ligne de Microsoft : https://testconnectivity.microsoft.com/

Cyrus

À partir de la version 4.1, une vérification de l'arborescence Cyrus est réalisée au démarrage de BlueMind et alerte (au moyen d'un warning dans les logs) si l'arborescence n'est pas cohérente.

Outlook

Création d'un profil Outlook vierge

Afin de correctement connecter les Outlook sans connecteur, il convient dans un premier temps de bien suivre la documentation de mise en œuvre côté serveur :

Mise œuvre de MAPI pour Outlook

Nous attirons tout particulièrement votre attention sur le chapitre concernant les prérequis de communication avec le serveur : l'autodiscover doit fonctionner correctement pour qu'Outlook puisse communiquer avec BlueMind.

Ensuite, pour chaque poste, suivre la documentation de création d'un profil pour Outlook :

Synchronisation avec Outlook

Là aussi, attention à bien valider au préalable l'accessibilité des urls depuis le poste.

Limitations Outlook liées au fonctionnement de BlueMind

Les limitations connues concernant le fonctionnement d'Outlook sont répertoriées dans notre page dédiée à la compatibilité de BlueMind avec les logiciels clients et appareils

Limitations connues

Vous pouvez consulter les limitations connues référencées dans la documentation de compatibilité de BlueMind.

Mise à jour de BlueMind 4.0 vers 4.

1

x

Dossiers sous la boîte de réception

Dans les versions 4.0.x de BlueMind (4.0.x), les dossiers créés sous la boîte de réception par Outlook ne sont pas des dossiers de messagerie mais des dossiers virtuels.

BlueMind 4.1 apporte le support des sous-dossiers de la boîte de réception (inbox).

Remarque

title	Mise à jour 4.0.x vers 414.x

Attention : dans le cadre d'une mise à jour de BlueMind 4.0.x vers 4.1 ou supérieure, les dossiers virtuels ne seront pas migrés et seront supprimés.

Pour se prémunir de cela, il est possible de déplacer ces dossiers virtuels en dehors de la boîte de réception avant la mise à jour de façon à les conserver, ils pourront ensuite y être remis et seront recréés en tant que dossiers de messagerie.

Sv translation

language	en

Introduction

BlueMind's version 4.0 incorporates major upgrades in terms of architecture including on the one hand, native Outlook support and on the other hand data replication to prepare the mail system's data for Outlook and other uses (new webmail, mobiles devices in particular).

Replication

Replication -- one active one for each mail shard (and therefore one for each mailbox-role) – allows Cyrus to send a copy of messages to the bm-core service. The bm-core service uses replication to retrieve the necessary message metadata for bm-eas, bm-mapi and ElasticSearch. This metadata is stored as a database (like Exchange does) and in ElasticSearch.

As a result, you may have migrated an entire mail spool (on the Cyrus side), as messages are visible in webmail and Thunderbird, but replication fails. Under those circumstances, messages – all or some of them – are not available:

in Outlook
via EAS (smartphones)
in the search engine (webmail, smartphones)
to create filters in user settings or the admin console (the folders are not shown)

Volet

On this page:

Sommaire

Mise oeuvre de MAPI pour Outlook

Data migration and replication

Given current BlueMind-Outlook stability with the MAPI protocol, migrating data through a PST upload in Outlook is not an option. As a whole, server-side data migration is safer and the result will be more consistent.

Recommended data migration solutions include:

Exchange migration tool
server-side PST migration
IMAP synchronization tools with imapsync (see recommendations below)
Domino migration tool

Replication extracts and stores mail spool information into BlueMind objects that must exist beforehand. For replication to work properly, only data known by BlueMind must be fed into Cyrus: domains and mailboxes must therefore be created in the admin console (or via API), before the mailboxes are filled with data.

Currently, as admin0 (BlueMind super-administrator), you can migrate BlueMind data without worrying about BlueMind objects and mail storage rules. With admin0 privileges, mail data can be stored on the Cyrus server without undergoing any rights or consistency checks. This is why BlueMind may see the data as inconsistent and may cause the replication to fail. We are therefore advising you against importing data through imapsync as the admin0 user.

To avoid this, if you are planning an imapsync transfer of BlueMind data, it is important for the imapsync to be carried out with the user's login ID. By performing operations as a mail user, you are assured that an account exists, with the correct partition, etc.

To generate an API token for a specific user:

https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/python-api-examples/generateUserToken.py

This link shows and example of data migration which you can adapt depending on the source server and the accounts/data you want to transfer:

https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/migration/4.0/kerio

As a whole, and in particular for version 4.0, we strongly recommend that you test data migration on a test server, which will be re-installed or destroyed later. The migration process, once verified, can be done on a blank server (or domain), with no trace of the operations carried out during testing. The LDAP/AD connection, Imapsync or Exchange data migration, once prototyped successfully, can be replayed on the production server.

Checking that replication works properly

In the bm-tick monitoring console, you can watch the "Mailspool & Replication" dashboard. Two graphs are particularly relevant:

Number of messages replicated per hour:

Number of active replications:

This number must be 1 per server with the mailbox role and therefore the bm-cyrus-imapd service. If this number drops, this means that replication is no longer working.

On the contrary, if this number is higher than the number of IMAP backends, it usually means that the role has been given one – or several – separate storage server(s) but the service is still running on the main server. In that case you need to force-disable them by creating the following files on the bm-core and then stop the services:

Bloc de code
touch /etc/bm/bm-cyrus-imapd.disabled touch /etc/bm/bm-lmtpd.disabled systemctl stop bm-cyrus-imapd ; systemctl stop bm-lmtpd

To see if replication is working, you can perform an operation on an email (e.g. change it to unread) and using a tail command, check whether, at the same time, a line looking like the one below is added to the /var/log/bm/replication.log log file:

Bloc de code
{{APPLY MAILBOX (.... UserloginID ) }}

Replication progress

We are planning tick improvements in future versions which will allow you to check the replication process's progress.

In the meantime, you can compare the number of messages in the mail spool and archives with the number of entries in the message storage table. They won't match exactly, but it gives a pretty good idea of progress.

To find out the number of emails to be synchronized:

Bloc de code
# Number of messages in the spool: find /var/spool/cyrus/data/ -type f\|wc -l # Number of messages in the archives: find /var/spool/bm-hsm/cyrus-archives -type f\|wc -l

The sum of the two should be close to the result form the query on the bj-data database:

Bloc de code
select count(*) from t_message_body;

Note that the standard replication flow only watches "live" mailboxes. This means that if the replication delta is significant, then the replication has almost stopped, all active users have been properly replicated and have access to related features (webmail search, EAS, etc.). Also note that the count is approximate: if an email is sent to N users, it will be counted once in t_message_body but it will be present N times in the spool.

To start the replication on idle (unused) mailboxes, you must place them in the replication queue using the following command – after having cleaned some Cyrus logs:

Bloc de code
#cleaning cyrus service bm-cyrus-imapd stop rm /var/lib/cyrus/sync/core/log* service bm-cyrus-imapd start #running the replication bm-cli maintenance repair --ops replication.parentUid $DOMAIN_UID$

$DOMAIN_UID$ being the domain name, e.g.: bluemind.net

BlueMind without MAPI

Outlook

Without the MAPI service, Outlook continues to work with the connector like in version 3.5. Administrators must carry out the same provisioning procedure for the Outlook connector so that users can download and install it on their machines.

Cyrus

From version 4.1, the Cyrus folder structure is checked on BlueMind startup and an alert – a warning in logs – is sent if an inconsistency is found.

BlueMind avec MAPI

Autodiscover

From version 4.1, an autodiscover check is carried out on all installation domains and aliases. If no autodiscover works, then the MAPI doesn't start. If at least one autodiscover works, then the service starts in order to serve accessible domains.

As a result, for each domain and alias, the MAPI server attempts a query to domain.loc/autodiscover et autodiscover.domain.loc/autodiscover and checks that itself receives the query.

A check is also carried out on the DNS server to check the recording service _autodiscover._tcp.domain.loc and _autodiscover.<all aliases>.

Remarque
To make sure that the server is configured properly and can be reached on these urls, you can use Microsoft's online troubleshooting tool: https://testconnectivity.microsoft.com/

Cyrus

From version 4.1, the Cyrus folder structure is checked on BlueMind startup and an alert – a warning in logs – is sent if an inconsistency is found.

Outlook

Creating a blank Outlook profile

To enable connector-free Outlook, first make sure you follow the server-side implementation steps described in our documentation:

Implementing MAPI for Outlook

In particular, make sure you read the section about server communications prerequisites: autodiscover must work properly for Outlook to be able to communicate with BlueMind.

Then, for each workstation, follow our instructions on creating an Outlook profile:

Synchronisation avec Outlook

In this case, make sure you first ensure url accessibility from the workstation.

Outlook with BlueMind limitations

Known limitations with Outlook are listed in our page on BlueMind's compatibility with client software and devices.

Known limitations

You can find known limitations in our page on BlueMind compatibility.

Updating from BlueMind 4.0 to 4.

1

x

Inbox subfolders

In BlueMind versions 4.0.x, folders created in the inbox by Outlook are not mailbox folders but virtual folders.

BlueMind 4.1 brings inbox subfolder support.

Remarque

title	Updating from 4.0.x to 414.x

Warning: when you udpate from BlueMind 4.0.x to 4.1 or later, virtual folders are not migrated and will be deleted.

To prevent this, you can move these virtual folders outside the inbox before you perform the update to keep them. You can then put them back into the inbox where they will be created as mail folders.

Arborescence des pages

Historique de la page

Comparaison des versions

Ancienne version 9

Nouvelle version 10

Légende

Introduction

La réplication

Reprise de données et réplication

Vérification du bon fonctionnement de la réplication

Avancement du process de réplication

BlueMind sans MAPI

Outlook

Cyrus

BlueMind avec MAPI

Autodiscover

Cyrus

Outlook

Création d'un profil Outlook vierge

Limitations Outlook liées au fonctionnement de BlueMind

Limitations connues

Mise à jour de BlueMind 4.0 vers 4.

x

Dossiers sous la boîte de réception

Introduction

Replication

Data migration and replication

Checking that replication works properly

Replication progress

BlueMind without MAPI

Outlook

Cyrus

BlueMind avec MAPI

Autodiscover

Cyrus

Outlook

Creating a blank Outlook profile

Outlook with BlueMind limitations

Known limitations

Updating from BlueMind 4.0 to 4.

x

Inbox subfolders