Exchange Queue & A Outlook Anywhere et IPv6, l'Analyseur de connexion à distance et plus encore
Henrik Walther
q: nous avez simplement terminé déploiement Exchange 2007 sur des serveurs Windows Server 2008 dans notre organisation et des éléments travaillez très bien, avec une exception. Même si nous avez configuré Outlook Anywhere (anciennement RPC sur HTTP) en suivant les instructions dans la documentation Exchange 2007 sur Microsoft TechNet, nous ne peut pas connecter aux serveurs accès client Exchange 2007 d'un client Outlook 2007 sur Internet, quel que nous tentons. Nous avons ont apporté que le certificat SAN est approuvé par le client et que le port TCP 443 est ouvert sur le pare-feu connecté aux serveurs d'accès client. Avez-vous déjà vu ce type de problème ?
A que fait, j'ai. Vous indiquez qu'Exchange 2007 a été installé sur les serveurs Windows Server 2008. Un serveur d'accès au client a été installé sur un serveur Windows Server 2008, il est important de garder à l'esprit qui Outlook Anywhere ne fonctionnent pas correctement si IPv6 est activé sur le serveur. Car IPv6 est activé par défaut lorsque Exchange 2007 SP1 est installé sur Windows Server 2008, vous devez vous assurer pour le désactiver. J'ai vu plusieurs cas dans lesquels cette résolu le problème.
Pour plus d'informations sur la raison pour laquelle Outlook Anywhere et IPv6 sur Windows Server 2008 formulaires un cocktail incorrecte et comment vous désactivez IPv6 correctement sur des serveurs Windows 2008 sans casser Exchange 2007, je recommande extraire le billet de blog de l'équipe Exchange de Microsoft à msexchangeteam.com/archive/2008/06/20/449053.aspx. Ce problème doit être résolu avec Exchange 2007 SP1 report 4.
q: je suis actuellement implémenter Outlook Anywhere et ActiveSync Exchange dans notre environnement de messagerie Exchange 2007 et J'AI a été demandez si il est une certaine manière possible vérifier que Outlook Anywhere fonctionnent comme prévu sur l'autre côté de notre réseau de périmètre. En outre, je souhaite Assurez-vous que le service de découverte automatique a été correctement configuré dans notre environnement. Pouvez vous donner me les pointeurs ?
un Oui, il est possible tester Outlook Anywhere fonctionne correctement. Deux employés de Microsoft (Shawn McGrath du groupe de produits Exchange d'et Hughes Brad auprès des services de support technique) ont créé un outil Web appelé Exchange Server à distance connexion Analyzer (ExRCA). L'outil (dans la figure 1 ) doit toujours être considérées comme un prototype, mais J'AI rencontrez pas les bogues ou comportement étrange fasse. L'outil peut effectuer Outlook 2007 Autodiscover et tests de connectivité RPC/HTTP; il peut également tester si ActiveSync Exchange et SMTP entrant messagerie flux fonctionne comme prévu. Bien que ExRCA n'est pas actuellement pris en charge par Microsoft, J'AI fortement recommandons pour les tests de connectivité à distance par rapport à Exchange 2007.
La figure 1 page de démarrage Exchange Server Analyzer connectivité à distance (cliquez sur l'image pour l'agrandir)
Questions-réponses sur notre organisation utilise Exchange Server 2007, est dans les étapes de planification du déploiement de la réplication continue standby (SCR). Nous souhaitons disposez d'un second ensemble de données pour chaque bases de données boîte aux lettres créées sur nos serveurs non mis en clusters de boîtes aux lettres Exchange 2007 SP1 dans un autre site. Nous ont été lecture beaucoup sur SCR dans la documentation Exchange 2007 sur Microsoft TechNet mais ont toujours une question que nous n'ont pas réussi à obtenir réponse il : si nous activez une cible de SCR, est cela a le même effet qu'un Move-Mailbox avec le paramètre –ConfigurationOnly spécifié pour toutes les boîtes aux lettres utilisateur dans une base de données de boîtes aux lettres particulière ? En d'autres termes, uniquement modifier l'emplacement de serveur Exchange dans Active Directory.
A étant donné que vous utilisez des boîtes aux lettres serveurs non-membres (sinon, appelée un serveur de boîtes aux lettres autonome) en tant que serveurs SCR source, votre compréhension est correcte. Étant donné que vous êtes d'activer la copie SCR sur un autre serveur, portabilité de base de données sera utilisée. Cela signifie que l'emplacement de serveur Exchange dans Active Directory pour les boîtes aux lettres utilisateur de la base de données de boîtes aux lettres respectifs va modifier.
Si serveurs SCR sources dans votre environnement Exchange 2007 soit réplication continue en cluster (CCR) - ou cluster à copie unique (SCC) - basé et vous avez utilisé un nœud passif dans un cluster avec basculement en tant que la cible de SCR, vous devez activer la cible SCR portant le même nom et l'emplacement de serveur Exchange dans Active Directory changerait pas.
Q : Nous avez finalisé simplement déploiement de Exchange Server 2007 dans notre environnement d'entreprise et ont été demandez si elle est prise en charge pour déplacer les groupes de sécurité Exchange 2007 six, qui ont été créées par programme d'installation Exchange 2007 lors de la forêt et les domaines sont préparées pour l'installation d'Exchange 2007, à une autre unité d'organisation au lieu de le Microsoft Exchange sécurité groupes UO, qui est créée dans le domaine racine.
A Contrairement aux Exchange 2000/2003, qui n'a pas vous permettent de déplacer les groupes Exchange vers un autre OU de la forêt Exchange 2007 en fait permet cela. Vous pouvez voir que les six Exchange 2007 groupes de sécurité (voir figure 2 ) créées lors de la forêt est préparée pour Exchange 2007 sont marqués avec deux propriétés uniques ; le premier est un GUID connu et le second est un nom unique qui peut modifier.
La figure 2 groupes de sécurité Exchange Server 2007 (cliquez sur l'image pour l'agrandir)
Ces deux propriétés et le fait que qu'ils sont ajoutées à OtherWellKnownObjects attribut la forêt respectifs lors de l'installation est exécutée, garantissent que Exchange pourront trouver les groupes de sécurité n'importe où dans la forêt. Afin de pouvoir continuer et déplacer les groupes de n'importe où vous souhaitez, même à un autre domaine dans la forêt ! Des détails supplémentaires se trouvent dans (Forum aux questions sur les autorisations Exchange 2007 excellente Ross Lauriat technet.microsoft.com/bb310792) inclus dans la documentation Exchange 2007 sur Microsoft TechNet.
q: cause de certaines restructuration de notre environnement de messagerie Exchange 2007, nous à déplacer le témoin de partage de fichier pour chacun de nos serveurs de boîtes aux lettres Exchange 2007 CCR vers un autre serveur de transport Hub. Pouvez vous fournir des instructions sur comment cela est effectué de manière pris en charge ?
un déplacement que le témoin de partage de fichier d'un serveur de transport Hub Exchange 2007 vers un autre est très simple. Vous utilisez simplement les étapes qui vous suivi lorsque vous configuré initialement le témoin de partage de fichier pour vos serveurs de boîtes aux lettres en cluster. La seule différence est le chemin que vous spécifiez sur le serveur. Les étapes appropriées se trouvent dans la procédure pour configurer la section Witness de partage de fichiers dans la documentation Exchange 2007 sur Microsoft TechNet (voir technet.microsoft.com/bb124922).
Par ailleurs, vous devez savoir que si vous avez apporté utiliser un nom CANONIQUE enregistrement pour pointer vers votre serveur de transport Hub lors de la configuration le témoin de partage de fichier, la tâche puis simplement serait une question de vous modifier le nom de domaine pleinement qualifié (FQDN) de la ordinateur hôte cible sur lequel l'alias dans le nom CANONIQUE respectif enregistrer points (voir La figure 3 ).
La figure 3 enregistrement CNAME pointant vers un ordinateur hôte cible pour un témoin de partage de fichier (cliquez sur l'image pour l'agrandir)
Gardez à l'esprit, toutefois, que si vous avez des noeuds de cluster situés dans différents sites, conseils de résilience de site du groupe produit Exchange a changé (voir msexchangeteam.com/archive/2008/04/03/448615.aspx). En fait, le groupe de produits Exchange n'est plus recommande d'utiliser enregistrements CNAME dans les environnements Exchange 2007 géographique-cluster.
q: nous envisagez améliorer les paramètres de sécurité pour les serveurs de messagerie Exchange 2007 dans notre organisation. Une partie de notre plan d'optimisation de sécurité consiste à chiffrer les volumes sur lequel se trouvent les bases de données Exchange. Nous avons demandé s'il est recommandé ou même pris en charge pour stocker les Exchange les fichiers de base de données sur un volume qui a été chiffré utilisant le cryptage (ENCRYPTING File System).
A la réponse est un non clair. Placer Exchange 2007 bases de données sur un volume chiffré en fonction de EFS est pris en pas charge par Microsoft. En fait, il est non pris en charge pour .edb, .log, .stm (Exchange 2000/2003), .dat, .eml et fichiers .chk. La principale raison est que ce type de chiffrement donne les surcharges supplémentaires, qui affecte sensiblement les performances.
Pour sécuriser vos données Exchange 2007 davantage de fichiers, vous devez empêcher tout accès non autorisé à l'ordinateur Exchange et utiliser le format de message S/MIME pour chiffrer les données de message. En outre, si vous installez Exchange 2007 sur Windows Server 2008, envisagez d'utiliser BitLocker pour protéger les volumes.
q: j'ai simplement installé Exchange 2007 SP1 sur un serveur Windows Server 2008 qui est également un contrôleur de domaine. Puisque je ne pas utiliser IPv6 dans cet environnement, J'AI désactivé sous connexions réseau après Exchange 2007 SP1 avait été installée, puis J'AI redémarré le serveur. Lorsqu'il a été fourni en ligne, les services Exchange 2007 n'est plus démarré. Erreur 214, enregistré dans le journal d'application contient les informations suivantes :
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
A : j'ai vu plusieurs rapports sur ce comportement. Bien que ce n'est pas recommandé d'installer un des rôles de serveur Exchange 2007 sur un serveur Windows Server 2008 qui est également agissant comme un contrôleur de domaine, avoir un ou plusieurs Exchange 2007 serveur rôles exécutés sur un contrôleur de domaine avec IPv6 désactivé doit fonctionner, en particulier puisque c'est un scénario courant dans les laboratoires de test et ailleurs. La solution de maintenant est pour réactiver IPv6 sur le serveur. Rumor a que Exchange 2007 SP1 report 4 va résoudre ce problème.
Henrik Walther est un Microsoft Certified Master : Exchange 2007 et MVP Exchange ayant des plus de 14 années d'expérience dans l'entreprise informatique. Il travaille comme architecte technologique pour Interprise conseil (une infrastructure Microsoft partenaire or basé dans Danemark) et comme un rédacteur technique pour Biblioso Corporation (une société ÉTATS-Unis-basé spécialisée dans les services gérés documentation et de localisation).