Au cœur de SharePointDépannage de l'intégration de messagerie

Pav Cherny

Téléchargement du code disponible à l'adresse SharePoint2008_08.exe(416 Ko)

Sommaire

Approche de dépannage générale
Architecture de messagerie SharePoint
Obtention des informations de diagnostic
Transfert de messages sortants
Transfert de messages entrants
Gestion d'annuaire
Conclusion

Dans un environnement SharePoint bien conçu, les informaticiens n'ont pas besoin de changer leurs habitudes de communication ou de travail pour collaborer. Au lieu de devoir vérifier manuellement les sites de collaboration, SharePoint peut délivrer des documents et d'autres informations, comme les alertes et les rappels, directement dans leurs boîtes aux lettres.

Les utilisateurs peuvent également participer aux flux de travail en répondant à ces messages ou en envoyant de nouveaux éléments sous forme de messages électroniques à des bibliothèques et des listes de documents.

Cependant, l'intégration de SharePoint® dans un environnement de messagerie sécurisé présente de nombreux défis et elle offre une opportunité à des composants non SharePoint d'influer sur la collaboration basée sur SharePoint. Le défi est d'isoler et d'éliminer efficacement les causes initiales de problèmes dans l'environnement intégré où qu'ils apparaissent.

Dans cet article, j'aborde l'intégration de messagerie SharePoint basée sur une stratégie de dépannage éprouvée qui fournit des résultats rapides. L'idée est de localiser efficacement l'emplacement problématique puis de déterminer des étapes de dépannage plus détaillées et ciblées.

Dans une grande entreprise, cette investigation par phases peut nécessiter de transmettre le problème à un autre spécialiste après une analyse initiale, surtout si le problème est lié à des composants autres que SharePoint. D'un autre côté, dans les petites et moyennes entreprises, il n'est pas rare qu'un seul administrateur informatique doive dépanner tous les systèmes impliqués directement, ce qui met encore plus en évidence le besoin d'avoir une approche structurée.

Pour garder cet article pratique, j'utilise un environnement de test avec Active Directory®, Exchange Server 2007 et WSS 3.0. Les instructions détaillées pour créer cet environnement de test, de même que les outils de dépannage abordés dans cet article, dans le matériel associé, sont disponibles dans la section Téléchargements de code du site Web TechNet Magazine.

Approche de dépannage générale

Le dépannage de l'intégration de messagerie SharePoint nécessite une approche extrêmement structurée, peut-être même plus que dans d'autres scénarios d'interopérabilité. Plusieurs facteurs compliquent cette tâche.

Bien sûr, vous devez travailler avec des technologies complexes, et pendant que vous luttez avec les problèmes de transfert de messages, les conversions de format de message, les aspects de sécurité et les problèmes de gestion d'annuaire, vous découvrirez que certains messages d'erreur de SharePoint peuvent être troublants. Les groupes de discussion Internet sont pleins de threads de discussion non résolus et des suggestions qui vous peuvent vous entraîner sur la mauvaise piste, comme exécuter toutes les applications Web sous l'identité du pool d'applications pour l'Administration centrale de SharePoint pour assurer le travail d'intégration de messagerie.

Mais il y a également des aspects positifs. SharePoint est très flexible. En fait, il peut vous fournir des informations de dépannage détaillées si vous savez où regarder. Avec quelques scripts basiques, vous pouvez améliorer considérablement l'efficacité de votre dépannage.

Le premier objectif du dépannage est de comprendre le problème auquel vous êtes confronté. Vous avez besoin d'identifier où se situe le problème et quels composants il implique. Vous pourriez également essayer de reproduire le problème dans différentes configurations de système et étudier les journaux d'événements Windows® et les fichiers journaux texte. Mais ceci peut être difficile car certains problèmes ne se produisent que de manière sporadique. Ceci dit, mieux vous pourrez reproduire un problème, plus vite vous pourrez identifier et éliminer sa cause initiale. Autre objectif important, souvent négligé, est de décrire toutes les modifications de configuration et les correctifs et de s'assurer qu'ils sont appliqués sur tous les systèmes concernés dans l'environnement, ainsi que sur tous les serveurs principaux dans une batterie de serveurs Web.

Architecture de messagerie SharePoint

Chaque fois que vous êtes confronté à un problème lié à l'intégration de messagerie, il est judicieux de prendre d'abord sa tasse de café ou de thé et de vérifier l'architecture d'intégration de messagerie SharePoint avant de s'engager dans des opérations de dépannage. Sinon vous pourriez finir par régler le mauvais problème ou réparer le mauvais composant. Par exemple, une erreur « Accès refusé » qui vous empêche de créer un objet de contact dans Active Directory n'est pas nécessairement le signe qu'il faut modifier les autorisations d'accès dans Active Directory, comme vous le verrez plus tard.

Dans tous les cas, il est essentiel de comprendre le rôle de chaque composant impliqué dans l'intégration de messagerie et l'interaction des différents composants. Si vous regardez la figure 1, vous verrez les composants importants dans un scénario de connectivité SharePoint-Exchange, ils seront détaillés dans les sections suivantes.

fig01.gif

Figure 1 Architecture d'intégration de messagerie SharePoint (cliquez sur l'image pour l'agrandir)

Obtention des informations de diagnostic

L'un des éléments les plus importants pour le dépannage est des informations de diagnostic fiables. Le grand classique de toujours est le journal des événements Windows. Entre autres choses, vous pouvez contrôler le niveau d'écriture de SharePoint dans le journal des événements Windows sur les serveurs Web en utilisant Administration centrale de SharePoint (sur la page Opérations, sous Journalisation et création de rapports, cliquez sur Journalisation des diagnostics). Vous pouvez spécifier l'événement le moins critique à consigner dans le journal des événements et le journal de suivi. Le journal de suivi (situé par défaut sous %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) est très utile si vous cherchez des informations de bas niveau, mais il peut se remplir très rapidement. Donc utilisez cette fonctionnalité avec parcimonie.

Une autre façon d'obtenir des informations de diagnostic consiste à activer le débogage pour l'application Web concernée en configurant le fichier web.config correspondant, comme présenté dans le fichier Web Application Config.pdf du matériel associé. SharePoint affiche des informations de suivi détaillées directement dans l'interface utilisateur. L'un des avantages de cette approche est que vous pouvez voir les informations d'erreur pertinentes sans devoir analyser des mégaoctets de données de suivi. L'un des inconvénients est que vous devez modifier la configuration système de votre application Web. N'oubliez pas de sauvegarder le fichier web.config original puis de revenir à la configuration d'origine une fois le dépannage terminé.

Vous pouvez configurer également le service SMTP pour écrire des informations détaillées de processus dans le journal du protocole SMTP (dans le Gestionnaire des services Internet, sélectionnez la case Activer l'enregistrement dans le journal dans l'onglet Général). Assurez-vous que vous installez le module Journal ODBC avec la fonctionnalité Service SMTP, comme indiqué dans SharePoint Messaging Integration.pdf du matériel associé, même si vous n'avez pas l'intention d'utiliser le Journal ODBC. Sinon, le service SMTP n'écrira pas le journal de protocole. Par défaut, le journal de protocole SMTP est situé dans %SystemRoot%\System32\LogFiles\SmtpSvc1. C'est un fichier texte qui vous permet d'analyser en détail la communication SMTP et de déterminer si un message a quitté le serveur SharePoint.

Sur le serveur de transport Hub qui communique avec le service SMTP, vous pouvez activer également la journalisation de protocole dans Connecteur d'envoi et Connecteur de réception (voir SharePoint Messaging Integration.pdf). Vous pouvez utiliser différents autres outils pour suivre les chemins que prennent les messages dans l'environnement Exchange Server 2007 à travers les serveurs de transport Hub et les serveurs de Boîte aux lettres, tels que Suivi de messages, Afficheur des files d'attente et Suivi du pipeline. Si vous voulez des informations détaillées pour le dépannage de problèmes de flux de messages Exchange Server 2007, consultez la rubrique « Problèmes relatifs au transport et aux flux de messagerie » à l'adresse go.microsoft.com/fwlink/?LinkID=120145.

Sur les contrôleurs de domaine Active Directory, vous pouvez collecter des informations de dépannage détaillées en activant la journalisation des diagnostics pour Accès à l'annuaire et d'autres catégories en configurant les entrées de registre correspondantes sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Une valeur 0x0 pour une catégorie signifie que seuls les événements critiques sont enregistrés tandis qu'une valeur 0x5 représente tous les événements, y compris les informations de débogage. L'utilisation d'un niveau de journalisation supérieur à 0x3 peut dégrader les performances du serveur et remplir rapidement le journal des événements Windows. Lors des opérations normales, toutes les valeurs devraient être définies sur 0x0.

La collecte d'informations de diagnostic détaillées sur les serveurs SharePoint, Exchange et Active Directory dans une situation de dépannage peut vous aider à situer un point problématique rapidement et de manière fiable. Des outils de dépannage supplémentaires, comme les outils TCP/IP (ping, tracert, telnet, et ainsi de suite) et le Moniteur réseau, peuvent également s'avérer pratiques, car la majeure partie de la communication entre ces systèmes a lieu par le biais du réseau informatique. Microsoft® Network Monitor 3.1 est disponible à l'adresse go.microsoft.com/fwlink/?LinkId=120143.

Transfert de messages sortants

Ressources

Équipé des journaux d'événements, journaux de suivi, journaux de protocole, journaux de suivi de messages et traces réseau, je suis fin prêt à dépanner l'intégration de messagerie SharePoint. Commençons par la partie facile : le transfert de messages sortants. SharePoint prend en charge le transfert de messages sortants dans différentes configurations et ne nécessite pas de service SMTP local sur les serveurs Web. Cependant, dans un scénario complet d'intégration de messagerie, c'est la configuration recommandée pour utiliser le service SMTP local. La figure 2 présente les composants clé du scénario.

fig02.gif

Figure 2 Transfert de messages sortants (cliquez sur l'image pour l'agrandir)

Ce scénario de messagerie comprend quatre étapes : SharePoint doit transférer le message au service SMTP, le service SMTP doit traiter le message, le serveur de transport Hub doit recevoir le message, et Exchange Server 2007 doit transférer le message à sa destination finale.

Si SharePoint ne peut pas transférer le message au service SMTP, vous recevrez généralement une erreur dans l'interface utilisateur, par exemple une notification qu'un message électronique ne peut pas être envoyé. La cause peut en être que le service SMTP ne fonctionne pas. Ou peut-être que le journal SMTP de protocole vous dit que le service SMTP a refusé la tentative d'envoi avec le code d'erreur 550 (Action demandée non exécutée : boîte aux lettres non disponible), qui indique que le problème se situe au niveau du service SMTP.

Pour vérifier que le problème ne vient pas de SharePoint, vous pouvez utiliser un script de base (voir SMTP.VB dans le matériel associé) pour envoyer un message test via SMTP avec les mêmes informations d'expéditeur et de destinataire. Si c'est un problème de service SMTP, le script échouera. En fait, ce script pourrait vous donner de précieux indices sur la cause initiale du problème, ce que SharePoint ne révèle malheureusement pas même avec le débogage activé, comme illustré à la figure 3.

fig03.gif

Figure 3 Impossible de relayer des messages (cliquez sur l'image pour l'agrandir)

En accordant au serveur Web les autorisations de relais dans la configuration de service SMTP et en redémarrant le service SMTP, vous pouvez résoudre le problème d'envoi de messages de SharePoint. Maintenant le message peut atteindre le service SMTP, et la question importante suivante est de savoir si le service SMTP route le message au serveur de transport Hub.

Si le message reste dans le dossier de file d'attente, le service SMTP est incapable de contacter le serveur de transport Hub. La raison en est soit que le service de Transport Microsoft Exchange ne s'exécute pas, soit un problème de communication ou de configuration du réseau. En utilisant le client Telnet, vous pouvez vérifier rapidement et facilement si vous pouvez vous connecter au port de destination d'un Connecteur de réception configuré pour la communication interne.

Ceci n'est pas nécessairement le port TCP 25. En fait, si le service SMTP utilise ce port, vous pouvez transférer les messages au Connecteur de réception par défaut pour les serveurs de transport Hub, qui est configuré de manière à bloquer les envois de messages anonymes. Dans ce cas, vous verrez un fichier de message dans le dossier de dépôt. (Le service Minuteur de Windows SharePoint Services doit être arrêté, sinon, le message disparaît au bout de quelques secondes). Le fichier de message est une notification d'état de remise indiquant que le message a été refusé avec le « Code de diagnostic : smtp;530 5.7.1 Le client n'est pas authentifié ».

Pour résoudre ce problème, vous devez créer un Connecteur de réception dédié pour vos serveurs SharePoint. Parce que vos serveurs SharePoint sont des systèmes internes, choisissez l'option d'authentification Sécurisé de l'extérieur. De cette façon, vous n'avez pas besoin d'accorder des droits étendus au compte ANONYMOUS LOGON (Ouverture de session anonyme). Envisagez également d'utiliser IPSec pour protéger la communication entre les serveurs SharePoint et le serveur de transport Hub.

Si les messages quittent le dossier de file d'attente SMTP et que les journaux de protocole SMTP sur le serveur SharePoint et sur le serveur de transport Hub (vérifiez le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indiquent un transfert de messages réussi, vous pouvez considérer que le travail est fait, à condition que Exchange Server 2007 puisse router le message vers la destination. Comme nous l'avons dit précédemment, utilisez les outils de dépannage de flux des messages inclus dans Exchange Server 2007 pour examiner les problèmes si des messages n'atteignent pas les destinataires Exchange voulus. Notez que des informations de destinataire incorrectes, des filtres antispam et des restrictions de taille de message peuvent empêcher une remise finale à ce stade.

Transfert de messages entrants

Dans le sens inverse, le transfert de messages est légèrement plus compliqué parce que les problèmes potentiels sont plus subtils. Par exemple, la documentation produit de SharePoint recommande la configuration d'enregistrements MX dans DNS pour les domaines de messagerie électronique de SharePoint, ce qui est un bon moyen de mal acheminer les messages dans une organisation Exchange.

Exchange Server 2007 utilise des Connecteurs d'envoi avec les espaces d'adresse associés pour transférer les messages. Il peut router vos messages SharePoint vers des serveurs de transport Edge pour le transfert via Internet bien que vos serveurs SharePoint soient internes. Pour le transfert de messages interne, utilisez plutôt des Connecteurs d'envoi avec des espaces d'adresse détaillés et spécifiez vos serveurs SharePoint exécutant le service SMTP comme étant des hôtes intelligents dans la configuration de connecteur (voir le fichier SharePoint Messaging Integration.pdf dans le téléchargement associé). L'établissement d'une topologie de routage bien définie avec des serveurs de tête de pont dédiés permet un transfert de messages fiable d'Exchange à SharePoint.

Pour vérifier que les messages arrivent à vos serveurs SharePoint, arrêtez le service Minuteur de Windows SharePoint Services. Les messages s'accumuleront dans le dossier Drop parce que c'est le service Minuteur qui traite les messages et place les fichiers joint dans les bibliothèques de documents associées avec les adresses de messagerie de destinataire, comme indiqué dans la figure 4. Si les messages n'arrivent pas dans le dossier Drop, utilisez l'Afficheur des files d'attente sur votre serveur de transport Hub pour voir si Exchange achemine les messages correctement. Examinez alors les problèmes de communication réseau qui pourraient empêcher le serveur de transport Hub de communiquer avec le service SMTP sur le serveur SharePoint.

fig04.gif

Figure 4 Transfert de messages entrants (cliquez sur l'image pour l'agrandir)

Lorsque vous redémarrez le service Minuteur, vous devez voir les éléments de messages disparaître du dossier de dépôt. Cependant, si les pièces jointes de messages ne finissent pas comme documents dans les bibliothèques de destination bien que SharePoint indique que le traitement de message à réussi dans le journal d'événements Windows, cela signifie que Exchange a envoyé les messages au format RTF d'Exchange. Pour analyser ce problème, arrêtez le service Minuteur de nouveau, envoyez un autre message avec une pièce jointe à partir de votre client Outlook®, puis ouvrez le message dans le Bloc-notes une fois qu'il est arrivé dans le dossier de dépôt. Cherchez maintenant la chaîne « winmail.dat ». Si vous la trouvez, Exchange Server envoie les messages dans le mauvais format.

SharePoint exige le codage des pièces jointes de messages au format MIME ou UUENCODE. En outre, SharePoint n'affiche pas de problèmes liés à winmail.dat dans le journal des événements Windows (voir la figure 5). Les fichiers joints ne s'afficheront simplement pas dans la bibliothèque de documents. Utilisez le Bloc-notes comme outil de dépannage et corrigez le problème de mise en forme en configurant une définition de Domaine distant dans la Console de gestion Exchange pour le domaine de messagerie électronique SharePoint. Dans l'onglet Format du message d'origine envoyé comme pièce jointe à l'état de journal, sous Format RTF Exchange, sélectionnez Never use (Ne jamais utiliser).

fig05.gif

Figure 5 Traitement de message Winmail.dat (cliquez sur l'image pour l'agrandir)

Gestion d'annuaire

L'un des événements les plus utiles du service Minuteur est l'événement 6873, qui déclare qu'une erreur est survenue pendant le traitement d'un fichier de message électronique entrant à cause d'un alias inconnu. Ceci survient si un utilisateur Exchange spécifie une adresse de messagerie SharePoint inexacte en envoyant des messages, par exemple une bibliothèque de documents qui n'existe pas.

Vous pouvez corriger ce problème en configurant le Service de gestion d'annuaire dans les paramètres de message électronique Entrants dans Administration centrale de SharePoint pour créer des objets de destinataire pour les bibliothèques de documents activés par message dans Active Directory. Les utilisateurs Exchange peuvent alors facilement sélectionner ces objets de destinataire avec les informations d'adresse correctes dans le carnet d'adresses.

Sachez toutefois que vous ouvrez maintenant une toute nouvelle boîte de vers de dépannage. Le Service de gestion d'annuaire échoue dans une configuration de système sécurisé fondée sur le principe du moindre privilège parce que cette fonctionnalité a des exigences d'autorisation élevée sur le serveur Web. En outre, la documentation produit (comme technet.microsoft.com/library/cc262947.aspx) exagère un peu la situation lorsqu'elle suggère que vous accordiez au pool d'application Administration centrale le droit « Créer, supprimer et gérer les comptes utilisateur » dans l'UO que vous avez spécifiée pour les objets de destinataire SharePoint dans Active Directory.

Le Service de gestion d'annuaire crée les objets de contact et de groupe, et, ainsi, le compte de pool d'applications Administration centrale nécessite un contrôle total sur les objets de contact et de groupe de cette UO, mais il n'a pas besoin d'autorisations administratives pour les comptes utilisateur. Si vous configurez le Service de gestion d'annuaire dans une batterie de serveurs Web, comme présenté, et que vous essayez d'activer par message une bibliothèque de documents, il y a de très fortes chances pour que vous rencontriez une erreur « Accès refusé ».

L'information d'erreur indique des problèmes d'autorisation Active Directory, et que les administrateurs SharePoint sont prompts à attribuer le contrôle total à Tout le monde sur l'UO SharePoint. Cependant, non seulement ceci affaiblit la sécurité d'Active Directory, mais cela ne résout absolument pas le problème.

Le dépannage structuré nécessite que vous localisiez d'abord le point problématique et que vous appliquiez alors des modifications ciblées de la configuration. Si vous suivez cette approche et que vous vérifiez le journal des événements Windows sur le contrôleur de domaine, que peut-être vous suivez la communication réseau en utilisant le Moniteur réseau, vous pourrez découvrir que SharePoint n'accède pas à Active Directory lorsque ce problème survient. Il est donc peu probable que les modifications de configuration d'Active Directory répareront le problème. Le problème survient sur le serveur SharePoint.

Malheureusement il est incroyablement difficile d'obtenir des informations plus utiles sur ce problème d'autorisation. SharePoint n'enregistre pas d'informations supplémentaires dans le journal des événements Windows. Cependant, si vous activez le débogage de SharePoint, vous pouvez voir la pile d'appels (comme à la figure 6), ce qui suggère que le Service de gestion d'annuaire utilise la méthode CreateContact d'un service Web SharePoint. Le SDK SharePoint vous dira qu'il s'agit du service Web d'intégration de messagerie électronique (<WSS_server>:<admin_port>/_Vti_bin/SharepointEmailWS.asmx).

Figure 6 Sortie de débogage

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Observons SharepointEmailWS.asmx dans un navigateur Web pour voir la liste des opérations prises en charge. Vous pouvez voir la méthode CreateContact, et un clic sur le lien de CreateContact révèle les messages SOAP que vous devez envoyer à ce service Web si vous voulez créer un contact dans Active Directory. C'est génial, parce que maintenant vous pouvez créer un outil de dépannage basé sur script (voir SharepointEmailWS.Vb dans le matériel associé) pour travailler hors de l'interface utilisateur SharePoint, ce qui permet de facilement spécifier différents comptes utilisateur pendant les exécutions de test. La figure 7 montre les informations retournées si vous exécutez ce script sous le compte de pool d'applications Administration centrale (à gauche) et sous le compte Administrateur SharePoint (à droite).

fig07.gif

Figure 7 Deux erreurs « Accès refusé » différentes (cliquez sur l'image pour l'agrandir)

Les messages d'erreur diffèrent ! Les deux messages indiquent que l'accès est refusé, mais l'erreur sur la gauche indique un problème de traitement et l'erreur de droit non. Donc quelle est la différence entre les comptes de pool d'applications et le compte Administrateur de SharePoint ?

L'Administrateur SharePoint est un administrateur local sur le serveur SharePoint tandis que les comptes de pool d'applications ne le sont pas. L'ajout de comptes de pool d'applications de votre application de Web au groupe d'administrateurs locaux et le redémarrage du serveur Web résolvent le problème, mais ce n'est pas une excellente nouvelle. Je considère que l'exécution de comptes de pool d'applications avec des privilèges d'administrateur sur les serveurs Web de production est inacceptable.

Pourquoi un compte de pool d'applications a-t-il besoin de ces autorisations élevées ? Une fois encore, le script peut révéler la réponse. Si vous accordez à tous les utilisateurs les autorisations d'administrateur local sur votre serveur Web à des fins de test, vous découvrirez que les comptes de pool d'applications peuvent utiliser le service Web d'intégration de messagerie électronique alors que l'accès reste refusé pour tous les autres comptes, y compris les administrateurs SharePoint. Ceci signifie que le service Web d'intégration de messagerie électronique utilise la configuration de pool d'applications comme base pour les décisions de contrôle d'accès.

La configuration de pool d'applications fait partie de la métabase IIS (ou le fichier applicationHost.config dans IIS 7.0), et l'accès à la métabase est limité aux administrateurs locaux par défaut. Heureusement il est possible d'accorder à des comptes non-administrateurs l'accès à la métabase en utilisant l'explorateur de métabase incluse dans les outils du Kit de ressources IIS 6.0. Dans IIS 7.0, il est encore plus facile d'accorder le contrôle total au fichier applicationHost.config : exécutez simplement les commandes suivantes :

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

Pour résumer, pour créer des objets de contact dans Active Directory, le pool d'applications Administration centrale a besoin d'un contrôle total sur les objets de contact et de groupe dans l'UO cible. Et les comptes de pool des applications Web nécessitent l'accès total à la métabase sur les serveurs SharePoint dans la batterie de serveurs Web. Maintenant vous êtes prêt à créer des objets de contact en utilisant l'interface utilisateur de SharePoint.

Mais attendez, ce n'est pas tout ! La création d'objets de destinataire dans Active Directory n'est que la moitié de l'histoire de l'intégration d'annuaire. L'autre moitié est la production d'attributs de destinataire liés à Exchange et la mise à jour des carnets d'adresses basés sur serveur. Par exemple, si vous mettez à jour la liste d'adresses globale sur votre serveur Exchange en utilisant la commande Exchange Management Shell Update-GlobalAddressList « Liste d'adresses globale par défaut », vous pourrez détecter les objets de destinataire récemment créés pour les bibliothèques de documents SharePoint dans le carnet d'adresses Outlook. Mais l'envoi de messages à ces destinataires ont pour résultat des rapports de non-remise à cause des informations d'adresse inexactes, comme illustré dans la figure 8.

fig08.gif

Figure 8 Message de non-remise à une bibliothèque de documents (cliquez sur l'image pour l'agrandir)

L'acronyme IMCEAEX désigne l'adresse encapsulée de Internet Mail Connector pour Exchange (Internet Mail Connector Encapsulated Address for Exchange). Il indique une adresse de destinataire non-Exchange encapsulée dans un format que l'ancienne version d'Internet Mail Connector peut traiter. Mais nous parlons d'Exchange Server 2007 et de connecteurs d'envoi SMTP natifs de nos jours.

Le fait est que le service Web d'intégration de messagerie de SharePoint n'écrit pas les attributs d'adresse dont Exchange Server 2007 a besoin pour le transfert de messages. Il écrit seulement les attributs prénom, nom de famille, nom d'affichage et adresse cible (et, facultativement, msExch­RequireAuthToSendTo). Mais il ne définit pas le surnom de messagerie, ou les adresses DN Exchange héritées ou proxy, et il n'associe pas l'objet de destinataire à une stratégie de destinataire Exchange.

Pour résoudre ce problème, utilisez l'applet de commande Get-Mailbox dans le Shell de gestion Exchange pour obtenir tous les objets de destinataire avec une adresse cible pointant vers le domaine de messagerie électronique SharePoint. Et canalisez la sortie vers l'applet de commande Set-MailContact pour activer les stratégies de destinataire Exchange, comme suit :

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

Ou bien, utilisez comme alternative la console de gestion Exchange et sélectionnez la case « Mettre à jour auto. les adresses selon la stratégie d'adresse de messagerie » dans les propriétés de l'objet de contact.

WSS 3.0 et MOSS 2007 prennent directement en charge l'intégration de messagerie complète pour activer les alertes et les notifications, les flux de travail et les envois de document par message électronique. Bien qu'il ne soit pas facile de configurer les systèmes correctement, l'intégration de messages peut augmenter la productivité des employés. Vous devez vous assurer que les transferts de messages entrants et sortants fonctionnent correctement. Vous devez vous assurer également que l'intégration d'annuaire fonctionne.

Les messages d'erreur de SharePoint ne sont pas toujours intuitifs ou instructifs. Cependant, je vous ai montré des moyens d'aller au fond des problèmes d'intégration, localiser les causes initiales et les éliminer de manière fiable sans devoir mettre en péril la sécurité sur vos serveurs SharePoint.

Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. La reproduction partielle ou totale sans autorisation est interdite.