Beaucoup de grandes entreprises vont jusqu’à placer des DC et des serveurs DNS secondaires dans chaque agence afin que, si une liaison WAN est défaillante, les systèmes de l’agence puissent continuer à communiquer entre eux. Bien entendu, en plaçant des serveurs DNS et des DC dans les agences, on provoque
Planifier le déploiement (2)
un flux de trafic lié à la réplication sur la liaison WAN qui relie l’agence au siège social. Aurez-vous suffisamment de bande passante pour ce surcroît de trafic ? Quand vous créez le premier DC dans une nouvelle forêt, Windows en fait un serveur DNS – en supposant qu’il n’y en a pas déjà un – et il attribue aussi divers rôles d’AD au serveur.
La plupart de ces rôles ne peuvent être attribués qu’à un serveur dans toute la forêt (pour les rôles au niveau de la forêt) ou à un seul serveur dans chaque domaine (pour les rôles au niveau du domaine). Si un DC qui héberge ces divers rôles était victime d’une panne irréparable, les rôles pourraient toujours être attribués à un autre DC. En revanche, si le premier DC du domaine est défaillant, le problème est très grave sauf si vous avez prévu l’éventualité d’un tel incident. Par défaut, ce DC détient tous les rôles maîtres pour la forêt et pour le domaine dont il est membre. Généralement, le serveur se comporte aussi comme un serveur DNS et comme le serveur GC : Exchange a besoin des deux pour fonctionner.
J’ai personnellement été confronté à un cas où un tel serveur était défaillant et il n’existait aucun serveur DNS secondaire ou serveur GC. Ce n’était pas beau à voir. Le serveur GC est important pour plusieurs raisons. Par exemple, si aucun serveur GC n’est disponible, l’administrateur est le seul utilisateur autorisé à se connecter. De plus, un serveur Exchange doit être capable d’interroger un serveur GC pour résoudre les adresses électroniques des destinataires des messages. Le serveur GC est aussi vital quand des clients Microsoft Outlook ouvrent la GAL (Global Address List).
En substance, vous ne devez pas permettre qu’un serveur DNS ou un serveur GC devienne un point de défaillance unique sur votre réseau, particulièrement si les deux sont le même serveur. Bonne nouvelle, la désignation d’un serveur comme serveur DNS secondaire est simple et vous pouvez configurer n’importe quel DC pour qu’il se comporte comme un serveur GC. Cependant, il ne faut pas configurer chaque DC de l’entreprise pour qu’il agisse comme un serveur GC – sauf si votre réseau est constitué d’un domaine.
Généralement, vous placerez un serveur GC dans tout site AD qui contient un serveur Exchange. L’exception à cette règle est celle d’un site qui contient moins d’une centaine de boîtes à lettres et la présence d’une bonne liaison WAN vers un autre site qui contient un serveur GC. Bien entendu, si la liaison WAN est défaillante, aucun serveur GC ne sera accessible. En disposant les serveurs GC, assurez-vous qu’il y a au moins un serveur GC pour quatre CPU Exchange. Ainsi, aucun serveur GC unique ne sera surchargé.
Téléchargez cette ressource
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Activer la mise en veille prolongée dans Windows 10
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Et si les clients n’avaient plus le choix ?
Les plus consultés sur iTPro.fr
- Le Zero Trust : pourquoi votre entreprise en a besoin
- Cloud souverain : répondre aux enjeux d’hybridation et de maîtrise des dépendances
- Cybermenaces 2026 : l’IA devient la nouvelle arme des attaquants
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
