Résolution des problèmes liés à la réplication des dossiers publics – Partie 1 : Résolution des problèmes de réplication des nouvelles modifications
Article d’origine publié le lundi 28 novembre 2011
Date de publication d’origine sur le blog américain : le 17 janvier 2006
Remarque : ce billet de blog est le premier d’une série consacrée à la résolution des problèmes liés aux dossiers publics. N’oubliez pas les parties 2, 3 et 4 de la série.
Introduction
Cette série de billets de blog a pour but de vous guider face aux problèmes de réplication des dossiers publics que vous devez résoudre. L’objectif n’est pas de vous montrer exactement comment résoudre tous les problèmes de réplication susceptibles de se poser mais plutôt comment isoler ces problèmes pour concentrer votre résolution sur le point de défaillance. En d’autres termes, la finalité de ce billet, c’est de partir d’un problème de type « Impossible de répliquer le contenu de mon ancien serveur sur mon nouveau serveur » pour arriver à un problème beaucoup plus ciblé tel que « Mon ancien serveur ne répond pas aux demandes d’état de mon nouveau serveur si bien que celui-ci ne sait pas qu’il lui manque des données et ne tente aucun renvoi. Le problème semble donc provenir de l’ancien serveur ». Ce billet explique aussi comment identifier certains des problèmes de réplication les plus courants. Avant d’entrer dans les détails du processus de résolution, laissez-moi vous résumer mon approche générale de ces problèmes.
Le meilleur outil de résolution des problèmes pour la réplication des dossiers publics est le journal des applications. Pour isoler un problème de réplication, vous devez être capable de suivre les événements de réplication dans le journal pour savoir où le processus s’interrompt. Comme point de départ pour la résolution, la règle générale voudrait que vous définissiez l’enregistrement des diagnostics pour les messages de réplication entrants et sortants sur la valeur maximale. Chaque fois qu’une banque envoie ou reçoit un message de réplication, elle consigne un événement à cet effet (en partant du principe que l’enregistrement est activé). Les diverses catégories de messages de réplication peuvent se distinguer selon le type affiché dans la description de l’événement. Je préfère me concentrer sur le type plutôt que sur l’ID d’événement, et ce pour plusieurs raisons :
- Les ID d’événements varient selon les versions d’Exchange. Par exemple, dans Exchange 5.5, une demande de renvoi sortante était un événement 3014. Dans Exchange 2000 et 2003, c’est un événement 3016.
- Les ID d’événements entrants et sortants sont différents selon chaque type. Un message de hiérarchie sortant est un événement 3018 tandis qu’un message de hiérarchie entrant est un événement 3028.
- Les demandes d’état et les messages d’état utilisent les mêmes ID d’événements malgré le fait qu’il existe deux types distincts de messages. Par conséquent, vous ne pouvez pas les distinguer à partir de l’ID d’événement seul.
Se concentrer sur le type est un peu plus facile. Vous pouvez aisément mettre en corrélation les types et les ID d’événements en examinant votre journal des applications. Il existe uniquement sept types et vous pouvez voir si le message est sortant ou entrant en observant la catégorie de l’événement. Si vous optez pour les types plutôt que les ID d’événements, seuls les éléments suivants sont à garder en mémoire :
Hiérarchie - 0x2
Contenu - 0x4
Demande de renvoi - 0x8
Réponse de renvoi - 0x80000002 (hiérarchie) ou 0x80000004 (contenu)
État - 0x10
Demande d’état - 0x20
Notez également que l’enregistrement des erreurs de réplication est rarement utile. Même lorsque la réplication fonctionne normalement, la plupart des serveurs génèreront un grand nombre d’événements d’erreur de réplication, tels que l’ID d’événement 3093 qui indique une erreur de lecture d’une propriété. Dans la majorité des cas, la propriété n’a aucune incidence sur la réplication et l’erreur peut-être ignorée. Je recommande de laisser l’enregistrement des erreurs de réplication défini sur Aucun sauf si vous recherchez quelque chose en particulier, tel que le problème décrit dans ce précédent billet de blog.
Résolution des problèmes de réplication des nouvelles modifications
Pour résoudre les problèmes découlant de la réplication des dossiers publics, vous devez d’abord vous familiariser avec le flux de messagerie normal généré lorsque la réplication fonctionne. Grâce ces informations, vous pouvez identifier le point de défaillance dès la survenue d’un problème. Avant d’aborder la manière de résoudre les problèmes liés à la réplication de nouvelles modifications, examinons en détail le comportement attendu.
Réplication de hiérarchie
La réplication des nouvelles modifications apportées à la hiérarchie a lieu à chaque fois que vous créez ou supprimez un dossier ou même modifiez les propriétés d’un dossier public, notamment la liste de réplicas, les autorisations client, la description, la note administrative ou les limites de stockage. Notez que ceci ne comprend pas les adresses de messagerie dans un dossier à extension messagerie. Les adresses de messagerie sont stockées dans l’objet répertoire dans Active Directory et leur modification n’aboutit donc pas à une réplication de la hiérarchie. Seule la modification des propriétés stockées dans la banque publique entraînera cette réplication.
Toutes les 15 minutes (par défaut), la banque diffuse toutes les modifications qui ont été apportées aux propriétés des dossiers dans un ou plusieurs messages de réplication de hiérarchie. Avec l’enregistrement défini au maximum pour les messages de réplication sortants, vous constaterez un événement semblable au suivant sur le serveur sur lequel la hiérarchie a été modifiée :
Type d’événement : Information
Source de l’événement : Banque de dossiers publics MSExchangeIS
Catégorie d’événement : Messages de réplication sortants
ID d’événement : 3018
Description :
Un message de réplication sortant a été émis.
Type : 0x2
ID de message : <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>
Base de données « Premier groupe de stockage\Banque de dossiers publics (BILONGEXCH1) »
CN min : 1-72CF, CN max : 1-72D3
RFI : 1
1) FID : 1-6994, PFID : 1-1, Décalage : 28
IPM_SUBTREE\NewFolder
Notez la mention « Type : 0x2 » au début de la description. C’est elle qui identifie le message en tant que message de réplication de hiérarchie.
Un message de réplication de hiérarchie est envoyé directement du serveur d’origine vers toutes les autres banques publiques. Le concept de topologie en matière de réplication des nouvelles modifications n’existe pas. Toutes les modifications apportées à la hiérarchie sont transmises directement du serveur où elles ont eu lieu vers tous les autres serveurs pour lesquels une banque publique est associée à la même hiérarchie. Tous les autres serveurs doivent consigner un événement entrant doté d’un type 0x2 lorsqu’ils traitent le message de réplication entrant avec succès.
Réplication de contenu
La réplication de contenu se produit lorsque vous créez ou supprimez un message ou bien modifiez les propriétés d’un message. Les heures auxquelles la banque diffuse les changements de contenu d’un dossier peuvent être modifiées en changeant la planification de réplication dans ce dossier mais, par défaut, les changements seront diffusés toutes les 15 minutes comme dans le cas de la hiérarchie. Un message de réplication de contenu est identifié par le type 0x4 dans la description de l’événement. Ici encore, le concept de topologie ne s’applique pas à la diffusion de nouvelles modifications. Lorsque vous modifiez le contenu d’un dossier dans un réplica donné, ce dernier envoie directement un message 0x4 à tous les autres réplicas du dossier. Dans ce cas aussi, tous les serveurs de réception doivent consigner un événement 0x4 entrant lorsqu’ils traitent le message entrant avec succès.
Étapes de résolution des problèmes
Il existe deux scénarios de base principaux pour la réplication. Lorsque de nouvelles modifications de hiérarchie ou de contenu ne sont pas transférées d’un serveur vers un autre, la résolution des problèmes est très simple.
1. Le serveur a-t-il généré un message de réplication sortant ?
Vous avez apporté une modification à un dossier ou ajouté du contenu à un dossier sur un serveur en particulier et ce contenu n’est parvenu à aucun autre serveur. La première question à se poser ici est la suivante : le serveur cible a-t-il diffusé les modifications ? Lors de la résolution des problèmes, il est primordial que vous suiviez le serveur avec lequel vous travaillez au moment d’effectuer les modifications. Plusieurs méthodes vous permettent de le faire. Dans le Gestionnaire système Exchange, cliquez avec le bouton droit sur le nœud Dossiers publics et choisissez « Se connecter à » pour pointer sur une banque précise. Le Gestionnaire système Exchange se chargera en grande partie de toutes les modifications à apporter à la banque en question sauf dans un cas bien précis : les autorisations client. Avant Exchange 2003 SP2, lorsque vous changiez les autorisations client à l’aide du Gestionnaire système Exchange, ce dernier tentait d’effectuer le changement dans une banque hébergeant un réplica du dossier, même si cela n’était pas nécessaire puisque les autorisations sont stockées sous la forme d’une propriété dans le dossier de la hiérarchie. Avec la version 2003 SP2 du Gestionnaire système Exchange, ce comportement a été modifié pour permettre désormais d’apporter des modifications dans la hiérarchie sur laquelle vous pointez. Lorsque vous testez la réplication de hiérarchie en effectuant des changements via le Gestionnaire système Exchange, il est préférable d’éviter d’utiliser les autorisations à des fins de tests car il peut être difficile de prévoir dans quelle banque le ou les modifications seront apportées, à moins que vous n’exécutiez le Gestionnaire système Exchange à partir d’Exchange 2003 SP2. Si vous utilisez Outlook et souhaitez vérifier quel réplica de dossier est concerné, vous pouvez faire appel à l’application MFCMAPI ou à un outil similaire pour afficher la propriété PR_REPLICA_SERVER du dossier. Vous connaîtrez alors le nom du serveur dont se sert Outlook pour accéder au contenu de ce dossier.
Si la planification de réplication est définie sur Toujours pour le dossier en question (ce qui est toujours le cas pour la hiérarchie), et si vous ne voyez aucun événement 0x2 ou 0x4 sortant au bout de 15 minutes, c’est le signe que quelque chose ne va pas sur le serveur d’origine. Si le serveur ne génère aucune diffusion de hiérarchie ou de contenu sortante, il est possible que le démarrage de l’agent de réplication ait échoué. L’un des scénarios courants est décrit dans l’article 272999 de la Base de connaissances Microsoft. L’élément clé à noter ici est l’événement 3079 :
ID d’événement : 3079
Source : Public MSExchangeIS
Type : Erreur
Catégorie : Erreurs de réplication
Description :
Erreur de thread de réplication inattendue (0x3f0).
EcGetReplMsg
EcReplStartup
FReplAgent
Ceci sera consigné même si aucun enregistrement supplémentaire n’est défini lors du montage de la banque publique. Si l’événement 3079 inclut la fonction « EcReplStartup », cela signifie que l’agent de réplication n’a pas pu démarrer et qu’aucun nouveau changement ne sera diffusé tant que le problème ne sera pas corrigé et la banque de nouveau montée.
La réplication de hiérarchie est également exposée à certains problèmes d’autorisations lorsque des banques publiques Exchange 5.5 sont présentes dans l’organisation. Quand un serveur Exchange 2000 ou 2003 envoie un message de réplication de hiérarchie à un serveur Exchange 5.5, il doit produire une propriété ptagACLData (autorisations de version 5.5 fondées sur des valeurs de nom unique legacyExchangeDN) à partir de la propriété ptagNTSD (autorisations de type Exchange 2000 basées sur des identificateurs de sécurité ou SID). Cela signifie que chaque SID doit être converti en une valeur legacyExchangeDN. Cette conversion de SID à valeur legacyExchangeDN peut échouer pour plusieurs raisons. Par exemple, si un SID est résolu en plusieurs utilisateurs, un événement semblable à celui-ci peut être généré :
ID d’événement : 9528
Catégorie : Général
Source : MSExchangeIS
Type : Erreur
Description :
Le SID S-1-5-21-408248388-469072634-37170099-1391 a été détecté sur 2 utilisateurs dans le SA et la banque d’informations ne peut pas allouer ce SID à un utilisateur unique.
Les utilisateurs concernés sont :
/DC=com/DC=société/CN=Utilisateurs/CN=Utilisateur1
/DC=com/DC=société/CN=Utilisateurs/CN=Utilisateur2
Parce qu’il est impossible de convertir le SID en nom unique legacyExchangeDN, la banque ne parviendra pas à générer un message de diffusion de hiérarchie sortant.
2. Le message a-t-il été adressé au serveur qui n’a pas reçu la modification ?
Si le message sortant a été généré par le serveur d’origine, l’étape qui suit consiste à s’assurer qu’il a été adressé au serveur qui n’a pas reçu les données. Le moyen le plus simple de le vérifier est de suivre le message. À l’aide de la fonctionnalité de suivi des messages, il vous suffit de suivre l’ID du message qui a été signalé dans l’événement de réplication sortant. La ligne « À : » sera visible dans la fenêtre Historique des conversations. Si la banque à laquelle les changements n’ont pas été apportés n’y apparaît pas, vous devrez alors porter votre attention sur le serveur d’origine. Voit-il ce serveur dans l’organisation ? Ce serveur dispose-t-il d’adresses de messagerie dans son objet banque publique ? Le serveur d’origine voit-il la banque dans la liste de réplicas disponible dans le dossier concerné ?
3. Le message est-il parvenu au serveur de destination ?
Après avoir vérifié que le message a bel et bien été adressé au serveur de destination, la question suivante à se poser est : le message a-t-il voyagé si loin ? Vous pouvez le déterminer à l’aide de la fonctionnalité de suivi des messages. Si la fonctionnalité confirme que le message a été remis à la banque alors qu’aucun événement de réplication entrant accusant réception du message n’apparaît, consultez la section « Problèmes courants » dans le dernier billet de blog de cette série.
Dans le billet de blog suivant : Résolution des problèmes de réplication des données existantes.
Ceci est une version localisée d’un billet de blog. Vous trouverez la version originale à la page Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes