Questions et réponses sur la file d'attente ExchangeAlignement des partitions de disque, planification pour SCR et bien plus encore

Henrik Walther

Q. Je planifie actuellement une migration d'Exchange Server 2003 vers une nouvelle organisation Exchange Server 2007. Pour répliquer les dossiers publics dans la nouvelle organisation, j'ai l'intention d'utiliser l'outil Microsoft® Inter-Organization Replication (IORepl). Cependant, j'ai entendu dire qu'IORepl n'est pas pris en charge avec un serveur cible Exchange 2007 et qu'il faut par conséquent introduire un serveur Exchange 2003 dans l'organisation Exchange cible.

R. Bien qu'il y ait eu des rumeurs affirmant que la réplication des données de disponibilité ou des dossiers publics entre une organisation Exchange 2003 et une organisation purement Exchange 2007 n'est pas prise en charge, cela n'est pas vrai. En fait, l'utilisation d'IORepl sur un serveur où les outils de gestion Exchange 2007 sont installés sans autre rôle de serveur Exchange 2007 est entièrement prise en charge. Gardez cependant à l'esprit que vous devez également installer le client MAPI (Messaging Application Programming Interface) et les Objets de données de collaboration (CDO) de Microsoft Exchange Server sur le serveur car ils ne sont plus fournis en tant qu'éléments de l'installation de base du produit.

Q. Je prépare actuellement une conception Exchange Server 2007 pour une grande entreprise qui comprend 150 000 postes de travail, et je dois calculer le nombre de serveurs de catalogue global requis par l'infrastructure de messagerie Exchange 2007. Pouvez-vous m'aider ?

R. Bien sûr ! Il s'agit précisément de la raison d'être de cette rubrique. Tout d'abord, il est important de comprendre que vous calculez le nombre de serveurs de catalogue global (ou plus exactement, le nombre de noyaux – et nous ne parlons pas des processeurs ici) nécessaires en fonction du nombre total de noyaux de serveur de boîtes aux lettres Exchange 2007 que vous avez l'intention d'utiliser. Notez que vous calculez le nombre de noyaux de serveur de catalogue global uniquement en fonction des serveurs de boîte aux lettres ; vous n'incluez pas les autres rôles de serveur Exchange 2007 tels que l'accès au client, le transport Hub, la messagerie unifiée ou le transport Edge. Bien que les autres rôles de serveur Exchange 2007 influencent le nombre de serveurs de catalogue global requis, le nombre de serveurs de boîte aux lettres qui sont déployés a un impact sur les autres rôles de serveur Exchange 2007, ce qui signifie que vous pouvez calculer le nombre de serveurs de catalogue global requis en fonction du nombre de serveurs de boîte aux lettres.

Par ailleurs, le nombre de noyaux de catalogue global dépend de si vous utilisez des contrôleurs de domaine 32 bits ou 64 bits dans l'infrastructure Active Directory®. Avec des contrôleurs de domaine 32 bits, vous utilisez un rapport 4:1, ce qui signifie que vous devez prévoir 1 noyau de catalogue global pour 4 noyaux de serveur de boîtes aux lettres. Avec des contrôleurs de domaine 64 bits, le rapport est de 8:1. Donc, par exemple, si vous déployez les serveurs de boîte aux lettres Exchange 2007 avec 8 noyaux installés et utilisez des contrôleurs de domaine 64 bits, vous aurez besoin d'1 serveur de catalogue global par serveur de boîtes aux lettres Exchange 2007. Enfin, si vous utilisez des contrôleurs de domaine 64 bits, veillez à installer suffisamment de mémoire pour que la base de données Active Directory entière (le fichier NTDS.DIT) puisse être mise en cache en mémoire.

Q. La réponse précédente explique les recommandations concernant le nombre de serveurs de catalogue global par serveur de boîtes aux lettres Exchange 2007. Comment puis-je calculer le nombre de rôles de serveur de transport Hub et d'accès au client Exchange 2007 qui doivent être déployés ?

R. Comme la réponse précédente le suggère, le nombre de serveurs d'accès au client et de serveurs de transport Hub Exchange 2007 (ou, plus exactement, de noyaux de serveur) que vous devez déployer est lié au nombre de noyaux de serveur de boîtes aux lettres. Il n'existe pas de règle absolue, mais la règle générale stipule 1 noyau de serveur d'accès au client pour 4 noyaux de serveur de boîtes aux lettres (rapport 4:1) et 1 noyau de serveur de transport Hub pour 7 noyaux de serveur de boîtes aux lettres (7:1). Le rapport 7:1 concerne uniquement les serveurs de transport Hub sans analyse antivirus. Lorsqu'un produit d'analyse antivirus tel que Forefront Security pour Exchange est installé, le rapport recommandé est généralement plus près d'1 noyau de serveur de transport Hub pour 5 noyaux de serveur de boîtes aux lettres (rapport 5:1).

Q. J'ai entendu dire qu'il est déconseillé d'installer plus de 8 cœurs de processeur dans un serveur Exchange 2007. Est-ce vrai, et si oui, pourquoi ?

R. Oui, c'est vrai. Bien qu'Exchange Server 2007 bénéficie considérablement de l'installation de processeurs multicœur, le nombre maximal de noyaux que vous devez installer dans un serveur Exchange 2007 est 8. Plus précisément, seulement 2 rôles de serveur Exchange 2007 peuvent en fait bénéficier de l'utilisation de noyaux supplémentaires (jusqu'à 8), à savoir les rôles de serveur de transport Hub et de boîtes aux lettres. Cela ne concerne en outre que des serveurs Exchange 2007 extrêmement occupés qui gèrent des millions de messages par jour et stockent plusieurs milliers de boîtes aux lettres.

Le groupe de produit Exchange a en fait effectué des tests avec 12 noyaux de processeur installés dans un serveur de boîtes aux lettres Exchange 2007 et a constaté des performances et une évolutivité de la banque d'informations négatives. Ils ont également observé que la latence moyenne des appels de procédure distante (RPC) doublait lorsqu'ils passaient de 8 à 16 noyaux.

À moins que vous ne prévoyiez des serveurs de boîtes aux lettres extrêmement occupés, 4 noyaux de processeur sont généralement suffisants. Pour plus d'informations et des considérations sur les processeurs pour les autres rôles de serveur Exchange 2007, consultez l'article à l'adresse technet.microsoft.com/aa998874.

Q. Nous effectuons actuellement une migration inter-forêts d'une organisation Exchange 2000 et Exchange 2003 vers une nouvelle organisation Exchange 2007. Cependant, lorsque nous essayons de déplacer une boîte aux lettres de la forêt source vers la forêt cible à l'aide de l'applet de commande Move-Mailbox avec le paramètre -SourceMailboxCleanupOptions DeleteSourceMailbox spécifié, l'erreur suivante apparaît :

« Bien que la boîte aux lettres ait été déplacée vers le serveur cible Exchange et supprimée du serveur source Exchange, une erreur s'est produite lors de la suppression des attributs de boîte aux lettres de l'utilisateur de la boîte aux lettres source. La version du système d'exploitation du contrôleur de domaine 'file01' est 5.0 (2195) Service Pack 4. La version minimale requise est 5.2 (3790) Service Pack 1 »

Un contrôleur de domaine Windows Server® 2003 (qui est également un serveur de catalogue global) existe dans la forêt source, mais il semble qu'il ne soit pas possible de spécifier quel contrôleur de domaine de la forêt source doit être utilisé, puisque le paramètre –DomainController peut uniquement spécifier un contrôleur de domaine ou un serveur de catalogue global dans la forêt cible. Est-ce correct ? Si oui, existe-t-il une solution de contournement ?

R. C'est correct. Vous ne pouvez pas spécifier un contrôleur de domaine ou le serveur de catalogue global de la forêt source dans le cadre de l'applet de commande Move-Mailbox ; le contrôleur de domaine (le serveur de catalogue global) sera choisi au hasard. Il existe l'une ou l'autre solution de contournement mais aucune d'entre elles n'est particulièrement jolie. La première consiste à désactiver les contrôleurs de domaine Windows® 2000 de la forêt source, mais je sais que ceci n'est souvent envisageable. La deuxième solution de contournement pourrait être utile dans votre situation. L'applet de commande Move-Mailbox doit utiliser un contrôleur de domaine qui sert également de serveur de catalogue global, ce qui signifie que vous pourriez être en mesure de résoudre le problème en supprimant le rôle de serveur de catalogue global des serveurs Windows 2000 de la forêt source. J'ai utilisé cette méthode avec succès dans plusieurs scénarios de migration, donc cela vaut sans aucun doute la peine d'essayer.

Q. Est-il possible d'installer un serveur d'accès au client, de transport Hub ou de boîtes aux lettres Exchange 2007 dans 1 site Active Directory tel que États-Unis, puis d'expédier le serveur vers un autre site Active Directory, tel que Danemark ? Si cela est pris en charge, le serveur Exchange 2007 découvrira-t-il alors automatiquement la nouvelle appartenance de site d'Active Directory ou cela nécessite-t-il une intervention manuelle ?

R. Oui, ce scénario est pris en charge et ne nécessite aucune intervention manuelle. Les services d'ouverture de session réseau (Net­Logon) et de topologie Active Directory de Microsoft Exchange (MSExchangeADTopology) gèrent l'appartenance de site pour les serveurs Exchange 2007. Si le serveur modifie l'appartenance de site, le MSExchangeADTopology met automatiquement à jour l'attribut de site du serveur connu sous le nom d'attribut msExchServerSite. Vous pouvez voir à la Figure 1 l'attribut msExchServerSite par l'utilisation d'un outil tel qu'ADSIEdit.

fig01.gif

Figure 1 Affichage de l'attribut msExchServerSite (Cliquez sur l'image pour l'agrandir)

Si vous voulez approfondir les relations entre les sites Exchange 2007 et Active Directory, je vous recommande vivement de jeter un œil à la section de la documentation Exchange 2007 appelée « Présentation du routage basé sur un site Active Directory » à l'adresse technet.microsoft.com/aa998825.

Q. Sur un serveur de boîtes aux lettres Exchange 2007 où la réplication continue locale (LCR) est activée pour les bases de données de boîte aux lettres, peut-on utiliser Microsoft Data Protection Manager 2007 (DPM 2007) pour sauvegarder les données de boîtes aux lettres via la copie passive de base de données de boîtes aux lettres ?

R. Bien que vous puissiez utiliser DPM 2007 pour sauvegarder les bases de données de boîtes aux lettres via le nœud passif d'un environnement de réplication continue en cluster (CCR) Exchange 2007, ce scénario n'est pas pris en charge lorsqu'il s'agit de copies de base de données de boîtes aux lettres dans un environnement LCR Exchange 2007.

Q. Il est possible de déplacer une base de données de serveur de boîtes aux lettres en cluster (CMS) Exchange Server 2007 vers un serveur de boîtes aux lettres autonome, mais est-il possible de monter une base de données non cluster sur un CCR ou un CMS Exchange 2007 basé sur un cluster à copie unique (SCC) ?

R. Dans la mesure où une banque d'informations Exchange Server 2007 ignore le type de serveur sur lequel elle réside, le montage d'une base de données non cluster sur un CCR ou un CMS basé sur un SCC est entièrement pris en charge.

Q. Selon l'article disponible à l'adresse technet.microsoft.com/bb508861, le service QMS (Message Quota Service) d'Exchange Server n'est pas pris en charge sur un serveur Exchange 2003 en cluster. Cependant, ce service sera-t-il pris en charge à l'avenir pour les environnements en clusters pour Exchange 2003 ou Exchange 2007 ?

R. L'outil QMS Exchange Server ne sera pas pris en charge sur les CMS Exchange 2003 à l'avenir. De plus, l'outil QMS n'est pas pris en charge avec les serveurs de boîtes aux lettres Exchange 2007 en cluster (ou, du reste, non cluster). Mais si vous utilisez Exchange 2007 dans votre organisation, il n'y a vraiment aucune raison d'installer l'outil QMS, puisque la même fonctionnalité est incluse en natif dans Exchange. Pour plus d'informations sur la façon de gérer les messages de quota dans Exchange 2007, consultez l'article à l'adresse technet.microsoft.com/bb232089.

Q. Avez-vous connaissance d'une documentation de référence qui répertorie les attributs qui sont définis sur les utilisateurs et/ou les objets de groupe Active Directory lorsque ces entités sont, respectivement, à extension boîte aux lettres ou à extension messagerie ?

R. La référence du modèle d'autorisations divisées de la documentation Exchange 2007 répertorie ces attributs. Vous pouvez trouver cet article à l'adresse technet.microsoft.com/bb430782.

Q. Existe-t-il un moyen de désigner un serveur de transport Hub Exchange 2007 comme serveur tête de pont pour le flux de messagerie interne dans notre infrastructure de messagerie Exchange 2007 ? L'idée serait, par exemple, que tout le courrier envoyé du site Active Directory 1 au site Active Directory 2 serait routé via le serveur de transport Hub A (situé dans le site Active Directory 1) vers le serveur de transport Hub B (situé dans le site Active Directory 2) et inversement. Cela fonctionnerait-il ?

R. Non. Pour que cela fonctionne, le serveur de boîtes aux lettres situé sur les sites Active Directory aurait besoin de savoir si les destinataires sont situés dans un site Active Directory différent. Le rôle de serveur de boîtes aux lettres Exchange 2007 ne possède pas ce type de mécanisme.

À moins que le serveur de transport Hub soit installé localement sur un serveur de boîtes aux lettres, le serveur de boîtes aux lettres chargera toujours les connexions d'équilibrage entre les serveurs de transport Hub dans le même site Active Directory. (Si le rôle de serveur de transport Hub est installé sur le serveur de boîtes aux lettres, le serveur de transport Hub situé sur la même boîte physique que le serveur de boîtes aux lettres est toujours préféré).

Ce n'est qu'après la catégorisation qu'Exchange 2007 saura où la boîte aux lettres du destinataire est située. La façon la plus simple de vous rapprocher de cet objectif consiste à utiliser le paramètre SubmissionServerOverrideList avec l'applet de commande Set-MailboxServer pour créer une liste statique de serveurs de transport Hub qu'un serveur de boîtes aux lettres doit utiliser, comme illustré à la figure 2 (voir technet.microsoft.com/bb232193).

fig02.gif

Figure 2 Paramètres du serveur de boîtes aux lettres (Cliquez sur l'image pour l'agrandir)

Cela signifie que si vous avez spécifié le serveur de transport Hub A ou B, le serveur de boîtes aux lettres utilisera toujours ce serveur de transport Hub, non seulement pour les messages envoyés aux destinataires sur un site spécifique mais également pour tous les sites Active Directory, ainsi que pour la remise de messages locale. Dans la mesure où ceci introduira, en théorie, un point de défaillance unique, je déconseillerais l'utilisation d'une telle approche.

Q. J'ai l'intention d'installer des serveurs de boîtes aux lettres Exchange Server 2007 SP1 sur Windows Server 2008 et je me pose des questions sur l'alignement de disque. Je sais que lorsqu'Exchange Server 2003 ou Exchange Server 2007 était installé sur les serveurs exécutant Windows Server 2003, il était recommandé de créer des partitions destinées à contenir les fichiers du journal des transactions et les banques d'informations de boîtes aux lettres à l'aide de l'outil diskpart afin d'améliorer les performances globales. Il était également conseillé d'aligner la partition de stockage conformément aux recommandations du fournisseur. Si le fournisseur de stockage ne prodiguait pas de recommandations, la meilleure pratique de Microsoft suggérait d'utiliser une valeur de 64 Ko.

Comment dois-je configurer les alignements de disque lors de l'installation de serveurs de boîtes aux lettres Exchange 2007 sur Windows Server 2008 ? Les mêmes règles s'appliquent-elles ?

R. Devinez quoi ? Avec Windows Server 2008, vous ne devez plus aligner les partitions de disque qui contiendront les fichiers du journal des transactions et les banques d'informations de boîtes aux lettres Exchange Server 2007 SP1 à l'aide de l'outil diskpart. Avec Windows Server 2008, les problèmes d'alignement des partitions de disque rencontrés dans Windows Server 2003, où une partition démarrait toujours sur le secteur 64 et désalignait de ce fait la partition entière lorsque vous utilisiez l'outil Gestionnaire de disques Windows, ont été corrigés.

Vous trouverez plus d'informations sur le problème d'alignement sur le blog de l'équipe Exchange à l'adresse msexchangeteam.com/archive/2005/08/10/408950.aspx. Par ailleurs, Windows Server 2008 aligne une partition de disque grâce à l'utilisation d'une limite de 1024 Ko. La documentation Exchange Server 2007 sur TechNet mentionne également ceci à l'adresse technet.microsoft.com/bb738145.

Q. Nous sommes actuellement dans la phase de planification de l'implémentation de la réplication continue en attente (SCR) dans notre environnement de messagerie Exchange Server 2007 SP1. Nous sommes un magasin relativement petit et nous ne pouvons pas nous permettre de déployer plus d'1 ordinateur physique où le serveur Exchange 2007 installé sert de cible SCR dans un deuxième site.

Nous ne savons pas s'il existe une prise en charge pour les autres rôles que le rôle de serveur de boîtes aux lettres sur la cible SCR.

R. Oui, les serveurs Exchange SCR source et cible peuvent tous deux exécuter d'autres rôles Exchange 2007 SP1. Cela signifie qu'un scénario où, par exemple, des serveurs Exchange 2007 SP1 avec les rôles de serveur d'accès au client, de transport Hub et de boîtes aux lettres installés sont déployés et utilisés comme cibles SCR est entièrement pris en charge.

Q. Notre entreprise, qui repose sur une forêt Active Directory Windows Server 2003 et une infrastructure de messagerie Exchange 2007, devra bientôt fusionner avec une entreprise récemment acquise. L'une des exigences lors de la fusion des 2 entreprises est que les listes d'adresses Exchange 2007 soient séparées pour que les utilisateurs de chaque entreprise puissent uniquement voir une liste d'adresses contenant les utilisateurs de celle-ci.

Je crois me rappeler certains articles de la base de connaissances Microsoft qui incluaient des instructions détaillés sur la façon de réaliser ceci dans un environnement Exchange 2003. Quelle est l'approche à adopter lorsqu'il s'agit de séparer des listes d'adresses dans un environnement de messagerie Exchange 2007 ?

R. Fournir toutes les étapes nécessaires prendrait beaucoup plus d'espace que celui dont je dispose ici. Heureusement, Microsoft a récemment publié un livre blanc technique qui explique comment configurer les organisations virtuelles et la ségrégation des listes d'adresses dans Exchange 2007. Vous pourrez trouver ce livre blanc à l'adresse technet.microsoft.com/bb936719. Par ailleurs, vous devriez consacrer quelques minutes à la lecture du billet qui inclut des commentaires concernant ce livre blanc sur le blog de Dave Goldman (voir go.microsoft.com/fwlink/?LinkId=115499).

Q. Exchange Server 2007 nécessite-t-il le service WINS (Windows Internet Naming Service) pour fonctionner correctement ?

R. Le produit Exchange Server 2007 à proprement parler ne nécessite pas WINS. Mais WINS pourrait être requis suivant la version de Microsoft Office Outlook® que vous utilisez dans votre environnement de messagerie Exchange Server 2007. Si votre environnement de messagerie se compose uniquement de serveurs Exchange 2007 et de clients Outlook 2007 ou Outlook 2003, WINS n'est pas nécessaire.

Enfin, il y a une situation rare où WINS est requis par Outlook 2007. Lors de la migration d'une une boîte aux lettres vers une nouvelle forêt Exchange, la version RTM d'Outlook 2007 essaiera de se connecter au serveur de boîtes aux lettres Exchange à l'aide du nom NETBIOS et non du nom de domaine pleinement qualifié (FQDN) comme prévu. Cependant, ce problème a été corrigé avec le correctif logiciel Outlook 2007 post-SP1 publié au mois de janvier 2008 (support.microsoft.com/?id=941275).

Si vos utilisateurs finaux possèdent Outlook 2002, WINS sera toujours nécessaire, puisque ce client s'appuie sur la résolution de nom NETBIOS. Je ne mentionne pas spécifiquement les clients Outlook antérieurs à Outlook 2002 vu qu'ils ne sont pas pris en charge avec Exchange 2007, mais cela s'appliquerait également à ceux-ci.

Henrik Walther est un architecte certifié Microsoft : messagerie (apprenti) et MVP Exchange, avec plus de 14 ans d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour Interprise Consulting et comme rédacteur technique pour Biblioso Corporation.