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é :
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>
.
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 :
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).
Mise à jour 4.0.x vers 41.
Attention : dans le cadre d'une mise à jour de BlueMind 4.0.x vers 4.1, 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.