Exchange Server utilisant un mauvais site Active Directory

Notre serveur Exchange 2013 a soudainement commencé à enregistrer des erreurs de mauvaise réplication entre les sites (il ne devrait pas y avoir de réplication car il n'y a pas d'autre serveur) ainsi que plusieurs autres problèmes qui semblent être liés.

Nous avons deux sites connectés par VPN. Il s'agit de la configuration des sites Active Directory:
il existe plusieurs sous-réseaux sur chaque site et le routage entre les sous-réseaux et les sites fonctionne correctement.

L'adresse IP du serveur Exchange est 10.10.0.26et il s'exécute sur le même hôte Hyper-V qu'un contrôleur de domaine avec l'IP 10.10.0.21(celle nommée XXXX-DC01 dans l'image) qui est définie comme faisant partie de la Default-First-Site.
Serveurs dans les sites

Le serveur Exchange pense qu'il se trouve sur le site YGXXX:
entrez la description de l'image ici

J'ai activé NTLOGON.LOG, mais les seules informations connexes semblent être:
entrez la description de l'image ici

Comment savoir pourquoi le serveur choisit le mauvais site?

active-directory exchange exchange-2013

— yakatz
source

Du serveur membre, telnet aux ports 88, 389, 445, etc., de vos contrôleurs de domaine de site local. Je blâmerais tellement le réseau en ce moment si j'étais vous, mais ensuite, les pare-feu se reconfigurent spontanément au milieu de la nuit juste pour me faire chier où je travaille.

— Ryan Ries

@RyanRies Ceux-ci et d'autres semblent tous ouverts. Le pare-feu Windows est désactivé sur DC et le serveur Exchange et DC sont sur le même serveur Hyper-V, mais je viens de remarquer qu'ils se trouvent sur différents commutateurs virtuels (alias différents ports réseau physiques dans ce cas). Cela pourrait-il le faire?

— yakatz

L'article Microsoft KB247811, Comment les contrôleurs de domaine sont situés dans Windows, est utile ici.

Cela dit, voici une liste de choses que je vérifierais si vous ne les avez pas déjà essayées:

Exécutez dcdiag.exe sur tous les contrôleurs de domaine pour voir s'ils ont rencontré des problèmes de réplication. Vous pouvez également vérifier les journaux des événements - parfois je les trouve plus faciles à lire que la sortie dcdiag.
Assurez-vous que l'adresse IP du serveur XXXX-DC01 est répertoriée dans les serveurs DNS répertoriés dans les propriétés de connexion réseau de votre serveur Exchange. Si le DC du site YG y figure, envisagez de le supprimer s'il ne fournit aucune redondance significative.

À partir de votre serveur Exchange, testez la recherche DNS:

c:\> nslookup
Default Server: XXXX-DC01.xxxxxxxxx.edu
Address: 10.10.0.21

> set q=SRV
> _ldap._tcp.xxxxxxxxx.edu

Si vous n'obtenez pas de réponse qui pointe vers votre premier site DC, vous avez un problème de connectivité DNS, un problème de serveur DNS et / ou un problème FSMO.
Si vous obtenez une bonne réponse, essayez d'exécuter une requête LDAP sur les serveurs DC renvoyés. Compte tenu de votre configuration, vous avez probablement déjà des utilisateurs et ordinateurs Active Directory (dsa.msc) installés sur le serveur Exchange. Exécutez cela à partir du serveur Exchange. Cliquez avec le bouton droit sur l'objet racine dans la hiérarchie et connectez-vous à votre contrôleur de domaine XXXX-DC01. Si vous ne pouvez pas vous connecter, vous savez que vous avez un problème LDAP, soit avec le service sur le contrôleur de domaine, soit avec la connexion et l'authentification à partir de la machine virtuelle Exchange.
Si vous pouvez vous connecter via dsa.msc, ma dernière suggestion serait de vérifier les FSMO. Ce n'est probablement pas le problème, mais cela vaut la peine d'être vérifié. Assurez-vous que vous disposez d'un contrôleur de domaine dans chaque site disposant d'un catalogue global (la propriété GC peut être modifiée sur les propriétés d'objet NTDS du serveur dans Sites et services Active Directory) et que le maître de schéma FSMO n'est pas un serveur de catalogue global. Alternativement, vous pouvez simplement faire de tous les serveurs des serveurs de catalogue global. Les définir tous est un peu une option mortelle, mais si vous avez une petite structure de répertoires qui se met rarement à jour, ce n'est pas la pire chose au monde.

— Howard Miller
source

DNS est très bien. Tous nos CD sont déjà des GC. À partir du serveur d'échange, l'un des 3 du premier site est inaccessible (en fait, l'ancien serveur d'échange qui était également un contrôleur de domaine - étrange car il peut contacter Exchange sur ce système pour la réplication de boîte aux lettres). Pourrait-il seulement essayer de contacter celui-là, puis changer de site?

— yakatz

Vous avez écrit "il ne devrait pas y avoir de réplication car il n'y a pas d'autre serveur". Donc, voulez-vous dire qu'il y avait auparavant Exchange sur ce serveur et qu'il répliquait OK quand il était encore installé, ou voulez-vous dire qu'Exchange est toujours là - mais peut-être pas aussi activement utilisé - et le nouveau serveur Exchange peut lui parler encore? Quoi qu'il en soit, vous voudrez peut-être voir pourquoi le trafic entre eux échoue comme "inaccessible".

— Howard Miller

Les serveurs n'ont pas de réplication configurée, mais le nouveau ne cesse de répéter que la réplication a échoué car il pense qu'elle est en place Site Bet sait que la base de données de boîtes aux lettres devrait l'être Site A. Exchange sur l'ancien système ne dispose plus de bases de données de boîtes aux lettres, la réplication n'est donc même pas possible.

— yakatz

Pourquoi avez-vous toujours des composants Exchange installés sur l'ancien serveur? Si vous n'en avez pas besoin, désinstallez-les. Si vous le faites, migrez leurs fonctions vers le nouveau serveur. Désinstallez-les ensuite.

— Howard Miller

— Je