Échanger la file d'attente & A: Gestion des environnements hybrides

Configuration des déploiements d'Exchange hybride avec des fonctionnalités liées à Office 365 peut prêter à confusion au mieux, mais ça vaut la peine.

Henrik Walther

Coexistence de l'hybride

Q. Nous sommes actuellement configuration d'une coexistence avec Exchange 2010-basé. Nous nous préparons migrer des boîtes aux lettres de notre organisation Exchange 2007 vers Exchange Online dans Office 365. Nous utilisons des serveurs Exchange 2010 pour le déploiement hybride, parce que nous n'avons pas encore mis à niveau notre locataire d'Office 365.

Nous sommes une grande entreprise avec les utilisateurs d'Exchange à l'aide de plus de 30 différents domaines SMTP. Nous avons des utilisateurs avec plusieurs domaines d'adresse de messagerie principale différente. Certains utilisent des alias@contoso.com, d'autres utilisent des alias@fabrikam.com et ainsi de suite. Nous voulons la coexistence lorsque vous travaillez avec Exchange Online et l'organisation Exchange 2007 local pour tous les utilisateurs.

Cela nécessiterait nous créer un enregistrement DNS de découverte automatique pour tous les domaines SMTP, mais aussi ajouter la découverte automatique de nom de domaine pleinement qualifié (FQDN) à la fiche de réseau (SAN) de zone de stockage, nous prévoyons d'utiliser sur les serveurs Exchange 2010 d'hybride ?

**R :**Avec les anciens serveurs hybride — c'est-à-dire hybride serveurs Exchange 2010, vous devez créer un enregistrement de découverte automatique dans le DNS pour tous les domaines SMTP. Aussi, le certificat SAN doit inclure tous les enregistrements DNS de découverte automatique utilisé dans la liste de SAN. Par exemple, si vous avez utilisé trois domaines SMTP (contoso.com, fabrikam.com et wingtiptoys.com) dans votre organisation Exchange et que vous souhaitiez configurer coexistence pour tous les trois avec Exchange Online dans Office 365, vous devrez créer les enregistrements suivants de découverte automatique dans le DNS :

  • Autodiscover.contoso.com
  • Autodiscover.fabrikam.com
  • Autodiscover.wingtiptoys.com

Vous devrez également inclure ces documents dans le certificat de SAN. Vous pouvez utiliser les enregistrements CNAME pour la redirection de découverte automatique, mais qui ne change pas le fait que vous devez ajouter tous les enregistrements de découverte automatique pour le certificat de SAN. Aussi, déploiements d'Exchange hybride ne supportent pas la redirection Autodiscover SRV-basé.

Avec la fonctionnalité de domaine de découverte automatique, vous avez la possibilité de régler l'un de vos domaines SMTP que le domaine de découverte automatique. Ce faisant, vous supprimez les exigences suivantes :

  • La nécessité de créer un enregistrement de découverte automatique pour tous les domaines SMTP dans le DNS, à l'exception du domaine que vous définissez comme le domaine de découverte automatique
  • La nécessité d'inclure le FQDN Autodiscover pour tous les domaines SMTP utilisés dans le certificat de SAN

C'est en effet une grande nouveauté du Exchange Server 2013. Le groupe de produits Exchange présente toujours des nouvelles fonctionnalités dans la version la plus récente, mais en temps qu'ils également choisissent de port arrière une fonctionnalité à une précédente version d'Exchange. Quand il s'agit de la fonctionnalité de domaine Autodiscover, cela s'est passé avec la sortie de Exchange 2010 RU1 de SP3 (vous pouvez le télécharger ici). Oui, lorsque vous appliquez RU1, vous pouvez utiliser la fonctionnalité de domaine de découverte automatique dans une configuration hybride axée sur Exchange 2010. Pour définir le domaine de la découverte automatique, utilisez la commande suivante :

Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

Vous pouvez alors voir le domaine de la découverte automatique a été définie en exécutant la cmdlet Get-HybridConfiguration (voir Figure 1).

Run the Get-HybridConfiguration cmdlet to confirm the Autodiscover domain is set.

Figure 1 exécuter la cmdlet Get-HybridConfiguration pour confirmer que le domaine de découverte automatique est.

Messages manquants

Q. Nous avons configuré une coexistence avec Exchange 2010-basé pour lever la coexistence d'Exchange et la course entre Exchange 2003 et Exchange Online dans Office 365. Parce que nous exigeons des flux de messagerie dans Exchange Online de passer par les serveurs de notre local Exchange 2010 hybride, nous avons choisi l'option suivante dans l'Assistant de Configuration hybride afin de configurer le transport centralisée : "Router tous les messages de liaison Internet par le biais de serveurs Exchange local. Ceci est généralement fait pour des raisons de conformité. »

Nous avons configuré le déploiement hybride par le livre. Nous voir l'Assistant de Configuration hybride créé la réception nécessaire et envoyez le connecteur local et les connecteurs entrants et sortants dans Forefront Online Protection for Exchange (FOPE). Le nom de domaine qui est utilisé pour forcer TLS de FOPE vers les serveurs de hybride local est dans le certificat de tierce partie sur les serveurs de l'hybride. Il est bien réglée sur « recevoir pour connecteur qui accepte les sessions SMTP dans les plages IP FOPE. »

Malgré tout cela, e-mails envoyés par Exchange Online dans Office 365 pour les destinataires dans les organisations Exchange local (ainsi que des destinataires externes) ne sont jamais envoyées. Lorsque vous utilisez message tracking dans le centre d'administration FOPE, nous voyons l'erreur suivante :

« Adresse IP de la cible principale 451 4.4.0 a répondu avec : « Échec de validation de certificat de 454 4.7.5. » Tentative de basculement d'hôte alternant, mais qui n'a pas réussi. »

Nous sommes vraiment coincés, ici. Nous nous demandons si vous avez des idées sur comment résoudre ceci plus loin ?

**R :**En fait, j'ai vu ce message d'erreur dans un scénario de déploiement d'Exchange 2010 hybride. Lorsque la configuration d'une configuration hybride, à l'aide de l'Assistant de Configuration hybride, une des choses qu'il crée est un nouveau connecteur nommé de réception « Inbound de Office 365 "sur chaque serveur de transport hybride (voir Figure 2).

The Hybrid Configuration wizard creates the new Inbound from Office 365 Receive Connector.

La figure 2 Assistant la Configuration hybride crée les nouveaux entrants du connecteur de réception bureau 365.

Ce connecteur est configuré pour seulement accepter les sessions SMTP entrantes d'un ensemble spécifique de plages d'IP, qui sont associés avec le service FOPE utilisé dans Office 365 (voir Figure 3).

The Inbound from Office 365 Receive Connector only receives messages from a specific set of IP addresses.

Figure 3 The en provenance de Office 365 Receive Connector seulement reçoit des messages d'un ensemble spécifique d'adresses IP.

Cet réception connecteur est également défini sur le nom de domaine complet qui correspond au FQDN du certificat utilisé pour le déploiement hybride (voir Figure 4).

The Inbound from Office 365 Receive Connector settings match the FQDN on the hybrid certificate.

Figure 4 The en provenance des paramètres Office 365 Receive Connector correspondre le nom de domaine complet sur le certificat d'hybride.

C'est également sur le certificat pour correspondre au FQDN sur le connecteur sortant dans FOPE, vous pouvez donc utiliser forcé TLS. Tout cela a été mis en place par le livre, comme vous l'expliquer vous a fait, mais génère toujours le même message d'erreur vous avez reçu pour les messages sortants d'Exchange Online.

Tout en regardant le journal de protocole pour le connecteur de réception sur les serveurs de l'hybride, j'ai vu quelque chose d'étrange. Les sessions SMTP entrantes de FOPE allaient par défaut connecteur de réception. Parce que l'adresse IP varie et autres paramètres ont eu raison sur l'Office 365 connecteur de réception, cela n'avait aucun sens. Ensuite, j'ai remarqué que même si les sessions SMTP entrantes se sont présentant comme FOPE, l'adresse IP source est une adresse IP privée. Il s'avère que c'était une adresse IP virtuelle (VIP) sur un équilibreur de charge qui répartie les sessions SMTP entrantes sur les serveurs de hybride Exchange 2010.

J'ai ajouté le VIP privé à la liste de plages IP de serveur distant sur l'Office 365 connecteur de réception. Puis les messages ont été remis avec succès. Si vous utilisez un équilibreur de charge pour SMTP, vérifiez si vous avez affaire à la même question.

La touche droite

Q. Nous avons juste configuré deux serveurs d'hybride de Exchange Server 2013. Nous nous demandons si nous pouvons utiliser un Exchange Server 2013 hybride edition clés pour ces serveurs comme nous pouvons avec des serveurs Exchange 2010 hybride ?

**R :**Choses sont toujours être réglés dès maintenant quand il s'agit de la clé de produit utilisée pour les licences correctement Exchange Server 2013 comme serveur hybride. Donc pour l'instant, il suffit d'utiliser Exchange Server 2013 en mode d'essai. Lorsque l'essai expire, il ne devrait pas avoir d'impact sur votre déploiement hybride. Il en résultera seulement dans les écrans de rappel supplémentaire.

Henrik Walther

Henrik Walther est un Microsoft Certified Master : Exchange 2007 et Exchange MVP avec plus de 18 années d'expérience dans le domaine de l'informatique. Il travaille comme consultant senior dans l'équipe de cloud Office 365 avec Microsoft Services Danemark et comme un rédacteur technique pour Biblioso Corporation (une société américaine spécialisée dans la gestion services de documentation et de localisation). Il a plus de 14 ans d'expérience de l'écriture de livres, des articles, des colonnes, des livres blancs et bulletins.

Contenus associés