Présentation de l'interopérabilité entre Exchange Server 2003 et les systèmes de messagerie non-Exchange

Dernière rubrique modifiée : 2006-07-27

Microsoft fournit plusieurs composants pour l'intégration d'Exchange 2003 dans une infrastructure non-Exchange et pour la migration des utilisateurs vers Exchange 2003 :

• Connecteurs SMTP et X.400 Pour une interopérabilité parfaite, vous devez déployer un chemin de transfert des messages bidirectionnel fiable. Tous les systèmes de messagerie modernes prennent en charge SMTP. Par conséquent, un connecteur SMTP permet de connecter ces systèmes. Si le système de messagerie existant dépend de X.400, vous pouvez alors utiliser un connecteur X.400. Cette connectivité de messagerie peut être temporaire (par exemple, il peut s'avérer nécessaire que les systèmes ne coexistent que lors de la migration des utilisateurs du système existant vers Exchange Server 2003). Dans d'autres cas, une coexistence à long terme peut s'avérer nécessaire (par exemple, le système de messagerie d'un département qui ne passe pas à Exchange Server 2003 peut nécessiter une connexion permanente).
• Outils Active Directory et interfaces de programmation d'applications Vous devez synchroniser le service d'annuaire Active Directory® et le répertoire du système de messagerie existant pour établir une liste d'adresses globale cohérente sur les deux systèmes de messagerie. Toutefois, ni un connecteur SMTP ni un connecteur X.400 ne prend en charge la synchronisation d'annuaire automatique. Comme mentionné dans la rubrique sur la Présentation de l'interopérabilité et de la migration dans Exchange Server 2003, les outils Active Directory, tels que Ldifde.exe et Csvde.exe, permettent de réaliser une synchronisation d'annuaire manuelle ou des opérations d'exportation et d'importation en bloc. Avec les capacités de programmation de base de Microsoft Visual Basic® Scripting Edition (VBScript), il est également possible d'implémenter une solution de synchronisation d'annuaire plus sophistiquée, semi-automatique, basée sur les interfaces ADSI (Active Directory Service Interfaces) et les CDO (Collaboration Data Objects) pour la gestion d'Exchange (CDOEXM). Pour plus d'informations sur ADSI et CDOEXM, voir la page sur le Kit de développement (SDK) d'Exchange (https://go.microsoft.com/fwlink/?LinkId=25925).
• Interfaces de programmation d'Exchange Server pour un accès aux informations de disponibilité Un accès entre plusieurs plateformes aux informations de disponibilité est utile pour planifier des réunions et des conférences sur différents systèmes de messagerie. Toutefois, un connecteur du calendrier n'est pas disponible pour les systèmes de messagerie non-Exchange autres que Lotus Notes ou Novell GroupWise lorsqu'il est connecté à l'organisation Exchange 2003 via le Connecteur pour Lotus Notes ou le Connecteur pour Novell GroupWise. Bien qu'il soit impossible de synchroniser les informations de disponibilité entre les systèmes connectés entre eux via un connecteur SMTP ou un connecteur X.400, Outlook permet de publier les informations de disponibilité dans un emplacement partagé ou d'utiliser CDO pour Exchange (CDOEX) pour implémenter une solution client affichant le statut de disponibilité des utilisateurs Exchange 2003 dans une page ASP.NET. Pour plus d'informations sur CDOEX, voir la page sur le Kit de développement (SDK) d'Exchange (https://go.microsoft.com/fwlink/?LinkId=25925).
• Assistant Migration d'Exchange L'Assistant Migration d'Exchange est un outil permettant de migrer les utilisateurs d'un système de messagerie pris en charge, tel que Microsoft Mail pour PC Networks, Microsoft Mail pour AppleTalk Networks ou Lotus cc:Mail, vers Exchange 2003. L'Assistant Migration d'Exchange prend également en charge LDAP et IMAP4, ce qui est très utile si vous devez migrer de HP OpenMail, Sun ONE (anciennement désigné par le terme Netscape iPlanet), Openwave Email Mx, Alt-n MDaemon ou de tout autre système de messagerie prenant en charge LDAP et IMAP4. L'Assistant Migration d'Exchange prend en charge la migration en copiant les informations d'annuaire, les boîtes aux lettres et les messages existants, puis en les important dans Exchange Server 2003, comme expliqué dans la rubrique sur la Présentation de l'interopérabilité et de la migration dans Exchange Server 2003.
• Extracteurs source autonomes L'Assistant Migration d'Exchange ne prend pas en charge directement les systèmes de messagerie existants, tels que Dec All-in-One, Verimation MEMO ou les systèmes PROFS (Professional Office System) et OfficeVision/VM d'IBM. Toutefois, les extracteurs source autonomes, disponibles auprès des fournisseurs Microsoft et non-Microsoft, permettent d'extraire les données existantes des boîtes au lettres du système de messagerie existant vers des fichiers de migration que l'Assistant Migration d'Exchange peut importer dans Exchange Server 2003. Pour obtenir un extracteur source autonome, contactez les services du Support Technique de Microsoft. Pour plus d'informations sur les services du Support Technique, notamment la procédure pour les contacter, voir la page https://support.microsoft.com.

Transfert et conversion des messages

Exchange Server 2003 prend en charge deux normes de messagerie pour une connexion à tous les types de messagerie : SMTP et X.400. SMTP est le protocole de transfert des messages natif d'Exchange 2003 et il est par conséquent recommandé de choisir SMTP plutôt que X.400. De plus, un connecteur SMTP est plus simple à configurer qu'un connecteur X.400. Toutefois, X.400 est un bon choix si vous travaillez dans un environnement qui repose sur une structure fondamentale X.400 ou qui ne prendra pas en charge SMTP à moins que vous ne déployiez des composants supplémentaires dans l'infrastructure existante.

Transfert des messages basé sur SMTP

Exchange Server 2003 repose sur le service SMTP de Windows 2003, étendu avec des composants de transport et des modules spécifiques à Exchange, pour une communication avec les hôtes SMTP distants. Le service SMTP est représenté dans Exchange 2003 par des serveurs virtuels. Pour que le transfert des messages fonctionne, les serveurs virtuels SMTP doivent être capables de résoudre les noms de domaine SMTP dans les adresses IP. Ceci s'effectue généralement via des requêtes DNS (Domain Name System). Les hôtes SMTP doivent être inscrits dans des enregistrements de serveur de messagerie (MX). Il est également possible de transmettre les messages SMTP sortants à un seul hôte SMTP pour une remise supplémentaire. Cet hôte SMTP est appelé un hôte actif. Les fournisseurs de services Internet (FAI) fournissent souvent à leurs clients un hôte actif central qui gère le transfert de messages sur Internet.

Le transfert des messages SMTP vers les hôtes SMTP internes est réalisé au mieux via les connecteurs SMTP dédiés. En effet, les connecteurs SMTP fournissent un meilleur contrôle de la configuration effectuée par les serveurs virtuels SMTP. Les paramètres du connecteur ont une priorité supérieure pour le transfert des messages que les paramètres des serveurs virtuels. Par exemple, un connecteur SMTP permet d'implémenter un serveur Bridgehead de messagerie central, responsable de tous les transferts des messages entre le système de messagerie existant et l'organisation Exchange 2003. La figure 1 illustre un environnement avec un seul serveur Bridgehead. Pour une tolérance de pannes et un équilibrage de charge, vous pouvez définir plusieurs serveurs Bridgehead dans la configuration du connecteur SMTP.

Lorsque vous configurez un connecteur SMTP, vous pouvez spécifier s'il convient d'utiliser des enregistrements DNS et MX pour le transfert des messages ou de transmettre tous les messages à un hôte actif. Utiliser un hôte actif est généralement la meilleure option lors du transfert des messages à un autre hôte SMTP du réseau interne car les destinations internes ne sont la plupart du temps pas inscrites comme enregistrements MX dans le système DNS. Pour transmettre des messages pour un domaine SMTP particulier sur un connecteur SMTP, vous devez identifier le connecteur responsable du domaine. Ceci doit être fait en définissant un espace d'adressage de type SMTP dans la configuration du connecteur correspondant au nom de domaine SMTP du système cible. Dans la figure 1, l'espace d'adressage est : SMTP : legacy.contoso.com. Le système cible étant identifié au moyen d'un nom de domaine SMTP, le système de messagerie existant et l'organisation Exchange 2003 ne peuvent partager le même nom de domaine SMTP. Pour plus d'informations sur la procédure de traitement des noms de domaine SMTP dans les scénarios de migration, voir la rubrique sur la Présentation de l'interopérabilité et de la migration dans Exchange Server 2003.

Remarque :
Si une adresse de destinataire ne correspond à aucun espace d'adressage de connecteur, les paramètres du serveur virtuel SMTP local sont utilisés pour la remise de messages. Par défaut, Exchange 2003 tente de localiser l'hôte SMTP distant en utilisant le système DNS jusqu'à ce que vous modifiez les options de remise du serveur SMTP virtuel.

Transfert des messages d'Exchange vers SMTP

La figure 2 illustre le processus d'envoi de messages d'Exchange 2003 vers un système de messagerie non-Exchange via un connecteur SMTP.

Le transfert des messages d'Exchange 2003 vers un système de messagerie non-Exchange via SMTP se déroule comme suit :

1. Tous les messages envoyés vers les utilisateurs locaux ou distants doivent passer par le moteur de transport d'Exchange 2003. La file d'attente de pré-traitement est le point d'entrée dans le moteur de files d'attente avancé.

2. Le moteur de files d'attente avancé transfère le message de la file d'attente de pré-traitement vers la file d'attente préalable à la catégorisation, pour que le catégoriseur puisse le traiter. Le catégoriseur vérifie les restrictions, applique des limites par expéditeur et destinataire et résout les informations sur le destinataire d'Active Directory, pour déterminer si le message se dirige vers un destinataire local ou distant. Le catégoriseur place alors le message dans une file d'attente après la catégorisation, de manière à le renvoyer vers le moteur de files d'attente avancé.

   Remarque :
   Le catégoriseur développe les listes de distribution, résout les noms d'expéditeur et de destinataire, détermine les serveurs associés et le format de conversion des messages et bifurque les messages. La bifurcation est le processus de création de plusieurs copies d'un message, exigé, par exemple, lorsque les destinataires imposent différents formats de message.

3. Le moteur de files d'attente avancé transfère les messages adressés à des destinataires non locaux de la file d'attente après la catégorisation vers la file d'attente de pré-routage et appelle le moteur de routage. Le moteur de routage gère les informations sur le saut suivant dans la table d'état des liens. Sur la base de l'adresse cible de l'utilisateur, le moteur de routage identifie le destinataire comme l'utilisateur d'un système de messagerie non-Exchange et déplace le message vers la file d'attente de liens pour le connecteur SMTP. Le composant du gestionnaire de files d'attente gère les files d'attente de liens. Le nom de la file d'attente correspond à la destination de remise distante.

4. Le service de protocole SMTP récupère le message, détermine l'hôte de destination à partir de la configuration du connecteur SMTP ou via une requête DNS basée sur le domaine SMTP du destinataire, établit une connexion TCP/IP à l'hôte de destination sur le port TCP 25 et transfère le message.

5. L'hôte de destination remet le message à sa destination finale.

Transfert des messages de SMTP vers Exchange

Un connecteur SMTP est utilisé pour le transfert des messages sortants d'Exchange 2003. Les connecteurs SMTP sont des objets de configuration contenant des paramètres qui déterminent l'établissement des connexions et le transfert des messages du service SMTP. Toutefois, les systèmes de messagerie non-Exchange ne reconnaissent pas ces objets et paramètres. Les hôtes SMTP distants établissent une connexion TCP/IP au service SMTP sur le serveur Exchange 2003 via le port TCP 25 et transfèrent leurs messages.

La figure 3 illustre le processus de réception des messages en provenance d'un hôte SMTP distant.

Le transfert des messages d'un hôte SMTP distant vers Exchange 2003 peut être divisé en quatre étapes :

1. L'hôte SMTP distant établit une connexion TCP/IP au serveur Exchange 2003 sur le port TCP 25 et transfère le message. Le service de protocole SMTP local place le message dans la file d'attente de pré-traitement du moteur de files d'attente avancé.
2. Le moteur de files d'attente avancé transfère le message de la file d'attente de pré-traitement vers la file d'attente préalable à la catégorisation, pour que le catégoriseur puisse le traiter. Le catégoriseur vérifie les restrictions, applique des limites par expéditeur et destinataire et résout les informations sur le destinataire d'Active Directory, pour déterminer si le message se dirige vers un destinataire local ou distant. Le catégoriseur place alors le message dans une file d'attente après la catégorisation, de manière à le renvoyer vers le moteur de files d'attente avancé.
3. Le moteur de files d'attente avancé transfert les messages adressés à des destinataires locaux de la file d'attente après la catégorisation à la file d'attente de remise locale.
4. Le pilote de banque d'informations Exchange récupère le message et le place dans la Boîte de réception du destinataire local.

Conversion des messages Exchange/SMTP

Comme son nom l'indique, SMTP (Simple Mail Transfer Protocol) ne définit pas les types de message complexes, tels que les demandes de confirmation de remise, les demandes de confirmation de lecture, les demandes de réunion ou les demandes de tâche. En fait, SMTP ne gère qu'un type de message : un message à texte simple. Un message SMTP consiste en une séquence de caractères ASCII de sept bits. L'en-tête du message, qui contient, entre autres, des informations sur l'expéditeur et le destinataire, l'objet et la date, est séparé du corps par une ligne nulle, qui est une ligne vide précédant le caractère retour chariot/saut de ligne. Comme présenté à la figure 4, le format des messages SMTP, défini en RFC 822, est en effet simple.

Le format des messages SMTP de base ne peut être utilisé que pour des messages électroniques à base de texte. Pour prendre en charge les pièces jointes, les fichiers originaux doivent être codés à l'aide d'UUENCODE ou de MIME (Multipurpose Internet Mail Extensions). Choisissez de coder les pièces jointes du message à l'aide d'UUENCODE ou de MIME selon les fonctions prises en charge par le client de messagerie de réception.

UUENCODE est un mécanisme de codage convertissant les données binaires en caractères ASCII imprimables, pour que les données puissent être incluses dans le corps du message sans violer les conventions SMTP. Le message présenté à la figure 4 contient le flux de caractères à sept bits d'un fichier attaché au format Uuencode.

MIME fournit un autre moyen de coder en texte des informations non textuelles. MIME, défini en RFC 1341 et plus, est un format très flexible. Il décrit une manière d'inclure plusieurs parties de divers types de contenu dans un message électronique texte ou non. Le message peut contenir du texte, des images, du son, de la vidéo ou d'autres données spécifiques à des applications.

Remarque :
MIME utilise l'algorithme de codage/décodage Base64, qui est flexible et fiable mais augmente le volume des données codées de 33 % en moyenne. Ceci signifie qu'un connecteur SMTP doit transférer 33 % de données en plus par message.

Lorsque vous connectez une organisation Exchange 2003 à un système de messagerie non-Exchange via un connecteur SMTP, le contenu du message doit être encapsulé à l'aide d'UUENCODE ou de MIME pour éviter la perte du format RTF (Rich Text Format) et des caractères étendus. Le message encapsulé peut être inséré dans un message sous forme de caractères imprimables.

Par défaut, les messages sont encapsulés à l'aide de MIME. Toutefois, vous pouvez spécifier le format du message pour chaque domaine SMTP dans l'outil Gestionnaire système Exchange. Sous Paramètres globaux, affichez les propriétés de l'objet Format des Messages Internet et passez à l'onglet Format des messages. Parmi d'autres, vous pouvez choisir de fournir le corps du message au format HTML. Ceci est un bon choix si le client de messagerie électronique du destinataire prend en charge les messages au format HTML. Les messages au format HTML conservent la majorité des fonctions du format RTF qui seraient perdues si vous choisissiez un corps du message en texte brut.

Remarque :

Certains administrateurs de messagerie bloquent les messages au format HTML car ils peuvent inclure des scripts contenant des codes malveillants, tels que des vers. Demandez à l'administrateur distant s'il vous est possible de transférer des messages au format HTML. L'alternative au format HTML est le texte brut ou le format TNEF (Transport Neutral Encapsulation Format). Ces deux possibilités sont détaillées ultérieurement dans cette section.

Le tableau 1 indique quelles fonctions au format RTF Exchange sont converties correctement lors du passage format HTML, et lesquelles ne le sont pas.

Tableau 1 Conversion des messages électroniques du format RTF au format HTML

Pour éviter de perdre la mise en forme des informations lors de la conversion du format RTF au format HTML, les utilisateurs d'Outlook peuvent configurer leurs clients de manière à composer par défaut des messages au format HTML. D'autre part, si les utilisateurs utilisent Microsoft Word comme éditeur de messagerie électronique, ils peuvent utiliser la totalité du module d'édition HTML disponible sous Word lors de la composition de messages électroniques. Par exemple, ils composent un message au format HTML et insèrent un tableau dans le message. Le tableau est alors conservé lors de la transmission du message car il s'agit d'une structure HTML native. En revanche, un tableau inséré dans un texte au format RTF sera perdu lors de la conversion du format RTF au format HTML. L'enjeu n'est pas de savoir si un message au format HTML peut supporter un tableau (ou autre fonction RTF spécifique), mais si la conversion du format RTF au format HTML prend en charge cet élément au format RTF.

Une autre option est d'envoyer une information au format RTF au destinataire distant, encapsulée au format TNEF. C'est un choix judicieux si vous savez que le destinataire travaille avec un client prenant en charge l'interface MAPI, telle qu'Outlook avec le moteur de transport IMAP4. L'envoi de messages au format RTF permet d'assurer une interopérabilité maximale entre les utilisateurs d'Outlook sur différents systèmes de messagerie car toutes les propriétés du messages sont préservées. Par exemple, les informations de calendrier nécessitent un format RTF. Les utilisateurs peuvent s'envoyer des types de message particuliers, tels que des demandes de réunion ou des demandes de tâche, au format RTF. Les utilisateurs peuvent décider individuellement d'envoyer des messages au format RTF , mais vous pouvez également activer cette fonction dans le Gestionnaire système Exchange pour chaque domaine SMTP. Dans les propriétés de l'objet Format de Message Internet, passez à l'onglet Avancé, puis, sous Format RTF Exchange, sélectionnez l'option Toujours.

Remarque :

Lorsque vous envoyez un message encapsulé au format TNEF, tous les attributs MAPI sont conservés mais le destinataire doit travailler avec un client de messagerie compatible MAPI. Les clients qui ne comprennent pas MAPI affichent un message en texte brut ou au format HTML, avec une pièce jointe supplémentaire nommée winmail.dat, que le destinataire ne peut utiliser. Ceci peut dérouter le destinataire. Par conséquent, vous ne devez pas envoyer des informations en texte brut aux domaines SMTP, à moins d'être sûr que les destinataires travaillent avec un client conforme MAPI.

Transfert des messages basé sur X.400

Avant que SMTP ne soit établi comme l'une des normes majeures en termes de transfert des messages, des fournisseurs commerciaux de services de messagerie électronique et de grandes entreprises ont déployé des structures fondamentales X.400 pour se connecter aux différents systèmes de messagerie. Aujourd'hui, SMTP est plus populaire que X.400 car il est simple et établi sur Internet. Toutefois, X.400 reste une norme de messagerie répandue dans les cabinets d'avocat, les services juridiques, les institutions financières, les compagnies d'assurance et autres organisations pour lesquelles le transfert des messages doit être sécurisé et traçable. Dans une structure fondamentale basée sur SMTP, il est difficile de trouver les messages déroutés ou de déterminer l'origine d'un message électronique avec texte offensif. Toutefois, dans une structure basée sur X.400, toutes les connexions nécessitent une authentification. Tous les Agents de transfert des messages (MTA) doivent s'identifier comme MTA autorisés avant de pouvoir transférer des messages. Internet étant désormais inondé de courriers indésirables et de virus de courrier électronique, X.400 gagne en popularité.

Exchange Server 2003 prend en charge X.400 via le service Piles MTA de Microsoft Exchange. MTA Exchange prend en charge X.400 selon l'année de conformité 1984 et peut communiquer avec les systèmes X.400 distants de 1984 et 1988 via TCP/IP ou X.25. Les systèmes X.400 des années de conformité ultérieures (p. ex. 1992) doivent réduire leurs modules de fonction à la norme de 1988 lors d'une communication avec Exchange 2003. La norme X.400 demande que les systèmes X.400 s'adaptent aux capacités, inférieures, de leur partenaires de communication.

Remarque :
Le connecteur X.400 est disponible uniquement dans Exchange Server 2003 Enterprise Edition.

Transfert des messages d'Exchange vers X.400

La figure 5 illustre le processus d'envoi de messages d'Exchange 2003 vers un système X.400 distant.

Le transfert des messages d'Exchange 2003 vers un système de messagerie non-Exchange via X.400 se déroule comme suit :

1. L'utilisateur envoie un nouveau message, que le pilote de banque d'informations Exchange place dans la file d'attente de pré-traitement pour le transmettre au moteur de transport d'Exchange 2003. Dans Exchange 2003, tous les messages adressés à des destinataires locaux ou distants doivent passer par le moteur de transport.
2. Le moteur de files d'attente avancé transfère le message de la file d'attente de pré-traitement vers la file d'attente préalable à la catégorisation, pour que le catégoriseur puisse le traiter. Le catégoriseur vérifie les restrictions, applique des limites par expéditeur et destinataire et résout les informations sur le destinataire d'Active Directory, pour déterminer si le message se dirige vers un destinataire local ou distant. Le catégoriseur place alors le message dans une file d'attente après la catégorisation, de manière à le renvoyer vers le moteur de files d'attente avancé.
3. Le moteur de files d'attente avancé transfère les messages adressés à des destinataires non locaux de la file d'attente après la catégorisation vers la file d'attente de pré-routage et appelle le moteur de routage. Le moteur de routage identifie le destinataire comme l'utilisateur d'un système de messagerie X.400 (sur la base de l'adresse cible de l'utilisateur et de l'espace d'adressage associé au connecteur X.400) et déplace le message vers la file d'attente de liens pour MTA Exchange. Le composant du gestionnaire de files d'attente gère les files d'attente de liens.
4. Le pilote de banque d'informations Exchange informe MTA Exchange qu'un nouveau message attend d'être transféré. MTA obtient le message de la liste d'attente de liens, convertit les informations sur le destinataire et le corps du message du format MDBEF (Message Database Encoding Format) au format X.400 approprié, selon l'année de conformité et le jeu de caractères du MTA distant, comme spécifié dans les propriétés du connecteur X.400, et place le message dans une file d'attente interne MTA du système de fichiers.
5. MTA Exchange établit une connexion au MTA distant, s'identifie et, lorsque la connexion est acceptée, transfère le message. Le MTA distant remet alors le message au destinataire final.

Transfert des messages de X.400 vers Exchange

La figure 6 illustre le processus de réception des messages en provenance d'un MTA X.400 distant.

Le transfert des messages d'un MTA X.400 vers Exchange 2003 peut être divisé en plusieurs étapes :

1. Le MTA X.400 distant établit une connexion au MTA Exchange local, s'identifie comme un MTA autorisé et, une fois que le MTA Exchange a accepté la connexion et que l'association a été établie avec succès, transfère le message. Le MTA Exchange stocke le message entrant dans la base de données de messages de son système de fichiers.
2. Le MTA Exchange convertit les informations sur le destinataire et le corps du message au format Exchange et place le message dans la banque de boîte aux lettres SMTP pour le passer au moteur de transport SMTP pour remise. Dans Exchange 2003, tous les messages doivent passer par le moteur de transport SMTP.
3. Le pilote de banque d'informations Exchange place le message dans la file d'attente de pré-traitement du moteur de files d'attente avancé.
4. Le moteur de files d'attente avancé transfère le message de la file d'attente de pré-traitement vers la file d'attente préalable à la catégorisation, pour que le catégoriseur puisse le traiter. Le catégoriseur vérifie les restrictions, applique des limites par expéditeur et destinataire et résout les informations sur le destinataire d'Active Directory, pour déterminer si le message se dirige vers un destinataire local ou distant. Le catégoriseur place alors le message dans une file d'attente après la catégorisation, de manière à le renvoyer vers le moteur de files d'attente avancé.
5. Le moteur de files d'attente avancé transfert les messages adressés à des destinataires locaux de la file d'attente après la catégorisation à la file d'attente de remise locale.
6. Le pilote de banque d'informations Exchange récupère le message et le place dans la Boîte de réception du destinataire local.

Conversion des messages Exchange/X.400

Les connecteurs X.400 prennent en charge divers types de contenus et de jeux de caractères. Les types de contenu X.400 incluent P2 (année de conformité 1984), P22 (année de conformité 1988) et le composant de corps de message 14 ou 15 pour les données binaires. Lorsque le MTA Exchange communique avec un MTA X.400-84, le corps du message est envoyé à l'aide du type de contenu P2 et les pièces jointes à l'aide du composant de corps de message 14. Lors d'une communication selon l'année de conformité 1988, le texte est envoyé à l'aide du contenu P22 et vous pouvez configurer le serveur de manière à envoyer des pièces jointes à l'aide du composant de corps de message 14 ou 15, au format FTBP (File Transfert Body Part).

Le MTA Exchange prend en charge les composants du corps du message X.400 suivants pour le texte du message :

• Alphabet international 5 (IA5) Un jeu de caractères identique à l'US-ASCII qui inclut les caractères d'Europe de l'Ouest.
• Organisation Internationale de Normalisation (ISO) 6937 Un jeu de caractères qui inclut 333 caractères du script latin, auquel il faut ajouter des marques d'absence de poids diacritique. Pour prendre en charge d'autres langues, la commutation du jeu de caractères doit être définie dans ISO 2022. ISO 6937 est un sur-ensemble de la définition du jeu de caractères Télétexte.
• ISO 8859 Une famille de jeux de caractères au codage simple de huit bits. La plupart des langues basées sur des caractères codés sur un octet peuvent être prises en charge dans l'un des alphabets ISO 8859.
• Télétexte 61 (T.61) Un sous-ensemble d'ASCII, auquel il faut ajouter des caractères internationaux codés à huit bits.

Les jeux de caractères des types de contenu P2 ou P22 ne peuvent représenter ni des informations au format RTF ni des objets OLE. La prise en charge du format RTF est disponible uniquement si le destinataire peut comprendre les formats de message MAPI. Plusieurs systèmes de messagerie basés sur X.400, tels que HP OpenMail, prennent en charge Outlook et par conséquent MAPI.

Le MTA Exchange peut encapsuler la totalité du message au format TNEF et y ajouter une pièce jointe. Le principe est le même que celui indiqué précédemment pour le connecteur SMTP. Si le système récepteur peut traiter une pièce jointe au format TNEF (par exemple si le destinataire utilise Microsoft Outlook), le message s'affiche avec toutes les informations au format RTF. Toutefois, si le système récepteur ne peut pas traiter le format TNEF, il peut s'avérer que le texte du message et ses pièces jointes ne sont pas lisibles. Vous devez vous assurer que la configuration du connecteur X.400 correspond aux capacités du système de messagerie non-Exchange.

Synchronisation d'annuaire

La synchronisation d'annuaire est le processus de propagation des informations d'annuaire sur les utilisateurs Exchange 2003 d'Active Directory vers l'annuaire d'un système de messagerie non-Exchange, simultanément avec la propagation d'informations sur les utilisateurs du système de messagerie non-Exchange vers Active Directory, dans Exchange 2003. Lorsque la synchronisation d'annuaire est terminée, chaque système dispose d'une copie complète des données d'annuaire (utilisateurs, groupes, etc.) pour l'organisation de la messagerie associée.

La synchronisation d'annuaire implique deux processus séquentiels :

• La synchronisation des destinataires à partir d'Active Directory vers un système de messagerie non-Exchange.
• La synchronisation des destinataires à partir d'un système de messagerie non-Exchange vers Active Directory.

Malheureusement, vous ne pouvez pas utiliser de connecteur SMTP ou X.400 pour activer une synchronisation d'annuaire planifiée, automatique, entre Exchange 2003 et un système de messagerie non-Exchange. Vous devez par conséquent implémenter une solution manuelle ou semi-automatique. Lorsque vous implémentez une solution client pour une synchronisation d'annuaire, n'oubliez pas d'implémenter un processus bidirectionnel car les attributs du destinataire doivent être mis à jour dans les deux annuaires. Pour plus d'informations sur la procédure de travail par programme avec des informations d'annuaire dans un système de messagerie non-Exchange, contactez le fournisseur du système de messagerie. Cette section traite de l'utilisation d'Active Directory et des outils Active Directory standard.

Synchronisation des entrées d'annuaire d'un système de messagerie non-Exchange vers Active Directory

La synchronisation d'annuaire d'un système de messagerie non-Exchange vers Active Directory inclut les processus suivants :

1. Récupération des informations d'annuaire à partir du système de messagerie non-Exchange Divers outils permettent d'obtenir les informations d'annuaire source, dont les interfaces API or le protocole LDAP. Si le système de messagerie non-Exchange prend en charge le protocole LDAP, l'Assistant Migration d'Exchange permet d'extraire les informations d'annuaire à partir de ce système de messagerie non-Exchange. Pour les annuaires LDAP, assurez-vous d'avoir activé l'option Migrer à partir de l'annuaire Internet (LDAP via ADSI), puis, sur la page suivante, activez l'option Extraire les fichiers de migration uniquement. L'Assistant Migration d'Exchange place les informations d'annuaire extraites dans un fichier de migration principal nommé directory.pri, fichier texte .csv (valeurs délimitées par des virgules) utilisable comme base pour un traitement approfondi, p. ex. pour une importation d'annuaire. Pour plus d'informations sur les fichiers de migration et l'Assistant Migration d'Exchange, voir la rubrique sur la Présentation de l'interopérabilité et de la migration dans Exchange Server 2003.

   Remarque :

   Les annuaires conformes LDAP fournissant généralement des informations d'adresses SMTP, vous devez utiliser un connecteur SMTP si vous disposez d'annuaires conformes LDAP pour vous connecter aux systèmes de messagerie. Si vous préférez un connecteur X.400, assurez-vous d'obtenir les informations d'adresse au format X.400. La plupart des systèmes de messagerie proposent des fonctions d'exportation de l'annuaire propriétaire que vous pouvez utiliser. Contactez l'administrateur responsable du système de messagerie existant, pour qu'il vous fournisse les informations d'annuaire exportées au format correspondant au connecteur que vous déployez entre Exchange 2003 et le système de messagerie non-Exchange.

2. Préparation des informations d'annuaire en vue d'une importation dans Active Directory L'outil que vous utilisez pour importer les informations d'annuaire dans Active Directory détermine la procédure de structuration des données pour une importation effective. Par exemple, si vous utilisez Ldifde.exe, vous devez fournir les données sources au format LDIF (Lightweight Data Interchange Format). Le format LDIF est défini dans RFC 2849. Toutefois, si vous connaissez la programmation à l'aide d'ADSI ou de CDOEXM, vous pouvez développer une solution client pour importer les données. Le format des données sources dépend des routines d'analyse que vous implémentez dans votre solution client. Idéalement, un outil permet d'analyser le fichier d'entrée sans conversion de format. Par exemple, vous souhaiterez peut-être analyser directement la structure basée sur un fichier texte .csv d'un fichier directory.pri sans modifier le format auquel il a été exporté depuis un annuaire LDAP, pour importer des informations sur le destinataire dans Active Directory. Pour plus d'informations sur la programmation à l'aide d'ADSI ou de CDOEXM, voir la page sur le Kit de développement (SDK) d'Exchange (https://go.microsoft.com/fwlink/?LinkId=25925).

3. Importation des informations d'annuaire dans Active Directory L'Assistant Migration d'Exchange ne permet pas de réaliser la synchronisation d'annuaire réelle car il est conçu pour créer des boîtes aux lettres dans Exchange 2003. La synchronisation d'annuaire est basée sur l'hypothèse que les destinataires restent dans le système existant. Pour réaliser une synchronisation d'annuaire correctement, votre solution doit créer des comptes d'utilisateur ou des contacts à extension messagerie au lieu de comptes d'utilisateur avec boîte aux lettres. Il est recommandé de créer une unité organisationnelle désignée pour tous les utilisateurs non-Exchange dans Active Directory, à utiliser lors des processus de migration.
   Pour les utilisateurs non-Exchange, vous pouvez créer les types de compte d'utilisateur suivants dans Active Directory :

   • Comptes d'utilisateur Windows désactivés Créez des comptes d'utilisateur Windows désactivés si vos utilisateurs non-Exchange ne sont pas encore dans votre environnement Active Directory, mais le seront après la migration vers Exchange 2003.
   • Nouveaux comptes d'utilisateur Windows Créez des comptes Windows activés pour les utilisateurs non-Exchange travaillant dans votre environnement Active Directory avant la migration.
   • Contacts Windows Créez des contacts Windows pour les utilisateurs non-Exchange qui ne sont pas dans votre environnement Active Directory. L'Assistant Migration d'Exchange peut convertir ces objets contact en comptes d'utilisateur lors du processus de migration.
     Une information intéressante est mise en avant en ce qui concerne les listes de distribution du système de messagerie existant. Vous pouvez synchroniser les listes de distribution comme des objets contact, ce qui a l'avantage de vous éviter de gérer les informations sur les membres du groupe dans Active Directory. Toutefois, si vous synchronisez les listes de distribution comme des objets contact, les messages envoyés à une liste de distribution doivent tout d'abord être transférés au système de messagerie existant pour une extension de la liste de distribution avant la remise des messages aux destinataires individuels. Si la liste de distribution contient des destinataires faisant référence aux utilisateurs de l'organisation Exchange 2003, les messages doivent être retournés à l'organisation Exchange 2003 après l'extension de la liste de distribution. Pour éviter ce transfert des messages inutile, vous pouvez créer des groupes à extension messagerie dans Active Directory et en spécifier directement les membres individuels. Si vous faites cela, Exchange 2003 peut étendre la liste de distribution immédiatement et sans transfert des messages supplémentaire vers le système de messagerie existant.
     Les groupes d'Active Directory peuvent contenir n'importe quel type d'objet destinataire (par exemple les comptes d'utilisateur, les contacts ou autres groupes). Après avoir créé dans Active Directory des comptes d'utilisateur ou contacts à extension messagerie correspondants aux destinataires du système existant, vous pouvez reprendre point par point les listes de distribution du système existant et y ajouter les objets destinataires nécessaires comme membres. Lorsque vous effectuez la migration des utilisateurs à l'aide de l'Assistant Migration d'Exchange, ce dernier trouvera les objets à extension messagerie existants en mettant en correspondance l'adresse de messagerie du compte à migrer et l'adresse de messagerie de l'objet cible d'Active Directory. Lors du processus de migration, l'Assistant Migration d'Exchange convertit ces objets destinataires en comptes d'utilisateur avec boîte aux lettres et conserve les informations sur les membres du groupe de distribution. Toutefois, si vous n'utilisez pas l'Assistant Migration d'Exchange, vous devez prendre des mesures supplémentaires pour ajouter les comptes d'utilisateur avec boîte aux lettres à tous leurs groupes de distribution après la migration. Il est possible de programmer ces mesures.

   Remarque :
   L'Assistant Migration d'Exchange n'exporte pas d'information d'annuaire concernant les listes de distribution du système de messagerie existant. Vous devez utiliser une méthode d'exportation d'annuaire différente ou créer les listes de distribution manuellement dans Active Directory.

4. Mise à jour des informations d'annuaire dans Active Directory Après l'importation des informations d'annuaire dans Active Directory, vous devez vous assurer qu'elles sont mises à jour dans les deux annuaires. Par exemple, si vous modifiez ou supprimez un utilisateur dans le système existant, l'objet destinataire correspondant doit alors être mis à jour ou supprimé dans Active Directory. La modification ou la suppression d'un objet destinataire existant nécessite de trouver l'objet existant dans Active Directory, puis d'effectuer la mise à jour.
   Pour trouver des objets destinataires dans Active Directory :

   • Objets destinataires modifiés dans le système de messagerie non-Exchange L'adresse de messagerie de l'objet destinataire permet de localiser son équivalent dans Active Directory car l'adresse de messagerie principale de l'objet Active Directory est l'adresse SMTP ou X.400 du destinataire dans le système de messagerie existant. Toutefois, il peut s'avérer dans certaines situations que les adresses de messagerie ne correspondent pas. Un utilisateur peut, dans Active Directory, avoir un compte d'utilisateur qui n'est pas encore à extension messagerie ou son adresse électronique peut avoir été modifiée (par exemple, un utilisateur reçoit une nouvelle adresse SMTP dans le système de messagerie existant). Dans de telles situations, les adresses de messagerie correspondantes ne fonctionnent pas et vous devez utiliser des attributs supplémentaires pour trouver l'objet destinataire correspondant. Dans le système existant, le nom affiché ou alias de l'utilisateur (ou tout autre attribut) vous permet d'établir une association fiable entre les objets destinataires source et cible.
   • Objets destinataires supprimés dans le système de messagerie non-Exchange Rechercher un objet cible dans Active Directory lorsque l'objet source a été supprimé du système de messagerie non-Exchange existant est un processus compliqué. L'objet source supprimé n'existant plus, il ne peut pas être utilisé comme référence pour localiser l'objet destinataire correspondant dans Active Directory. Dans cette situation, vous pouvez supprimer manuellement d'Active Directory l'objet destinataire correspondant ou comparer la liste d'adresses complète du système de messagerie non-Exchange avec la liste complète des objets destinataires correspondants dans Active Directory, pour déterminer quels objets existent uniquement dans Active Directory. Les comptes Active Directory à extension messagerie sans équivalent dans le système de messagerie source indiquent que les objets sources ont été supprimés.
     Pour comparer les listes d'adresses, vous devez associer les objets destinataires créés dans Active Directory à leurs équivalents dans le système de messagerie non-Exchange. Vous pouvez utiliser le nom de domaine SMTP du système de messagerie existant pour établir cette association. Une autre possibilité est d'utiliser une unité d'organisation exclusivement pour les objets destinataires appartenant à un système de messagerie existant spécifique. Vous pouvez alors comparer les objets de cette unité d'organisation à la liste de destinataires du système existant. Une troisième possibilité, et peut-être la plus fiable pour comparer les listes d'adresses, est d'écrire des informations spécifiques sur le système de messagerie où résident les destinataires dans un attribut des objets destinataires dans Active Directory. Vous pouvez alors utiliser cet attribut comme base d'une requête LDAP. Un attribut d'extension ou l'attribut nommé importedFrom permet d'enregistrer vos informations de synchronisation spécifiques.

La figure 7 illustre le processus général de transfert d'informations d'annuaire du système de messagerie non-Exchange vers Active Directory basé sur LDAP, l'Assistant Migration d'Exchange et un script personnalisé traitant le fichier directory.pri. Si vous préférez une solution sans script personnalisé, vous pouvez remplacer ce dernier par Ldifde.exe. Mais n'oubliez pas que vous devez alors convertir le format du fichier directory.pri au format LDF pour prendre en charge Ldifde.exe.

Synchronisation des entrées d'annuaire d'Active Directory vers un système de messagerie non-Exchange

La synchronisation d'annuaire d'Active Directory vers un système de messagerie non-Exchange est basée sur les mêmes principes que la synchronisation d'annuaire d'un système de messagerie non-Exchange vers Active Directory. Vous devez extraire les informations sur les comptes d'utilisateur avec boîte aux lettres d'Active Directory, traiter les informations, puis importer, mettre à jour ou supprimer les informations dans l'annuaire existant. Les outils tels que Ldifde.exe, Csvde.exe ou ADSI permettent d'extraire des données Actives Directory. Vous pouvez également utiliser l'Assistant Migration d'Exchange car Active Directory est un annuaire conforme LDAP pris en charge. L'avantage d'utiliser l'Assistant Migration d'Exchange pour extraire des données Active Directory est que les informations d'annuaire extraites sont placées dans un fichier directory.pri exactement de la même manière que les informations d'annuaire d'un autre annuaire LDAP. Par conséquent, vous pouvez réutiliser les routines d'analyse de fichier utilisées pour la synchronisation d'annuaire d'un système non-Exchange vers Active Directory. Seuls les interfaces API ou les outils d'importation des informations d'annuaire dans l'annuaire existant diffèrent. Pour plus de détails sur la procédure d'importation des informations d'annuaire dans le système de messagerie existant, contactez le fournisseur du système de messagerie.

Remarque :

Pour que fonctionne la synchronisation d'annuaire Active Directory vers un système non-Exchange, le système de messagerie non-Exchange doit contenir les informations d'annuaire pour les utilisateurs qui se trouvent en dehors du système de messagerie. La plupart des systèmes permettent d'associer des objets destinataires SMTP ou X.400 à des connecteurs ou domaines distants dans leur annuaire. Lors de la connexion des systèmes de messagerie via SMTP, vous devez synchroniser les utilisateurs Exchange comme destinataires Internet. Lors de la connexion des systèmes de messagerie à l'aide d'un connecteur X.400, vous devez synchroniser les utilisateurs Exchange comme destinataires X.400. Tous les utilisateurs Exchange ont au moins une adresse SMTP et une adresse X.400.

La figure 8 illustre le processus général de transfert d'informations d'annuaire d'Active Directory vers un système de messagerie non-Exchange à l'aide de l'Assistant Migration d'Exchange et d'un script personnalisé utilisant des interfaces API ou des outils d'importation non-Microsoft pour placer les objets destinataires dans l'annuaire existant.

L'un des inconvénients de l'Assistant Migration d'Exchange lors de l'extraction des informations d'annuaire d'Active Directory est que vous ne pouvez pas extraire d'informations pour les comptes d'utilisateur à extension messagerie, les contacts ou les groupes de distribution d'Active Directory. Si votre organisation Exchange 2003 est connectée à plusieurs systèmes de messagerie non-Exchange ou si vous avez créé des objets à extension messagerie pour des destinataires sur Internet, vous souhaiterez peut-être inclure ces objets à extension messagerie dans votre processus de synchronisation d'annuaire personnalisé, de manière à ce que les utilisateurs des systèmes de messagerie non-Exchange puissent communiquer commodément avec tous les utilisateurs de votre environnement de messagerie à l'aide de l'organisation Exchange 2003 comme structure fondamentale. Vous devez utiliser des outils tels que Ldifde.exe, Csvde.exe ou ADSI pour extraire les objets à extension messagerie d'Active Directory. La meilleure manière de synchroniser les groupes de distribution à extension messagerie se présente sous forme d'objets contact, de manière à pouvoir ignorer la synchronisation des membres d'un groupe. Vous pouvez corriger ces problèmes de groupes de distribution de différentes manières, comme indiqué dans la rubrique sur la Présentation de l'interopérabilité et de la migration dans Exchange Server 2003.

Remarque :
Si vous décidez de synchroniser les contacts à extension messagerie, il convient d'examiner attentivement vos processus de synchronisation d'annuaire pour éviter la duplication d'informations d'adresses, qui peut se produire si vous synchronisez des objets à extension messagerie faisant référence aux destinataires réels dans le système de messagerie existant.

Alternatives de synchronisation d'annuaire

Implémenter une solution personnalisée pour la synchronisation d'annuaire est un bon choix pour les administrateurs système qui préfèrent travailler avec des outils de ligne de commande et des interfaces API. Toutefois, si vous préférez implémenter une solution mise à disposition, vous souhaiterez peut-être envisager les options suivantes :

• Connecteurs de messagerie disponibles dans Exchange Server 5.5 ou Exchange 2000 Server Si vous exécutez une organisation Exchange en mode mixte, vous souhaiterez peut-être utiliser pour le transfert des messages et la synchronisation d'annuaire des connecteurs de messagerie, inclus dans Exchange 5.5 ou Exchange 2000 mais non disponibles dans Exchange 2003. Par exemple, Exchange 2000 permet de se connecter de manière transparente à Microsoft Mail pour PC Networks ou Lotus cc:Mail et Exchange 5.5 de se connecter à Microsoft Mail pour PC Networks, Lotus cc:Mail, ainsi que les systèmes PROFS et SNADS (Systems Network Architecture Distribution Services) d'IBM avec un connecteur passerelle direct.
• Microsoft Metadirectory Services (MMS) Vous pouvez utiliser le service MMS pour intégrer plusieurs annuaires entre eux. Le service MMS prend en charge une plage étendue de services d'annuaire, dont Active Directory, l'annuaire Exchange 5.5, les domaines Microsoft Windows NT®, Lotus Notes/Domino, Lotus cc:Mail, Novell NetWare Directory (NDS) ou Novell NetWare Bindery, Novell GroupWise, Banyan Systems BeyondMail and Intelligent Messaging, les langages SQL (Structured Query Language)/ODBC (Open DataBase Connectivity) et les serveurs d'annuaire LDAP, tels que Netscape, Sun ONE (anciennement désigné par le terme Netscape iPlanet), ainsi que les annuaires X.500. Le service MMS est un bon choix si votre organisation Exchange 2003 doit coexister de manière permanente avec un système de messagerie non-Exchange. Toutefois, si vous avez l'intention de remplacer l'infrastructure existante en migrant vers Active Directory et Exchange 2003 dans un futur proche, un investissement dans le service MMS peut ne pas être garanti.
• Connecteur Lotus Notes Si vous connectez Exchange 2003 à Lotus Notes/Domino, mais souhaitez envoyer des messages électroniques via SMTP plutôt que d'utiliser un connecteur Lotus Notes, vous pouvez conserver les annuaires synchronisés à l'aide des fonctions de synchronisation d'annuaire fournies par le connecteur Lotus Notes. Il vous suffit de modifier les tables de mappage pour les attributs d'annuaire, de manière à ce que les destinataires Exchange apparaissent comme destinataires SMTP dans Lotus Notes et que les destinataires Lotus Notes apparaissent comme contacts SMTP dans Active Directory. Pour plus d'informations sur la procédure de modification des tables de mappage, voir l'article 303724 de la Base de connaissance Microsoft sur la synchronisation d'annuaire entre Notes et Exchange avec des adresses SMTP (https://go.microsoft.com/fwlink/?linkid=3052&kbid=303724).

Intégration de calendrier

Exchange 2003 conserve les informations de disponibilité dans un dossier public système caché appelé SCHEDULE + DISPONIBLE/OCCUPé et nécessite une instance du Connecteur de calendrier pour placer les informations de disponibilité des utilisateurs non-Exchange dans ce fichier système. Malheureusement, le Connecteur de calendrier n'est pas disponible lorsque vous connectez Exchange 2003 à un système de messagerie non-Exchange via un connecteur SMTP ou X.400.

Vous pouvez contourner cette limitation grâce à l'option publication du service de disponibilité Internet (IFB) de Microsoft Outlook. Les utilisateurs d'Outlook peuvent utiliser cette fonction pour publier des informations de disponibilité dans un emplacement partagé, de manière à ce que d'autres utilisateurs, qui n'auraient autrement pas accès aux informations, puissent les récupérer. Les utilisateurs d'Outlook peuvent publier leurs périodes de disponibilité à l'aide du service de disponibilité Internet de Microsoft Office ou sur un emplacement du réseau interne. Lors de l'utilisation du service de disponibilité, vous pouvez limiter l'accès aux informations publiées de manière à ce que seuls les membres du service spécifiquement autorisés peuvent afficher vos informations. Par défaut, Outlook met à jour les informations de disponibilité sur le service de disponibilité toutes les 15 minutes, de manière à ce qu'elles reflètent votre planification la plus récente. Lorsque d'autres utilisateurs planifient une réunion avec vous, les périodes de disponibilité que vous avez publiées vers le service de disponibilité s'affichent automatiquement, sous forme de barres grisées, sous l'onglet Planification de leur demande de réunion, de manière à savoir à quels moments vous n'êtes pas disponible. Pour plus d'informations sur le service de disponibilité, voir la page https://go.microsoft.com/fwlink/?LinkId=25927.

Vous pouvez également publier vos informations de disponibilité sur un serveur interne. L'avantage de cette option est qu'il n'est pas nécessaire d'être membre du service. Un serveur Web sur intranet, un serveur FTP (File Transfer Protocol) interne ou un serveur de fichier permet de fournir le référentiel partagé. La seule différence parmi ces options est l'URL que vous devez spécifier dans la configuration de votre Outlook pour l'emplacement de publication des informations de disponibilité. Vous pouvez utiliser n'importe quel format URL valide, tel que : http://, file://\ ou ftp://.

La figure 9 illustre une possibilité d'implémenter le partage d'informations de disponibilité dans un environnement avec un système de messagerie non-Exchange.

La publication d'informations de disponibilité via Internet ou intranet fonctionne bien si tous les utilisateurs disposent d'Outlook. Toutefois, la publication IFB n'est prise en charge que si vous utilisez Outlook avec l'option IMO (Messagerie Internet uniquement). Pour plus d'informations sur la procédure de configuration d'Outlook avec l'option IMO, voir la documentation du produit Outlook.

D'autres clients de messagerie peuvent également prendre en charge la publication des informations de disponibilité via Internet ou intranet car la publication IFB est basée sur une norme IETF (Internet Engineering Task Force) appelée iCal. La publication IFB est basée sur la norme vCalendar, qui fait partie du iCal, et sur une norme pour le formatage et le stockage des informations de disponibilité.

Si vous activez une organisation Exchange où les utilisateurs ont généralement accès à leur boîte aux lettres via le service de transport MAPI pour Exchange, Outlook perpétue l'utilisation du dossier public système SCHEDULE + DISPONIBLE/OCCUPé pour tous les destinataires Exchange des listes d'adresses basées sur un serveur. Il ne vérifie ni le service de disponibilité ni aucun référentiel partagé pour ces comptes basés sur un serveur. Ces comptes basés sur un serveur incluent tous les utilisateurs Exchange, ainsi que tous les destinataires non-Exchange synchronisés avec Active Directory.

En d'autres termes, la publication IFB fonctionne correctement jusqu'à la synchronisation d'annuaire. Car, en ce qui concerne Outlook, les comptes d'utilisateur et les contacts à extension messagerie dans Active Directory sont des destinataires dans l'organisation Exchange 2003 pour laquelle Outlook ne peut prévoir de trouver des informations de disponibilité publiées sur un emplacement partagé du réseau d'entreprise. La publication IFB ne fonctionne pas car Outlook vérifie uniquement le dossier public système SCHEDULE + DISPONIBLE/OCCUPé pour les utilisateurs non-Exchange avec des objets destinataires synchronisés ; or les informations de disponibilité n'existent pas à cet emplacement.

Pour contourner le fait que la publication IFB ne fonctionne pas avec Outlook, excepté avec l'option IMO, vous disposez des choix suivants :

• Ne pas réaliser de synchronisation d'annuaire Si partager les informations de calendrier est plus important que fournir des listes d'adresses cohérentes sur tous les systèmes de messagerie, vous pouvez choisir de ne pas synchroniser les annuaires. Toutefois, la synchronisation des annuaires est généralement nécessaire pour une interopérabilité parfaite et il s'agit d'une priorité supérieure à la publication IFB. Si vous souhaitez fournir des listes d'adresses cohérentes basées sur un serveur, vous devez rechercher une solution différente pour fournir un accès multi-plateformes aux informations de disponibilité.

• Enregistrer les informations de calendrier comme page Web Si vous n'utilisez pas la fonction de publication IFB, vous pouvez publier un instantané d'un mois de votre calendrier avec tous les rendez-vous et réunions sur une page Web. Toutefois, il est important de noter que cette méthode indique tous les détails de vos réunions et autres rendez-vous. Vous publiez plus que des périodes de disponibilité dans ce scénario. De plus, la page Web ne se met pas automatiquement à jour lors des ajouts, suppressions ou modifications des rendez-vous dans votre dossier Calendrier. Par conséquent, vous devez enregistrer votre calendrier chaque fois que vous souhaitez mettre à jour la version Web.

• Fournir un accès aux informations de calendrier via une page ASP.NET Au lieu d'enregistrer des instantanés de calendrier comme page Web, vous pouvez choisir d'implémenter une solution personnalisée pour les recherches d'informations de disponibilité à l'aide des interfaces API d'Exchange, telles que CDOEX. CDOEX fournit une méthode GetFreeBusy via l'interface IAddressee que vous pouvez appeler par programme dans une page ASP.NET ou un programme Visual Basic. Vous pouvez également utiliser d'autres langages de programmation, tels que C++ ou Microsoft C#. Comme son nom l'indique, la méthode GetFreeBusy permet d'obtenir les informations de disponibilité d'un utilisateur Exchange 2003 valide.

  Remarque :
  CDOEX peut uniquement être utilisé directement sur un serveur exécutant Exchange 2000 ou Exchange 2003. Pour cette raison, il est préférable d'utiliser la méthode GetFreeBusy dans une page ASP.NET publiée via les services IIS (Internet Information Services) de Microsoft sur un serveur Exchange 2003.

  L'exemple suivant de code Visual Basic .NET, tiré du Kit de développement (SDK) d'Exchange, illustre la procédure d'obtention d'informations de disponibilité pour un utilisateur donné. Vous pouvez utiliser ce code pour fournir aux utilisateurs non-Exchange une solution basée sur le Web pour accéder aux informations de disponibilité des utilisateurs Exchange. Pour plus d'informations sur la méthode GetFreeBusy, voir la page sur la vérification du statut de disponibilité (en anglais) (https://go.microsoft.com/fwlink/?LinkId=25928).

  ' Reference to Microsoft ActiveX Data Objects 2.5 Library
  ' Reference to Microsoft CDO for Exchange 2000 Library
  ' Reference to Active DS Type Library
  Function GetFreeBusyString(ByVal strUserUPN As String, _
                             ByVal dtStartDate As Date, _
                             ByVal dtEndDate As Date, _
                             ByVal Interval As Integer) As String
  
     Try
        ' Variables.
        Dim iAddr As New CDO.Addressee()
        Dim freebusy As String
        Dim Info As New ActiveDs.ADSystemInfo()
  
        iAddr.EmailAddress = strUserUPN
        If Not iAddr.CheckName("LDAP://" & Info.DomainDNSName) Then
           Throw New System.Exception("Error occurred!")
        End If
  
       ' Get the free/busy status in Interval minute intervals
       ' from dtStartDate to dtEndDate.
       freebusy = iAddr.GetFreeBusy(dtStartDate, dtEndDate, Interval)
       GetFreeBusyString = freebusy
  
     Catch err As Exception
        Console.WriteLine(err.ToString())
        GetFreeBusyString = ""
     End Try
  End Function
  

  La méthode GetFreeBusy peut être utilisée uniquement pour obtenir des informations de disponibilité Exchange. Toutefois, plusieurs systèmes de messagerie fournissent des interfaces Web pour accéder aux données dans les boîtes aux lettres et référentiels publics. Vérifiez avec le fournisseur de votre système existant pour voir si une interface API similaire est disponible, de manière à ce que vous puissiez également fournir aux utilisateurs Exchange un accès aux informations de calendrier via une solution basée sur le Web personnalisée.

• Configurer Outlook pour utiliser la publication IFB mais une autre solution pour accéder aux informations de disponibilité publiées Une autre option, peut-être meilleure, pour fournir à la fois aux utilisateurs Exchange et non-Exchange un accès aux informations de disponibilité de chacun dans une solution ASP.NET est d'analyser les fichiers vCalendar que les clients Outlook peuvent écrire dans un annuaire partagé lorsque la publication IFB est activée. La publication d'informations de disponibilité fonctionne toujours. Seule la recherche d'informations de disponibilité pour les objets destinataires synchronisés est un problème pour les utilisateurs Exchange. Une solution ASP.NET peut résoudre ce problème. Les utilisateurs Exchange et non-Exchange peuvent configurer leurs clients Outlook pour publier des informations de disponibilité sur un serveur Web, puis utiliser la solution basée sur ASP.NET comme outil lors des planifications des réunions et conférences. L'implémentation d'une solution ASP.NET pour analyser des fichiers vCalendar est un sujet qui n'est pas abordé dans ce guide. Pour plus d'informations, voir la page sur le Kit de développement (SDK) de Microsoft Exchange Server 2003 (en anglais) (https://go.microsoft.com/fwlink/?LinkId=25925).

• Ignorer le problème Une autre option est d'éviter l'intégration de disponibilité dans son ensemble. S'il est possible de migrer des équipes et des départements comme une seule unité, les utilisateurs n'auront peut-être pas besoin d'informations de disponibilité multi-plateformes. Si vous migrez tous les supposés candidats à la réunion vers Exchange 2003 simultanément, les utilisateurs peuvent utiliser la fonction Outlook standard pour les recherches d'informations de disponibilité lors de la planification des réunions.