Échange de file d'attente & A: les migrations et les mises à jour
Lors de la migration d’un groupe vers un autre groupe, les mises à jour ne sont pas toujours automatiques ni souvent souhaitées.
Henrik Walther
Exchange 2010 et Hyper-V
Q. Nous planifions de déployer Exchange Server 2010. Politique de l'entreprise stipule que tous les nouveaux serveurs doivent être des machines virtuelles (SSN) fonctionnant sous Hyper-V. Afin d'accroître la demande et la disponibilité du service, tous les serveurs racine de Hyper-V participent aux Clusters de basculement Hyper-V.
Nous avons vu récemment ce blog post sur le blog de l'équipe Microsoft Exchange annonçant le support de virtualisation de matériel amélioré pour 2010 de l'échange. Nous avons trouvé particulièrement la déclaration suivante intéressant :
« Combinant des solutions de haute disponibilité de Exchange 2010 (groupes de disponibilité de base de données [GCD]) avec axée sur l'hyperviseur clustering, haute disponibilité, ou des solutions de migration qui feront avancer ou automatiquement les serveurs de boîtes aux lettres de basculement qui sont membres d'un DAG entre serveurs racine en cluster, est maintenant supporté. »
C'est une bonne nouvelle pour nous, car elle signifie que nous pouvons désormais déployer des serveurs de boîte aux lettres Exchange 2010 participant à un DAG comme VMs sur un Cluster de basculement de Hyper-V. Y a-t-il autre chose que nous devrions être conscients de cela ?
**R :**Vous chronométrés certainement votre déploiement Exchange 2010 bien. Vous avez absolument raison que Microsoft supporte maintenant combinant GCD avec la technologie de regroupement et de la migration de basculement basé sur l'hôte. Ceci s'applique non seulement à Hyper-V, mais tout fournisseur de virtualisation matérielle participant à la Programme de Validation Windows Server Virtualization (SVVP).
Cependant, il y a quelques points importants à garder à l'esprit si vous comptez sur les membres vivants de DAG migration. Vous avez besoin d'échange 2010 SP1 ou version ultérieure pour cela d'être soutenu. Il a aussi fortement recommandé d'utiliser des volumes de cluster partagé et disques pas unique. Lorsque l'équipe de Hyper-V et un groupe d'échange produit testé chaque méthode, ils ont remarqué le temps hors connexion associé à déplacer les ressources de stockage a été réduit de moitié en utilisant des volumes de cluster partagé.
Si le temps hors connexion de serveur dépasse cinq secondes, le nœud de DAG va être expulsé du cluster. Il est donc important de s'assurer que le Cluster de basculement de Hyper-V peuvent migrer des ressources en moins de cinq secondes. Si elle ne le peuvent pas, ajuster le timeout de pulsation de cluster à une valeur plus élevée. Vous ne devrait pas affecter plus de 10 secondes, cependant.
Vous devez également vous assurer que vous avez appliqué les derniers correctifs de Hyper-V-liées aux serveurs hôte Hyper-V. Concernant le réseau de migration live, assurez-vous que les trames jumbo sont activés et les commutateurs impliqués soutiennent trames jumbo. Il est également recommandé que vous modifiez la mémoire tampon de réception sur chaque hôte Hyper-V de 8192. Aussi, vous devez déployer autant bande passante que possible pour le réseau de migration live (5 Go ou plus est préférable).
Il est important de configurer chaque machine virtuelle telle qu'ils sauver et restaurer l'État sur disque lorsque déplacés ou déconnecté. Tout basculement doit provoquer un démarrage à froid lorsque le nœud cible fonctionne une machine virtuelle. Un processus de migration planifiée doit également inclure une botte de fermeture et le froid. L'action hors connexion contrôlée par cluster est définie sur « Save State » par défaut. Au lieu de cela, il doit être défini sur « Shut down » (voir Figure 1) afin que le serveur froid bottes quand vivre-migré d'un nœud de Hyper-V à l'autre.
.jpg)
La figure 1 contrôlée par Cluster hors ligne, action est définie "Shut down.”
Le récemment publié "Des pratiques exemplaires pour virtualiser Exchange Server 2010 avec Windows Server 2008 R2 Hyper-V" livre blanc comprend beaucoup de bonnes informations sur Exchange 2010 virtualisation avec Hyper-V. Et, last but not least, la documentation Exchange 2010 sur TechNet a été actualisé pour tenir compte de cette nouvelle position de soutien.
Enregistrement de noms de domaine complets
Q. Nous avez déployé Exchange 2010 et ont un total de 12 rôles de serveur d'accès Client (CAS). Nous utilisons un modèle de centre de données de distribution utilisateur actif/passif. Cela signifie que nous avons un datacenter primaire et un datacenter de basculement. Il y a six rôles de CAS dans chaque datacenter. Nous utilisons une solution équilibreur de charge matérielle pour charger le trafic d'accès client équilibre dans chaque datacenter. Nous avons environ 50 000 utilisateurs, avec la plupart se connecter à leur boîte aux lettres à l'aide de clients internes de Outlook 2007/2010.
Nous avons vu récemment ce billet de blog sur le Blog de l'équipe Exchange, qui recommande à tous les clients activer l'authentification Kerberos pour les clients Outlook internes et explique pourquoi. En raison de cette recommandation, nous planifions activer l'authentification Kerberos pour les clients Outlook internes au sein de notre organisation.
Bien que nous avons lu le billet de blog en détail et vérifié la documentation Exchange 2010 sur TechNet, nous sommes encore un peu en doute when it comes to qui pleinement qualifié les noms de domaine (complets FQDN) nous avons besoin pour vous inscrire comme les noms principaux de service (NPS). Qu'en est-il l'auto-Découvrez FQDN ? Aurait besoin d'enregistrer ce FQDN ainsi ?
**R :**Je peux comprendre pourquoi vous êtes un peu confus sur l'auto-Découvrez FQDN. La plupart des clients ont un Autodiscover FQDN habituellement nommé autodiscover..com (companyname). Ce nom de domaine complet est pour des clients externes (principalement les dispositifs Outlook Anywhere et Exchange ActiveSync) pour la création automatique de profil.
Plusieurs fonctionnalités d'Outlook 2007/2010 s'appuient sur le service de découverte automatique (de bureau adjoint [OOF], Offline Address Book [OAB] et [UM] de messagerie unifiée). Les clients Outlook 2007/2010 internes n'utilisent pas ce FQDN Autodiscover, cependant. Ils rechercher le point de connexion de service dans Active Directory en utilisant le service de découverte automatique interne identificateur URI (Uniform Resource), qui, par défaut, souligne le FQDN de CAS (voir Figure 2).
Lorsque vous utilisez une solution d'équilibrage de la charge de distribuer le trafic client CASs dans un tableau de CAS, vous définissez généralement le service de découverte automatique interne URI pour pointer vers l'adresse IP virtuelle (VIP) associé au service virtuel respectif sur l'équilibreur de charge. Certains clients utilisent un nom de domaine complet dédié pour cela. D'autres utilisent simplement le FQDN même utilisé pour Outlook Web App (OWA), Exchange Control Panel (ECP), hyperactivité vésicale et Exchange Web Services (EWS).
.jpg)
Figure 2: FQDN pour le service de découverte automatique interne URI.
Mises à jour de point de terminaison
Q. Nous avons une solution Exchange 2010 site résiliente avec un primaire et le basculement de datacenter. Récemment, nous avons fait un basculement de datacenter prévues pour vérifier les étapes de notre plan antisinistre datacenter. Pendant le passage au numérique, nous avons remarqué quelque chose. Bien que les clients Outlook internes pourraient bien se connecter après avoir changé l'enregistrement DNS pour le tableau de CAS dans le datacenter primaire donc il a indiqué dans le tableau de CAS dans le datacenter de basculement, le point de terminaison de connexion n'est jamais mis à jour sur les clients.
Lorsque le tableau de CAS n'est pas disponible dans le datacenter primaire et l'enregistrement DNS pour ce tableau de CAS est mis à jour pour pointer vers le tableau de CAS dans le datacenter de basculement, n'est pas on attend ce comportement que le point de terminaison de connexion est mis à jour dans le client Outlook ainsi ?
**R :**Ce que vous voyez est en fait le comportement attendu. Le point de terminaison de connexion ne sera pas / ne devrait pas être mis à jour lorsque vous modifiez l'enregistrement DNS pour le tableau de CAS dans le datacenter primaire pour pointer vers l'adresse IP associée à la tableau de CAS dans le datacenter de basculement. Comme vous l'avez vu vous-même, les clients Outlook connect bien tant que le nom de tableau de CAS se résout à joignable adresse IP.
Ce comportement rend moins douloureuse alors que le passage au datacenter. Il vous suffit de prendre soin de réplication DNS — il n'y a pas lieu de s'inquiéter de savoir si un client Outlook avait son profil à jour.
Mises à jour de profil
Q. Nous avons plusieurs sites d'Active Directory, tous les serveurs Exchange 2010 SP1. Chaque site dispose de trois rôles de CAS. Afin de distribuer le trafic client entre les trois rôles de CAS à chaque site, nous avons créé des tableaux de CAS et GCD pour fournir la résilience de boîte aux lettres.
Parfois, un utilisateur déplace en permanence d'un site de physique à l'autre. Dans ce cas, nous allons boîte aux lettres de l'utilisateur à une base de données de boîtes aux lettres dans le nouveau site. Parce que nous déplacer la boîte aux lettres de l'utilisateur d'une base de données de boîtes aux lettres avec une valeur de serveur d'accès Client RPC différente de la valeur de la base de données cible, nous nous attendrions profil de l'utilisateur Outlook pourrait être mis à jour pour refléter la valeur de CAS de la RPC de la base de données de boîtes aux lettres cible (voir Figure 3).
.jpg)
Figure 3: valeur de serveur d'accès Client RPC pour une base de données de boîtes aux lettres.
Nous n'avons pas tous les clients Outlook 2003, seul 2007 et 2010. Jusqu'à présent, nous avons n'a pu avoir le profil Outlook mis à jour en exécutant une réparation de profil.
**R :**Je crois comprendre comment vous pouvez vous attendre le profil Outlook pour mettre à jour automatiquement pendant un déménagement de boîte aux lettres de cross-site d'une base de données de boîtes aux lettres avec une valeur de RPC CAS à une base de données de boîtes aux lettres cible avec une autre valeur de CAS de la RPC. En réalité, cependant, ce que tu vis est le comportement attendu.
La raison de ce comportement a à voir avec le fait que la source de CAS (tableau) détermine quelle boîte aux lettres, il doit accéder à basée sur les propriétés Active Directory. Si Active Directory est à jour, elle ne parle jamais de la base de données de boîte aux lettres erroné et jamais recevoir la réponse d'anecWrongServer, ce qui est nécessaire afin de déclencher une mise à jour du profil Outlook. Le groupe produit Exchange est pleinement conscient de ce comportement loin de l'idéal. Il n'y a aucun mot encore sur les cas — ou même si — cela sera corrigé.
Confiance, mais vérifiez
Q. Nous essayons de mettre en place la Fédération entre notre groupe Exchange 2010 et un autre. J'ai l'impression de se rappeler que vous devez utiliser un certificat de confiance d'une autorité de certification de tierce partie (CA) de mettre en place la Fédération fiducies entre organisations Exchange 2010. Je voulais vérifier si c'est vrai.
**R :**Vous a probablement lirez ceci avant Exchange 2010 SP1 avait été libéré. Avec Exchange 2010 RTM, vous exigeait un certificat de confiance d'une certification tierce pour obtenir une fiducie de Fédération de travail entre les deux organisations Exchange 2010.
Toutefois, cela a changé avec la sortie de Exchange 2010 SP1. Avec Exchange 2010 SP1, vous pouvez utiliser un certificat auto-signé ou un certificat émis par une PKI interne. En réalité, l'Assistant de « Nouvelle Fédération Trust » crée automatiquement et installe un certificat auto-signé spécifiquement à des fins de fiducie Fédération (voir Figure 4).
.jpg)
La figure 4 le nouveau certificat auto-signé créé par l'Assistant "nouvelle Fédération de confiance".
.jpg)
Henrik WaltherMicrosoft Certified maître : Exchange 2007 et Exchange MVP avec plus de 15 ans d'expérience dans le domaine de l'informatique. Il travaille comme architecte technologique pour Timengo Consulting (Microsoft Gold Certified Partner au Danemark) et comme rédacteur technique pour Biblioso Corp. (une entreprise américaine spécialisée dans géré les services de documentation et de la localisation).