Partager via

Questions et réponses sur la file d'attente Exchange

  • Article

Installation d'Exchange 2003/2007 dans un environnement Exchange 2010

Henrik Walther

Question : Est-il possible d'installer Exchange 2003 ou 2007 dans une organisation Exchange 2010 pure ?

Réponse : s'il s'agit d'un environnement Exchange 2010 vierge (organisation Exchange composée uniquement de serveurs Exchange 2010 et dans laquelle aucune version antérieure d'Exchange n'a jamais été déployée), la réponse est non. Si vous avez effectué la transition d'Exchange 2007 vers Exchange 2010 et que le dernier serveur Exchange 2007 a déjà été mis hors service, la réponse est encore non. Vous ne pourrez pas installer Exchange 2007 ultérieurement dans cette organisation car elle sera maintenant considérée comme une organisation Exchange 2010 pure.

Si vous prévoyez d'effectuer la transition d'Exchange 2003 vers Exchange 2010 et que vous avez déjà préparé la forêt Active Directory à l'aide du programme d'installation d'Exchange 2010, là encore vous ne pouvez pas installer de serveur Exchange 2007 dans l'organisation. Soit dit en passant, cette impossibilité est signalée par un message d'avertissement lors de l'installation du premier serveur Exchange 2010 dans une organisation Exchange 2003 pure (voir la Figure 1).

 

Figure 1 Le programme d'installation vous avertit que vous ne pouvez pas installer Exchange 2007 dans l'organisation après l'avoir préparé à l'aide du programme d'installation d'Exchange 2010.

Par conséquent, si vous pensez que vous aurez besoin d'un serveur Exchange 2007 à une date ultérieure, vous devez conserver un serveur Exchange 2007 dans l'organisation après avoir effectué la transition d'Exchange 2007 vers Exchange 2010. Ou si vous effectuez la transition d'Exchange 2003 vers Exchange 2010, vous devez déployer un serveur Exchange 2007 dans l'organisation avant de préparer la forêt Active Directory à l'aide du programme d'installation d'Exchange 2010.

Question : nous utilisons actuellement Exchange 2007 comme système de messagerie dans notre environnement d'entreprise. Nous venons de mettre tous nos ordinateurs clients à niveau de Windows XP vers Windows 7, et nous avons quelques problèmes à installer les outils de gestion Exchange 2007 (SP2) sur les nouveaux clients Windows 7. Y a-t-il des particularités à noter lors de l'installation des outils de gestion Exchange 2007 sur Windows 7 ?

Réponse : Exchange Server 2007 ayant été développé avant Windows 7, les outils de gestion Exchange 2007 ne sont pas pris en charge sur Windows 7. Le groupe de produits Exchange a choisi d'axer ses efforts sur Exchange 2010, qui bien entendu prend en charge Windows 7. 

Le développement logiciel est toujours soumis à des contraintes budgétaires et de ressources, et malheureusement ces contraintes ont imposé certaines restrictions lorsque le groupe de produits Exchange a dû décider de la prise en charge de l'installation des outils de gestion Exchange sur Windows 7. L'un des principaux facteurs pris en considération a été le fait qu'environ 65 % de tous les clients qui utilisent Exchange sont toujours sous Exchange 2003, et maintenant que la version commerciale d'Exchange 2010 a été publiée, la plupart d'entre eux effectueront la mise à niveau directement vers Exchange 2010 sans passer par Exchange 2007.

La solution consiste à installer Exchange 2007 Service Pack 3 sur les clients Windows 7. Oui, vous avez bien entendu. Suite aux demandes des utilisateurs, le groupe de produits Exchange a décidé de publier durant le second semestre 2010 Exchange 2007 SP3, qui ajoutera la prise en charge de l'installation des outils de gestion Exchange 2007 sur les clients Windows 7 et d'Exchange 2007 sur les serveurs Windows Server 2008 R2. Pour plus d'informations sur la publication prochaine d'Exchange 2007 SP3, reportez-vous au site Web à l'adresse suivante : https://msexchangeteam.com/archive/2009/11/30/453327.aspx.

 

Question : en guise de préparation à une migration planifiée d'Exchange 2007 vers Exchange 2010, j'ai configuré un environnement de laboratoire avec deux forêts Active Directory distinctes. La forêt AD source contient une organisation Exchange 2007 et la forêt AD cible contient une organisation Exchange 2010.

Il me semble me souvenir que lorsque j'ai effectué une migration inter-forêt Exchange 2003 vers Exchange 2010, l'organisation cible n'exigeait pas forcément que les comptes d'utilisateurs Active Directory soient migrés vers la forêt AD cible.

Après avoir essayé d'effectuer un déplacement inter-forêt de certaines boîtes aux lettres Exchange 2007 vers une organisation Exchange 2010, j'ai constaté que les déplacements de boîtes aux lettres inter-forêts avec Exchange 2010 semblaient se comporter différemment par rapport à Exchange 2007.

Pouvez-vous m'expliquer comment déplacer des boîtes aux lettres d'une forêt à une autre lorsque la cible est une organisation Exchange 2010 ?

Réponse : vous avez raison lorsque vous dites que les déplacements de boîtes aux lettres inter-forêts dans Exchange 2010 ne fonctionnent pas comme dans Exchange 2007.

Comme vous l'indiquez, l'applet de commande Move-Mailbox d'Exchange 2007 n'exigeait pas nécessairement que les comptes AD soient migrés vers la forêt AD cible avant le déplacement de la boîte aux lettres associée. L'applet de commande Move-Mailbox d'Exchange 2007 recherchait dans la forêt AD cible des comptes AD correspondant à l'une des adresses proxy (adresses SMTP), ObjectSID sources (masterAccountSID, objectSID et sidHistory) ou legacyExchangeDN (adresse x500 estampillée sur l'objet utilisateur). Si une correspondance était trouvée, le compte AD associé dans la forêt AD cible était activé pour la messagerie. Dans le cas contraire, l'applet de commande Move-Mailbox créait un compte d'utilisateur AD activé pour la messagerie, mais désactivé.

Dans Exchange 2010, les choses ont changé. Tout d'abord, on n'utilise plus l'applet de commande Move-Mailbox. Elle a été remplacée par la toute nouvelle applet de commande New-Move Request qui, par ailleurs, apporte quelques nouvelles améliorations très utiles. De plus, lors des déplacements de boîtes aux lettres inter-forêts à l'aide de l'applet de commande New-Move Request, Exchange 2010 s'attend à trouver un mailuser valide et il tente de faire correspondre le compte source à un compte cible à l'aide du msExchMailboxGUID. Contrairement à Exchange 2007, il ne tentera pas d'effectuer une correspondance avec un compte cible à l'aide des attributs susmentionnés. Cela signifie qu'avant d'effectuer des déplacements inter-forêts avec Exchange 2010, vous devez mettre en service la forêt AD cible avec des utilisateurs de messagerie.

À propos, contrairement à Exchange 2007, il est maintenant possible d'effectuer des déplacements de boîtes aux lettres inter-forêts à l'aide de la console de gestion Exchange d'Exchange 2010 (voir la Figure 2). Il suffit d'ajouter d'abord l'organisation Exchange depuis la forêt AD cible vers la console de gestion Exchange.

 

Figure 2 La fenêtre de nouvelle demande de déplacement à distance d'Exchange 2010

Vous pouvez créer des utilisateurs de messagerie dans l'organisation Exchange 2010 à l'aide du script PrepareMoveRequest.ps1 décrit dans cette section sur Microsoft TechNet ou en utilisant Identity Lifecycle Management (ILM) 2007 FP1 (avec le dernier correctif qui activera la mise en service d'Exchange 2010 pour ILM 2007 FP1) ou à l'aide de Forefront Identity Management (FIM 2010), qui est actuellement disponible dans une version Release Candidate 1 et sera disponible dans une version RTM durant le premier semestre 2010.

Question : Exchange 2007 est actuellement déployé dans notre organisation. Nous avons implémenté une solution de disponibilité composée de quatre serveurs Exchange 2007 (deux serveurs sur lesquels les rôles de transport Hub et d'accès au client sont installés, et deux serveurs assumant la fonction de nœuds de cluster de serveur de messagerie dans un cluster à récupération en cluster continue [CCR, Continuous Replication Cluster]). Les serveurs Exchange 2007 sur lesquels les rôles de serveur de transport Hub et d'accès au client sont installés ont été configurés afin d'équilibrer la charge et de procurer un basculement automatique pour les connexions SMTP et clientes entrantes. Cette solution fonctionne très bien, mais maintenant qu'Exchange 2010 a été publié, nous souhaitons effectuer la mise à niveau vers cette nouvelle version de serveur Exchange. Nous souhaitons tirer parti de plusieurs nouvelles fonctionnalités, et on nous a également dit qu'il serait possible de réduire de moitié le nombre de nos serveurs Exchange sans perdre la fonctionnalité de haute disponibilité dont nous disposons actuellement.

Y a-t-il des éléments particuliers à prendre en considération avant d'implémenter une solution de haute disponibilité Exchange 2010 composée de seulement deux serveurs ?

Réponse : en effet, pour créer une solution de messagerie Exchange 2007 hautement disponible avec basculement automatique et sans point de défaillance unique au niveau matériel et au niveau stockage, il vous fallait au total quatre ordinateurs : deux serveurs avec les rôles de transport Hub et d'accès au client Exchange 2007 et deux serveurs assumant la fonction de nœuds de cluster dans un cluster CCR.

Le serveur de transport Hub dispose de fonctionnalités d'équilibrage de la charge et de basculement intégrées pour la communication intrasite, et vous pouviez le rendre redondant au moyen de mécanismes cycliques DNS. Mais puisque le rôle serveur d'accès au client n'inclut pas de fonctionnalité d'équilibrage de la charge, il vous fallait généralement configurer ces deux ordinateurs en tant que nœuds dans un cluster d'équilibrage de la charge réseau Windows afin de fournir des fonctionnalités d'équilibrage de la charge et de basculement automatique pour les connexions entrantes provenant de clients et de serveurs sur Internet et d'autres réseaux externes.

Les deux ordinateurs assumant la fonction de nœuds de cluster dans le cluster CCR possédaient dans ce cas respectivement les rôles de serveur de boîtes aux lettres actif et passif, de sorte que le serveur de boîtes aux lettres en cluster puisse basculer sur l'un ou l'autre nœud. Pour finir, il vous fallait dédier l'un des serveurs frontaux comme témoin de partage de fichiers dans le cluster CCR.

Comme vous le savez, la réplication CCR (de même que SCC, LCR et SCR) a été supprimée d'Exchange 2010. En contrepartie, Exchange 2010 propose une nouvelle fonctionnalité appelée Groupes de disponibilité de base de données. Cette fonctionnalité utilise la même technologie de synchronisation que CCR et SCR combinées, mais elle offre de très nombreuses nouvelles fonctions qui la rendent largement plus performantes que CCR et SCR. L'un des aspects intéressants d'Exchange 2010 est qu'il est possible d'installer d'autres rôles Exchange 2010 (transport Hub, accès au client et même Messagerie unifiée) sur le serveur sur lequel se trouve un rôle de serveur de boîte aux lettres ayant été ajouté à un groupe de disponibilité de base de données. Cela signifie qu'il n'est plus nécessaire de dédier deux ordinateurs comme serveurs frontaux pour les rôles de serveur de transport Hub et d'accès au client. Il vous suffit d'installer tous les rôles Exchange 2010 requis sur les deux ordinateurs, et vous disposez alors d'une solution de messagerie Exchange 2010 totalement redondante. Enfin, presque. Cela paraît trop beau pour être vrai, non ?

En fait, étant donné que les groupes de disponibilité de base de données utilisent dans une certaine mesure le composant Clustering avec basculement Windows (principalement la pulsation et la base de données de cluster), vous ne pouvez pas configurer les deux serveurs en tant que nœuds dans une configuration d'équilibrage de la charge Windows puisqu'il est impossible d'installer le Clustering avec basculement Windows et l'équilibrage de la charge Windows sur le même serveur. Cette impossibilité s'applique depuis Windows NT 4.0 et est due à des conflits de partage matériel potentiels entre le service de cluster et l'équilibrage de la charge Windows. Pour en savoir plus, reportez-vous à l'article suivant dans la Base de connaissances Windows : https://support.microsoft.com/default.aspx?kbid=235305.

Cela signifie que vous devez utiliser un périphérique d'équilibrage de la charge/basculement externe, tel qu'un équilibreur de charge matériel. Notez également que cet équilibreur doit être redondant ; un minimum de deux périphériques est donc nécessaire.

Bien que vous utilisiez tout de même le Clustering avec basculement Windows et que les Groupes de disponibilité de base de données soient une fonctionnalité de l'édition Enterprise, vous n'avez pas besoin d'Exchange 2010 Enterprise Edition pour utiliser cette fonctionnalité. Contrairement à la fonctionnalité CCR d'Exchange 2007, les Groupes de disponibilité de base de données sont également inclus dans l'édition standard d'Exchange 2010. Mais n'oubliez pas que vous êtes limité à un total de cinq bases de données (y compris les copies de bases de données actives et passives) dans ce scénario.

 Puisque vous installez les rôles de transport Hub et d'accès au client sur l'ordinateur qui détient le rôle de serveur de boîtes aux lettres et qu'il s'agit d'un serveur membre du groupe de disponibilité de base de données, vous économisez deux ordinateurs et deux licences d'édition standard de Windows 2008 et Exchange 2010. Si votre environnement ne possède aucun équilibreur de charge externe, vous pouvez recourir à un dispositif d'équilibrage de la charge virtuel ou faire l'acquisition d'un équilibreur de charge matériel. Bien entendu, il vous faut également un serveur assumant la fonction de serveur témoin, mais il n'est pas obligatoire qu'il s'agisse d'un serveur Exchange (bien que cela soit recommandé). Il peut s'agir de n'importe quel serveur de fichiers Windows 2003/2008 de votre environnement.

Henrik Walther est un Microsoft Certified Master : Exchange 2007 et un MVP Exchange, avec plus de 15 ans d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour Trifork Infrastructure Consulting (Microsoft Gold Certified Partner basé au Danemark) et comme rédacteur technique pour Biblioso Corp. (société basée aux États-Unis et spécialisée dans les services de documentation et de localisation gérés).

Contenu associé