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/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é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 :
tail si, au même instant, une ligne de ce type s'ajoute dans le fichier de log Refonte de l'archivage BlueMindA partir de la version 4, l'archivage des messages (HSM) est géré nativement par Cyrus (voir la page dédiée : Archivage). Si votre installation utilisait déjà l'archivage en version 3.5, il est nécessaire de récupérer ces archives 3.5 pour les ré-intégrer dans Cyrus (qui le gérera ensuite de façon autonome et transparente selon la politique définie). Cela a un impact significatif sur les espaces de stockage des mails et implique des opérations de reprise généralement longues, à organiser de façon cohérente avec les étapes de mise à jour en 4. Une procédure détaillée de mise à jour en 4 décrit les opérations nécessaires pour la reprise des archives. Elle est disponible sur l'espace Partenaire : Procédure de mise à jour depuis BlueMind 3.5 vers BlueMind 4. Il est très important de la lire attentivement. DimensionnementPlusieurs réorganisation d'architecture et modifications du fonctionnement de BlueMind impacte le dimensionnement des espaces de stockage des serveurs BlueMind. Il faut être particulièrement vigilant pour éviter des "full disks" qui vont perturber, bloquer ou faire échouer la mise à jour en version 4. Voici les évolutions de stockage qui peuvent impacter votre installation de BlueMind :
En terme de ressources mémoire, pour permettre au service ElasticSearch de fonctionner pendant la phase de mise à jour, il est nécessaire de lui allouer 1,5Go supplémentaire. Ces besoins en espace disque supplémentaire sont expliqués dans la procédure de mise à jour vers la version 4 : Procédure de mise à jour depuis BlueMind 3.5 vers BlueMind 4. BlueMind sans MAPICe mode de fonctionnement a ses limites que BlueMind n'est pas en mesure d'outrepasser. C'est la raison pour laquelle BlueMind a développé la connexion native avec Outlook, solution qui permet une meilleure prise en compte des fonctionnalités d'Outlook. Si vos utilisateurs sont habitués et satisfaits du connecteur Outlook, ce fonctionnement peut être maintenu. Sinon, il est recommandé de basculer progressivement sur Outlook via MAPI. OutlookSans 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. Le mapping des dossiers n'est pas compris ni traduit par outlook. Les dossiers par défaut tels que Boite de réception, Message envoyés, etc. apparaissent en anglais, car consultés via le protocole IMAP, sans traduction à la volée. Cela ne gêne pas la bonne synchronisation d'un point de vue technique, mais peut être gênant pour les utilisateurs. À titre d'information, avec MAPI, le mapping est correctement géré. 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
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.xDossiers sous la boîte de réceptionDans les versions 4.0.x de BlueMind, 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).
OutlookRecommandations et bonnes pratiquesPour fonctionner dans sa version actuelle, Outlook ne doit pas être pollué par des "objets" qui ne viennent pas de BlueMind. C'est pourquoi il est indispensable de créer un profil Outlook vierge et de ne pas configurer un compte Exchange / Office365 sur le même profil. Par ailleurs, des clés de registres sont à appliquer, entre autres pour éviter des conflits de configuration avec des informations disponibles sur le réseau (DNS, ActiveDirectory). Ces clés de registres sont indiquées dans la documentation suivante : XXXXXXXXX Cré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 En cas de problèmes :Version 4.0, 4.1, 4.2, 4.3 et 4.4De très nombreuses améliorations ont été apportées dans les versions successives de BlueMind depuis la version 4.0. Toutes les versions antérieures à BlueMind 4.5 doivent être impérativement mises à jour rapidement pour bénéficier de toutes les améliorations développées. 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 :
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ù 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.xDossiers sous la boîte de réceptionDans les versions 4.0.x de BlueMind, 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).
|
Sv translation | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
Data migration and replicationGiven 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:
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 therefore advise 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 that you carry out the imapsync while logged in as the user. By performing operations as the user themselves, you can be assured that an account exists, with the correct partition, etc. To generate an API token for a specific user: This link shows an 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. BlueMind archiving system redesignFrom version 4, message archiving (HSM) is handled natively by Cyrus (see Archivage for more details). If you installation already used archiving in version 3.5, you must retrieve the 3.5 archives to re-introduce them into Cyrus (which will then manage it autonomously and transparently according to the policy). This has significant impact on mail storage spaces and typically entails lengthy migration operations, to be organized according to version 4 upgrade operations. The detailed upgrade to version 4 procedure describes the operations required for archive migration. It is available in our Partner Space: Procédure de mise à jour depuis BlueMind 3.5 vers BlueMind 4. Please make sure that you read it carefully. Storage space sizingSeveral architecture reorganization and changes to how BlueMind works affects BlueMind server storage space sizing. You must be extremely careful to avoid "full disks" which can interfere, block or cause the upgrade to fail. These are the storage changes that can impact your BlueMind install:
In terms of memory resources, to allow the ElasticSearch service to work during the upgrade, it must be allocated an additional 1.5Go. These extra storage space needs are laid out in: Procédure de mise à jour depuis BlueMind 3.5 vers BlueMind 4. BlueMind without MAPIThis option has limitations BlueMind isn't able to override. This is why BlueMind has developed a native connection with Outlook, which provides a better implementation of Outlook features. If your users are used to the Outlook connector and happy with it, it can be left as is. Otherwise, we recommend that you progressively move to Outlook via MAPI. OutlookWithout 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. Outlook doesn't understand or translate folder mapping . Default folders such as Inbox, Sent, etc. are shown in English because they are picked up via the IMAP protocol without being translated. This doesn't interfere with syncing from a technical point of view but may be disturbing for some users. You should note that MAPI handles mapping correctly. CyrusFrom 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 with MAPIAutodiscoverFrom version 4.1, an autodiscover check is carried out on all installation domains and aliases. If no autodiscover works, then MAPI service will not 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 A test is also carried out on the DNS server to check the recording service
CyrusFrom 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. OutlookRecommendations and best practiceTo work in its current version, Outlook must not be polluted by "objects" that do not come from BlueMind. This is why a blank Outlook profile must be created and no other Exchange/Office365 should be configured on the same profile. In addition, registry keys must be applied, among other things to avoid network configuration conflicts (DNS, ActiveDirectory). Registry keys can be found here: XXXXXXXXX Creating a blank Outlook profileTo enable connector-free Outlook, first make sure you follow the server-side implementation steps described in our documentation: Mise oeuvre de MAPI pour OutlookIn 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: Synchronization with OutlookIn this case, make sure you first confirm url accessibility from the workstation. Limitations of Outlook with BlueMindKnown limitations with Outlook are listed in our page on BlueMind's compatibility with client software and devices. If you encounter issuesVersions 4.0, 4.1, 4.2, 4.3 and 4.4Many improvements have been made to BlueMind since version 4.0. All BlueMind versions earlier than 4.5 must be updated quickly to benefit from all the latest updates. 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 with 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:
To check if replication is working, you can perform an operation on an email (e.g. change it to unread) and using a
Replication progressWe 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:
The sum of the two should be close to the result from the query on the bj-data database:
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:
Known limitationsYou can find a list of | |||||||||||||||||||
Sv translation | |||||||||||||||||||
| |||||||||||||||||||
Data migration and replicationGiven 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:
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: 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 properlyIn 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:
To see if replication is working, you can perform an operation on an email (e.g. change it to unread) and using a
Replication progressWe 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:
The sum of the two should be close to the result form the query on the bj-data database:
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:
BlueMind without MAPIOutlookWithout 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. CyrusFrom 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 MAPIAutodiscoverFrom 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 A check is also carried out on the DNS server to check the recording service
CyrusFrom 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. OutlookCreating a blank Outlook profileTo enable connector-free Outlook, first make sure you follow the server-side implementation steps described in our documentation: 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: In this case, make sure you first ensure url accessibility from the workstation. Outlook with BlueMind limitationsKnown limitations with Outlook are listed in our page on BlueMind's compatibility with client software and devices. Known limitationsYou can find known limitations in our page on BlueMind compatibility. Updating from BlueMind 4.0 to 4.xInbox subfoldersIn 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.
|
Sv translation | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
Datenübernahme und ReplikationIn der aktuellen Phase der Stabilisierung des MAPI-Protokolls zwischen BlueMind und Outlook ist eine Datenübernahme durch PST-Laden aus Outlook verboten. Im Allgemeinen ist einee serverseitig überwachte Datenübernahme sicherer und bezüglich der Übernahmeergebnisse konsistenter. Die empfohlenen Übernahmelösungen sind:
Die Replikation extrahiert und speichert Informationen aus dem Mailspool in BlueMind-Objekten, die zuvor existieren müssen. Damit die Replikation richtig funktioniert, dürfen folglich nur Daten in Cyrus eingespeist werden, die BlueMind bekannt sind: Domänen und Mailboxen müssen also in der Administrationskonsole (oder per API) angelegt werden, bevor die Mailboxen gefüllt werden. Derzeit ist es in admin0 (BlueMind-Superadministrator) möglich, BlueMind-Daten ohne Berücksichtigung von BlueMind-Objekten und Mail-Speicherregeln zu übernehmen. In der Tat können mit admin0-Rechten E-Mail-Daten auf dem Cyrus-Server gespeichert werden, ohne dass irgendwelche Rechte oder Konsistenzprüfungen durchgeführt werden. Aus diesem Grund können die Daten für BlueMind als inkonsistent angesehen werden und somit kann die Replikation fehlschlagen. Wir raten daher davon ab, Daten per imapsync mit dem Benutzer admin0 zu importieren. Um dies zu vermeiden, muss bei geplanter BlueMind-Datenübertragung per imapsync der imapsync mit dem Login des Benutzers erfolgen. Wenn Sie die Vorgänge als E-Mail-Benutzer durchführen, können Sie sicher sein, dass das Konto existiert, dass die Partition die richtige ist usw. So erstellen Sie einen API-Schlüssel für einen bestimmten Benutzer: Beispiel für eine Datenübernahme, die dem Quellserver und den wiederherzustellenden Konten/Daten anzupassen ist: https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/migration/4.0/kerio Generell und insbesondere für die 4 wird dringend empfohlen, die Datenübernahme auf einem Testserver zu testen, der anschließend neu installiert oder vernichtet wird. Die Datenübernahme muss, nachdem sie validiert wurde, auf einem leeren Server (oder einer leeren Domäne) durchgeführt werden, die keine Spur der in der Testphase durchgeführten Vorgänge aufweisen. Die LDAP / AD-Verbindung, die ImapSync-Datenübernahme oder die Exchange-Wiederherstellung können nach erfolgreichem Prototyping auf dem Produktionsserver nachgespielt werden. Replikation auf ordnungsgemäße Funktion prüfenIn der Überwachungskonsole bm-tick können Sie die Tabelle (Dashboard) „Mailspool & Replication“ überwachen. Zwei Graphen sind besonders wichtig: Anzahl der replizierten Nachrichten pro Stunde: :
Anzahl der aktiven Replikationen :
Diese Zahl muss 1 pro Server mit der Mailbox-Rolle und damit der bm-cyrus-imapd Dienst sein, wenn diese Zahl sinkt, bedeutet dies, dass die Replikation nicht (mehr) erfolgt. Umgekehrt, wenn diese Zahl die Anzahl der IMAP Backends übersteigt, ist es in den meisten Fällen so, dass die Rolle einem (oder mehreren) separaten Speicherserver(n) zugewiesen wurde, der Dienst aber noch auf dem Hauptserver läuft. Nun muss die Deaktivierung erzwungen werden, indem Sie die folgenden Dateien auf dem bm-core erstellen und dann die Dienste stoppen:
Um zu sehen, ob die Replikation funktioniert, können Sie jederzeit einen Vorgang mit einer E-Mail durchführen (z. B. sie ungelesen weiterleiten) und mit einem Befehl
Fortschritt des ReplikationsprozessesDie Tick Verbesserungen werden in künftigen Versionen einen besseren Überblick über den Replikationsfortschritt ermöglichen. Unterdessen kann die Anzahl der Mails in den Mail- und Archiv-Spools mit der Anzahl der Einträge in der Tabelle verglichen werden, in der die Nachrichten gespeichert sind. Die Entsprechung ist nicht exakt, gibt aber einen guten Überblick über den Fortschritt. Zum Beispiel, um die Anzahl der zu synchronisierenden E-Mails zu kennen:
Die Summe der beiden muss dem Abfrageergebnis auf der bj-Datenbank nahe kommen:
Beachten Sie, dass der Standard-Replikationsstrom nur „lebendige“ Mailboxen überwacht. Das heißt, wenn das Replikationsdelta signifikant bleibt, während die Replikation fast gestoppt ist, wurden alle aktiven Benutzer repliziert und haben Zugriff auf die zugehörigen Funktionen (WebmailWebmailer-Suche, EAS usw.). Um die Replikation auf passiven (unbenutzten) Boxen zu starten, müssen Sie alle Boxen mit dem folgenden Befehl in der Replikationswarteschlange positionieren, nachdem Sie einige Cyrus-Protokolle bereinigt haben:
wobei BlueMind ohne MAPIOutlookOhne den MAPI-Dienst arbeitet Outlook weiterhin mit dem Connector wie in Version 3.5. Administratoren müssen das gleiche Verfahren von Mise a disposition du connecteur Outlook aus durchführen, damit Benutzer es herunterladen und auf ihren Rechnern installieren können. CyrusAb Version 4.1 wird beim Start von BlueMind eine Überprüfung des Cyrus Baums durchgeführt und eine Warnung (durch eine Warnung in den Protokollen) erfolgt, wenn der Baum nicht konsistent ist. BlueMind mit MAPIAutodiscoverAb Version 4.1 wird eine Autodiscover-Prüfung auf allen Domänen und Aliassen der Installation durchgeführt: wenn kein Autodiscover funktioniert, dann startet der MAPI-Dienst nicht, wenn mindestens ein Autodiscover gut ist, dann beginnt der Dienst, die erreichbaren Domänen zu bedienen. Der mapi Server versucht also für jede Domäne und jeden Alias eine Anfrage an Eine Prüfung auf dem DNS-Server wird durchgeführt, um den Eintrag
CyrusAb Version 4.1 wird beim Start von BlueMind eine Überprüfung des Cyrus Baums durchgeführt und eine Warnung (durch eine Warnung in den Protokollen) erfolgt, wenn der Baum nicht konsistent ist. OutlookErstellen eines leeren Outlook-ProfilsUm Outlook ohne Connector korrekt zu verbinden, sollten Sie zunächst Implementierungsdokumentation auf der Serverseite lesen: Implementieren von MAPI für Outlook Wir weisen Sie insbesondere auf das Kapitel über die Anforderungen an die Serverkommunikation hin: Die automatische Erkennung muss korrekt funktionieren, damit Outlook mit BlueMind kommunizieren kann. Befolgen Sie für jede Position die Dokumentation zum Erstellen eines Profils für Outlook Auch hier ist darauf zu achten, dass die Zugänglichkeit der Urls vom Rechner aus vorher validiert wird. Outlook Einschränkungen in Bezug auf den Betrieb von BlueMindBekannte Einschränkungen bezüglich der Funktion von Outlook sind auf unserer Seite zur Kompatibilität von BlueMind mit Client-Software und Geräten aufgeführt Bekannte EinschränkungenSie können die bekannten Einschränkungen in der BlueMind-Kompatibilitätsdokumentationnachlesen. Aktualisierung von BlueMind 4.0 auf 4.xOrdner unter dem PosteingangIn BlueMind-Versionen 4.0.x sind die von Outlook unter dem Posteingang angelegten Ordner keine E-Mail-Ordner, sondern virtuelle Ordner. BlueMind 4.1 bietet Unterstützung für Posteingangs-Unterordner (Inbox).
|