Résolution des problèmes liés à la réplication des dossiers publics – Partie 4 : Conseils pour Exchange Server 2007/2010
Article d’origine publié le lundi 28 novembre 2011
Date de publication d’origine sur le blog américain : le 11 janvier 2008
Il y a deux ans, j’ai publié une série en trois parties consacrée à la résolution des problèmes de réplication des dossiers publics. La première partie abordait la réplication des nouvelles données, la deuxième partie celle des données existantes et la troisième partie examinait le processus de suppression des réplicas et certains des problèmes fréquemment rencontrés avec Exchange 2003. Avec ce nouveau billet, je souhaiterais mettre à jour cette série pour Exchange 2007.
Dans Exchange 2007, le fonctionnement du processus de réplication des dossiers publics est fondamentalement le même qu’auparavant. Les étapes de résolution des problèmes décrites dans les trois premières parties sont toujours d’actualité. En revanche, les outils d’administration ont évolué et les problèmes couramment rencontrés dans Exchange 2007 sont un tantinet différents. C’est ce que j’aimerais aborder ici.
Modifications apportées aux outils d’administration
Le journal des événements demeure votre meilleur outil lorsque vous cherchez à limiter un problème de réplication à un point de défaillance en particulier Dans la première partie, je suggérais de définir l’enregistrement pour les messages de réplication entrants et sortants sur la valeur maximale. Ce paramètre est toujours valable mais dans Exchange 2007, vous utiliserez la cmdlet Set-EventLogLevel pour définir « MSExchangeIS\9001 Public\Replication Incoming Messages » et « MSExchangeIS\9001 Public\Replication Outgoing Messages » au niveau Expert.
Dans la deuxième partie, je décrivais comment utiliser les options Synchroniser la hiérarchie et Synchroniser le contenu dans le Gestionnaire système Exchange pour obtenir un message d’état et faire expirer le délai d’attente de toutes les entrées de renvoi en attente. Ces opérations sont toujours possibles dans Exchange 2007 grâce aux cmdlets Update-PublicFolderHierarchy et Update-PublicFolder. Ces dernières sont également disponibles dans l’outil de gestion des dossiers publics de la version SP1 du produit et apparaissent sous la forme de l’option Mettre à jour la hiérarchie lorsque vous sélectionnez la racine des dossiers publics et de l’option Mettre à jour le contenu si vous choisissez un dossier public en particulier. Parce que vous pouvez les utiliser à partir de la ligne de commande, ces options sont beaucoup plus souples que celles d’Exchange 2003. Par exemple, il est désormais très simple de dépasser le délai d’attente des entrées de renvoi pour tous les dossiers dotés d’un réplica sur votre serveur Exchange 2007 grâce à une simple commande « Get-PublicFolderStatistics | Update-PublicFolder », ce qui n’était pas possible dans Exchange 2003 sans cliquer sur une multitude d’options.
Dans la troisième partie, il était question de la manière d’exploiter la vue Instances de dossiers publics pour savoir si la suppression d’un réplica était terminée. Dans Exchange 2007, vous utilisez la commande Get-PublicFolderStatistics pour vous procurer ces mêmes informations.
Problèmes courants dans Exchange 2007
Le symptôme que j’ai le plus fréquemment observé jusqu’ici est un échec du pilote de banque d’informations. Par exemple, une réponse de renvoi est transmise à un serveur Exchange 2007 mais si vous examinez le journal des applications côté Exchange 2007, vous ne voyez jamais l’événement de réplication entrant. La fonctionnalité de suivi des messages indique que le message de réplication est parvenu au serveur de transport Hub et a ensuite échoué au niveau du pilote de banque d’informations.
Ce problème peut se produire pour plusieurs raisons mais, heureusement, il n’est pas difficile à résoudre. Pour la résolution, votre meilleure approche dans ce cas est de faire appel aux fonctionnalités de suivi du pipeline et de suivi de la conversion de contenu disponibles sur le serveur de transport Hub. Si vous exécutez la commande « "Get-TransportServer | fl », des paramètres semblables à ce qui suit apparaîtront :
PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com
Pour savoir pourquoi votre réponse de renvoi échoue dans le pilote de banque d’informations, définissez le paramètre PipelineTracingSenderAddress afin qu’il soit conforme à l’adresse SMTP de la banque de dossiers publics chargée d’envoyer la réponse de renvoi. Définissez ensuite les paramètres ContentConversionTracingEnabled et PipelineTracingEnabled sur $true et reproduisez le problème. Ceci fait, jetez un coup d’œil au dossier spécifié par le paramètre PipelineTracingPath. Vous devriez y trouver un sous-dossier appelé ContentConversionTracing et un dossier InboundFailures dans celui-ci. Dans le dossier InboundFailures, vous trouverez un fichier EML contenant le message de réplication même et un fichier TXT renfermant quelques informations sur l’échec. Le haut du fichier TXT offre souvent des indices précieux sur les raisons de cet échec.
Par exemple, dans certains cas, les résultats apparaissent souvent dans le fichier TXT :
Microsoft.Exchange.Data.Storage.PropertyValidationException : Échec de validation de propriété. Propriété = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Erreur = L’élément 0 de la propriété à valeurs multiples est non valide.
Le problème présenté dans ce cas est lié à la propriété Categories. Il se produit si le dossier public concerné contient des éléments dont la propriété Categories est définie comme étant vierge mais pas réellement vide (un seul espace y est inclus, par exemple). Pour le vérifier, vous pouvez vous rendre dans Outlook et opter pour un affichage par catégories des éléments. Deux ensembles différents d’éléments doivent apparaître définis sur « None » (Aucun). Pour corriger le problème, il vous suffit de supprimer la catégorie actuelle dans tous les éléments « None » à l’aide d’Outlook. Vous devrez peut-être les définir sur une autre catégorie, puis les redéfinir sur « None ». Une fois la propriété Categories définie comme il se doit, vous disposerez d’un seul ensemble d’éléments affichant « None » et la réplication des éléments se fera correctement.
Autre exemple :
Microsoft.Exchange.Data.Storage.PropertyValidationException : Échec de validation de propriété. Propriété = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Erreur = Email2AddrType est trop long : la longueur maximale est 9, la longueur réelle est 35.
Dans cet exemple, la propriété Email2AddrType est la source du problème. Nous nous sommes aperçus que, à la place du type d’adresse normal qu’elle doit contenir (par exemple, 'SMTP' ou 'EX'), l’adresse de messagerie complète a été renseignée dans certains contacts. En corrigeant simplement le problème, nous avons pu répliquer les éléments.
Parfois, le pilote de banque d’informations échoue parce qu’il ne peut pas identifier une propriété précise à l’origine du problème, comme dans les résultats suivants :
Microsoft.Exchange.Data.Storage.ConversionFailedException : Contenu de message endommagé. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException : Échec de conversion de contenu en raison d’un contenu TNEF endommagé (état de violation : 0x00000800)
Voici le type d’échec auquel vous êtes confronté lorsque vous rencontrez le problème décrit dans l’article 936000 de la Base de connaissances Microsoft. Pour corriger ce problème, il vous suffit d’appliquer le correctif sur le serveur Exchange 2003 qui génère le message de réplication.
Le plus important à retenir de tout ceci est qu’Exchange 2007 valide un grand nombre de propriétés pour empêcher les mauvaises données d’infiltrer la banque. C’est aussi une bonne chose car cela empêche toute réplication des données de dossiers publics à partir de vos serveurs Exchange 2003 tant que les problèmes de contenu ne sont pas corrigés sur ces mêmes serveurs. Le paramètre ContentConversionTracing peut vous aider à identifier ces problèmes et vous orientera souvent vers la propriété véritablement responsable du problème.
Il existe un autre problème courant que vous pouvez identifier au moyen du paramètre ContentConversionTracing mais il n’est pas réellement lié au contenu. Le fichier TXT dans le dossier InboundFailures se présentera ainsi :
Microsoft.Exchange.Data.Storage.ConversionFailedException : Limite de conversion du contenu dépassée.
sur Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
sur Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
sur Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)
InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False
ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True
Notez d’abord ce que dit la première ligne : « Limite de conversion du contenu dépassée ». Normalement, un message de réplication de dossiers publics ne souffre d’aucune limitation en termes de taille. Alors comment expliquer un tel échec du message ? Notez que le paramètre « isSenderTrusted » a la valeur False. Cela signifie que le message provenait d’une connexion SMTP qui n’était pas authentifiée. Soit l’authentification du serveur de réception a été un échec, soit ce dernier n’a jamais fait aucune tentative. Ceci ressemble beaucoup à ce que décrivait la section « Problèmes courants » de la troisième partie où il était question d’un échec d’authentification entraînant lui-même un échec du verbe XEXCH50 dans Exchange 2003. Le serveur de réception n’étant pas authentifié, le serveur Exchange 2007 applique les restrictions de taille normales au message. S’il s’agit d’un message de réplication de contenu qui comporte plus de 250 pièces jointes (ce qui n’est pas rare pour une réponse de renvoi de contenu), alors il échouera puisqu’il dépasse la taille limite admise. Souvent ce problème se pose parce qu’un administrateur a créé un deuxième connecteur de réception interdisant toute authentification mais l’a configuré pour qu’il écoute sur l’adresse IP interne plutôt que sur l’adresse IP externe. Si la cause est ailleurs, vous devrez peut-être réaliser une capture Netmon pour identifier le problème comme je l’ai décrit dans la troisième partie.
Conclusion
Vous disposez à présent de tous les éléments qui vous permettront d’isoler les problèmes de réplication de dossiers publics dans un environnement Exchange 2007. Toutes les étapes des versions précédentes du produit restent valables. Seule différence : les outils d’administration sont différents et les problèmes qui se posent ne sont plus les mêmes. J’espère que ce billet vous sera utile !
Ceci est une version localisée d’un billet de blog. Vous trouverez la version originale à la page Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips