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

  • Article

Migrations et de transitions

Henrik Walther

T ransitions et migrations semblent être sur un grand nombre de grands esprits des gens. Dans cette installation, je questions sur le déplacement à partir d'Exchange 2003 vers Exchange 2007, ainsi qu'à partir d'une de ces options pour Exchange 2010.

Q Notre entreprise utilise Lotus Domino pour la messagerie. Toutefois, nous prévoyez de passer à Exchange.Because Exchange 2010 est tout autour de l'angle, nous sommes penser à ignorer Exchange 2007 et à la place de migration directement vers Exchange 2010. Avec Ceci est l'esprit, nous avons une question pour vous : Microsoft mettent Microsoft Transporter Suite à la prise en charge Exchange 2010 ou fournira un autre outil de coexistence et migration ?
Un  

L'équipe Exchange n'ajoutera pas de prise en charge pour Exchange 2010 dans Microsoft Transporter Suite. Au lieu de cela, il se basent sur les outils de partenaires pour fournir la fonctionnalité définie requise pour une migration Domino-to-Exchange. Par exemple, il s'agit d'aider les partenaires avec mises à jour par conséquent, leur coexistence de Domino vers Exchange / outils de migration fonctionnent correctement avec Exchange 2010. En outre, l'équipe Exchange va s'assurer que les partenaires de résoudre les lacunes de fonctionnalités.

Notez, cependant, que vous pouvez migrer sans utiliser les outils de partenaires qui prennent en charge Exchange 2010. Pour ce faire, vous devez déployer un serveur Exchange 2007 à utiliser comme un tronçon de migration. C'est-à-dire, ajoutez un serveur Exchange 2007 à votre infrastructure, puis configurer la suite de transporter sur elle. Migrer les données tout d'abord à partir de Domino vers ce serveur, puis à partir de là, les serveurs Exchange 2010.

Enfin, sachez que Microsoft ne prendra en charge transporter suite pendant toute la durée de vie d'Exchange 2007, la prise en charge étendue pour laquelle finit le dans 2017. Par conséquent, vous avez encore quelques années pour effectuer votre migration avec le Transporter Suite.

 
Q Je sais que Exchange 2007 release to manufacturing (RTM) et SP1 ne prennent pas en charge Windows PowerShell version 2, mais sera Exchange 2007 SP2? je demande, car nous intention de gérer Exchange 2007 et les serveurs 2010 avec les outils de gestion Exchange équivalents à partir du même serveur.
Un

Oui, Exchange 2007 SP2 prendra en charge Windows PowerShell v2 à cette fin exacte. Étant donné que Microsoft prend en charge l'installation d'Exchange 2007 et les outils de gestion 2010 sur le même serveur (voir de la figure 1), et ce qui facilite la gestion de Exchange 2007 et 2010 à partir de la même possible de serveur, prise en charge de Windows PowerShell v2 dans Exchange 2007 SP2 apportées sens.

Mais n'oubliez pas que le Service Pack 2 de Exchange 2007 ne pourrez pas tirer parti des nouvelles fonctionnalités, telles que PowerShell à distance, dans Windows PowerShell v2. Cela signifie simplement que vous pouvez installer Windows PowerShell v2 au lieu de Windows PowerShell v1. L'ensemble des fonctionnalités d'Exchange 2007 Windows PowerShell restera le même.

Figure 1 : Un seul serveur peut prendre en charge les outils de gestion Exchange 2007 SP2 et Exchange 2010.

Q

Nous prévoyez de transition à partir d'Exchange 2003 vers Exchange 2007. Avant cela, nous voulons mettre à niveau de nos contrôleurs de domaine vers Windows Server 2008 en tant queainsi que de le basculer les domaine et forêt niveaux fonctionnels à partir de Windows 2003 en mode natif deWindows 2008.Dans nos recherches, nous avons trouvé (documentationTechNet.Microsoft.com/library/bb232170.aspx) qui nous indique que le serveur Exchange 2003 ne fonctionne plus comme prévu si nous modifions l'environnement Active Directory pour le domaine en mode natif de Windows Server 2008.

Souhaitez vous éclaircir certains lumière sur pourquoi Microsoft ne prend pas en charge de commutation de l'environnement Active Directory en mode natif Windows Server 2008 ?
Un  

L'article est correct et Voici pourquoi. Tout d'abord, Microsoft a créé Exchange 2003 (ainsi que ses service packs) long avant qu'il a développé les environnements Windows Server 2008 et Windows 2008 Active Directory. Bien sûr, ainsi que le groupe produit Exchange ne disposait aucun risque du codage ou du test par rapport à un environnement Windows Server 2008 Active Directory lors du développement d'Exchange 2003.

Étant donné que Exchange 2003 n'est plus pris en charge (bien que la prise en charge étendue s'exécute par le biais de mid-2014), réserver alloués de ressources de test pour ce scénario n'est pas aucun sens.

Le résultat est que l'équipe Exchange ignore si toutes les fonctionnalités Exchange 2003 seront arrête dans un environnement Windows Server 2008 Active Directory. Mais voici certaine : Doit quelque chose de rompre, les risques de modification du code d'Exchange 2003 de Microsoft à résoudre le problème sont très faible sur aucun.

 
Q  

Nous avez été informés que plusieurs modifications de schéma dans Exchange 2007 SP2 activer coexistence avec Exchange 2010.Will que nous devons exécuter Setup.com /PrepareSchema lors de la mise à niveau vers Exchange 2007 SP2 ainsi que lorsque nous préparez l'environnement Active Directory pour Exchange 2010 ?

En outre, nous avons la même question pour Setup.com /PrepareAD et /PrepareDomain.
Un  

Exchange 2007 SP2 contient en effet des changements de schéma. À vrai dire, ce service pack inclut toutes les modifications de schéma requises par Exchange 2010. Oui, lire correctement. Si vous avez mis à niveau Exchange 2007 SP2, vous n'avez pas besoin exécuter Setup.com /PrepareSchema lorsque vous êtes prêt à préparer l'environnement Active Directory pour Exchange 2010. L'échange de groupe produit a choisi d'inclure le schéma Exchange 2010 change dans Exchange 2007 Service Pack 2 principalement afin que les clients avaient uniquement exécuter une fois Setup.com /PrepareSchema.

Mais même si vous avez mis à niveau vers Exchange 2007 SP2 et par conséquent apporté des modifications de schéma nécessaire pour Exchange 2010, vous devez toujours exécuter Setup.com /PrepareAD et /PrepareDomain utilisant les bits d'Exchange 2010. Il s'agit en raison des nouveaux groupes de sécurité universel, modèle de contrôle d'autorisation d'accès basée sur les rôles, des applets de commande et what non-qui est disponible avec Exchange 2010.

 
Q
Quel type de croissance de la base de données (NTDS.dit) Active Directory doit attendre après avoir installé les objets de schéma inclus avec Exchange 2010
Un  

En règle générale, prévoir 2 Ko de croissance de l'arborescence d'information d'annuaire (DIT) par la nouvelle classe ou un attribut dans le schéma Active Directory. Dans la mesure où Exchange 2010 installe environ 3 000 objets dans le schéma, vous devez prévoir la taille globale du fichier NTDS.dit à augmenter d'environ 6 Mo.

Comme mentionné dans ma réponse à la question précédente, les mêmes modifications de schéma sont incluses dans Exchange 2007 SP2 et Exchange 2010. Par conséquent, vous verrez la croissance quel que soit le même si vous exécutez Setup.com /PrepareSchema à l'aide de bits d'Exchange 2007 SP2 ou Exchange 2010.

Figure 2 : le fichier NTDS.dit peut être dimensionnable.

Q  

Étant donné que nous avons beaucoup d'utilisateurs de Mac, nous avons beaucoup d'Entourage 2008 (et plus) clients dans notre environment.Most de messagerie Exchange 2007 des clients Microsoft Entourage se connecter à Exchange à l'aide de Web-Based Distributed Authoring and Versioning (WebDAV), mais quelques se connectent via le protocole POP (Post Office Protocol), ainsi que IMAP (Internet Message Access Protocol).

Nous avez entendu dire que Microsoft est interruption WebDAV de Exchange 2010 et demandez si qui laissera clients Entourage forcés à se connecter à Exchange 2010 à l'aide de protocoles hérités tels que POP ou IMAP ?
Un  

Oui, vous avez raison, avec Exchange 2010 Microsoft interrompt WebDAV. Et Oui, cela signifie que les utilisateurs d'Entourage 2008 et les versions antérieures sont en mesure de se connecter à Exchange 2010 via POP ou IMAP.

Mais l'équipe Exchange ne peut pas ignorer uniquement ce protocole de client de messagerie car un autre groupe de produit Microsoft utilise. Par conséquent, Microsoft est en prenant soin de ce problème avec le nouveau client Entourage (c'est-à-dire, au moment de la rédaction de ce document, en version bêta).

Le client de Microsoft Entourage à venir utilisera Exchange Web Services (EWS) pour se connecter à Exchange. Par conséquent, cette version également prendra en charge davantage de fonctionnalités que les versions précédentes, basés sur WebDAV.

Maintenant les tâches, notes et les catégories peuvent synchroniser withExchange et la nouvelle version d'Entourage aura une prise en charge complète pour AutoDiscover (Entourage 2008 SP1 avait limité uniquement prise en charge de découverte automatique).

Vous pouvez en savoir plus sur la version à venir de Microsoft Entourage ici : officeformac.com/blog/Entourage-for-Exchange-Web-Services-Beta-is-Live.

 
Q  

Nous sommes une petite entreprise qui souhaite utiliser la nouvelle fonctionnalité de groupe (DAG) de disponibilité de base de données une fois que nous mise à niveau à partir d'Exchange 2003 à Exchange 2010.We avez lu toutes les sections relatives à DAG dans la documentation Exchange 2010 TechNet, mais ne peut sembler pour plus d'informations sur le nombre de serveurs membre DAG de cartes réseau ont besoin.

Les ordinateurs que nous vous prévoyez de dédier en tant que serveurs de membres DAG actuellement uniquement ont une carte réseau chaque. Est-ce suffisant ?
Un  

Bien que DAGs fonctionnera correctement avec uniquement une interface réseau, vous devez vraiment disposer d'au moins deux cartes réseau connectées à différentes des sous-réseaux dans chaque serveur membre DAG. En fait, Microsoft ne prend pas en charge DAGs avec uniquement une interface réseau.

Vous vous demandez peut-être pourquoi il s'agit d'un scénario de travail si Microsoft ne la prend pas en charge.

Figure 3 : Un serveur de base de données de disponibilité groupe membre doit avoir au moins deux interfaces réseau, comme illustré ici

Imaginez également, les éléments suivants : Vous avez un DAG avec deux serveurs membres chaque configuré avec deux cartes réseau--un réseau public pour les connexions MAPI (Messaging Application Programming Interface) et un réseau privé pour la réplication et de pulsation.

Maintenant, vous perdez le réseau privé, ce qui fait également Office le réseau de réplication. Dans ce cas, la réplication continue via le réseau public (même si vous n'avez pas activé la réplication pour ce réseau).

Si vous aviez uniquement une seule carte réseau dans chaque serveur membre DAG, réplication s'arrête. Selon la durée de la durée d'indisponibilité, files d'attente de copie énorme pourraient entraîner et vous risquez de perdre des données si la copie active de la base de données est endommagée et un basculement à une copie de base de données sur un autre serveur du membre DAG était requis.

 

Henrik Walther , un Microsoft Certified Master : Exchange 2007 et MVP Exchange avec plus de 15 ans d'expérience dans l'entreprise informatique. Il travaille comme architecte de technologie pour Timengo (un Microsoft Gold Certified Partner au Danemark) et comme rédacteur technique pour Biblioso Corp. (une société américaine spécialisée dans managé documentation et les services de localisation).