Historique de la page
Sv translation | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||
Reprise de données et réplicationAu 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 :
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éplicationDans 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 :
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
Avancement du process de réplicationDes 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 :
La somme des deux doit être proche du résultat de la requête sur la base bj-data :
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.). 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 :
où BlueMind sans MAPIOutlookSans 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 MAPIAutodiscoverÀ 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 Une vérification est aussi effectuée sur le serveur DNS pour vérifier l'enregistrement
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. OutlookCréation d'un profil Outlook viergeAfin 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 BlueMindLes 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 connuesVous pouvez consulter les limitations connues référencées dans la documentation de compatibilité de BlueMind. Mise à jour de BlueMind 4.0 vers 4.1Dossiers sous la boîte de réceptionDans 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).
|
...