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/BM/repos/production/browse/4.0/migration/mailsync_kerio.py

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 :

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 :

{{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 :

# 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 :

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 :

#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 à 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>.

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

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).