Meilleure pratique pour mettre hors service un contrôleur de domaine qui est également un serveur DNS?

9

Il existe deux écoles de pensée pour le processus de mise hors service des contrôleurs de domaine Active Directory qui sont largement utilisés comme serveurs DNS.

  1. Ajoutez l'adresse IP du contrôleur de domaine sortant à un nouveau contrôleur de domaine et assurez-vous que DNS écoute sur cette adresse.

  2. Rétrogradez l'ancien contrôleur de domaine, laissez le rôle DNS dessus et configurez un redirecteur DNS global sur votre nouveau serveur.

Évidemment, les deux sont des espaces vides jusqu'à ce que tous les serveurs et périphériques aient été configurés pour utiliser l'adresse IP principale d'un nouveau serveur, mais parfois cette période de transition peut être relativement longue en fonction de la taille de l'environnement.

Y a-t-il une meilleure pratique claire ici?

MDMarra
la source
2
Ou un troisième, modifier toutes / toutes les références à l'ancien serveur DNS sur le réseau?
gravyface
1
Bien sûr, c'est l'objectif final, c'est pourquoi je l'ai appelé un trou d'arrêt. Mais dans certains très grands environnements, ce n'est pas une option si vous voulez le faire en temps opportun. J'ai dit: Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.non?
MDMarra
la sémantique ... vous avez raison, mais je préfère simplement changer systématiquement la configuration DNS des périphériques, surveiller l'activité, en commençant par les étendues DHCP, puis travailler à travers les serveurs dans l'ordre du moins important à important (serveurs membres vers d'autres contrôleurs de domaine) ) que d'usurper l'identité de l'ancien serveur et / ou de le laisser traîner plus longtemps que nécessaire.
gravyface
Bien sûr, c'est la meilleure option, mais quand je parle d'un environnement "très grand", je parle d'une infrastructure distribuée à l'échelle mondiale avec plus de 300 contrôleurs de domaine et de nombreuses équipes informatiques différentes gérant différents composants de l'infrastructure. Parfois, il n'est vraiment pas possible de s'assurer que vous avez obtenu chaque appareil lors du premier swing lors d'une mise à niveau.
MDMarra
1
@gravyface Vous ne vous trompez pas, mais dans des environnements vastes et géographiquement dispersés avec une gestion décentralisée de différents composants, il n'est pas toujours possible de s'entendre sur un plan de match, de mettre tout le monde en ligne et de travailler vers un objectif commun. Parfois, il vous suffit de prendre une décision pour aller de l'avant et de trouver une solution ou une solution de contournement pour vous assurer qu'elle a le moins d'implications possibles pour les autres
Mathias R. Jessen

Réponses:

5

J'hésite à répondre parce que je pense que c'est plus une question de "discussion" qu'une question strictement Q&R ... mais c'est un samedi matin paresseux donc je le ferai quand même.

Y a-t-il une meilleure pratique claire ici?

Non (putain, c'était peut-être une réponse facile à tous ...)

Microsoft fournit des conseils Bingable très génériques et facilement googleables sur la façon de rétrograder les contrôleurs de domaine et d'effectuer des migrations d'AD et de DNS, mais je ne vais pas prendre la peine de les lier ni de prétendre qu'ils répondent à votre question spécifique, car Microsoft ne peut évidemment pas documenter chaque cas spécifique pour l'environnement de chaque organisation différente.

Ainsi, les administrateurs de systèmes / ingénieurs comme nous doivent combler les lacunes avec notre propre expertise et expérience où Microsoft n'a pas écrit un script spécial juste pour nous, et c'est ce qui nous rend précieux.

Je peux vous donner un exemple de quelque chose que nous avons fait pour résoudre ce même problème, car je travaille également dans des environnements à l'échelle du globe avec des dizaines ou plus de contrôleurs de domaine, des forêts AD disparates cohabitant sur les mêmes réseaux, des appareils non Windows consommant également Les services DNS à partir des mêmes contrôleurs de domaine, etc. étaient potentiellement encore utilisés. Et lorsque plusieurs organisations hétérogènes utilisent actuellement ces serveurs DC / DNS, il s'agit généralement d'un processus exténuant et fastidieux de reconfiguration de chaque client (dont beaucoup ne sont pas sous votre contrôle) avant de mettre hors service le contrôleur de domaine, impliquant des chefs de projet,

Voilà pourquoi je dis que je ne pense pas que quelqu'un peut vous donner la réponse à cette question. Il y a mille façons de s'y prendre et certaines seront meilleures que d'autres selon la structure et les besoins de votre organisation.

Quelque chose que nous avons fait pour résoudre ce problème est de créer un VIP pour chaque centre de données et de regrouper tous les contrôleurs de domaine de ce centre de données derrière ce VIP. (Ce VIP est destiné au service DNS uniquement pour des raisons évidentes, je ne parle pas d'équilibrage de charge Kerberos et LDAP.) De cette façon, les clients peuvent être configurés pour utiliser ce VIP pour leur résolveur DNS, et nous sommes libres d'ajouter et de retirer contrôleurs de domaine derrière ce VIP quand et comme nous le souhaitons.

Mais vous n'êtes pas devant le problème ... donc, compte tenu des options que vous avez fournies:

  1. Ajoutez l'adresse IP du contrôleur de domaine sortant à un nouveau contrôleur de domaine et assurez-vous que DNS écoute sur cette adresse.

  2. Rétrogradez l'ancien contrôleur de domaine, laissez le rôle DNS dessus et configurez un redirecteur DNS global sur votre nouveau serveur.

Je choisirais l'option # 1, car votre objectif est de mettre hors service l'ancien serveur le plus rapidement possible, et l'option # 2 ne vous aide pas à vous débarrasser de l'ancien serveur. Avec l'option # 2, l'existence du serveur est toujours nécessaire. Je n'accepterais pas non plus la suggestion de Mathias R. Jessen de zones de stub, car encore une fois, vous devez toujours laisser l'ancien serveur en place et en service, ce qui n'est pas propice à votre objectif final.

Avec l'option n ° 1, aussi moche soit-elle, vous pouvez retirer l'ancien serveur, réclamer des économies de coûts pour votre entreprise, éviter d'avoir à payer un mois de loyer supplémentaire sur ce centre de données et être récompensé pour avoir été un si bon employé.

Edit: En pensant un peu plus à notre conversation, je pense que j'ai peut-être projeté mes propres exigences sur vous, car j'ai des exigences de tirer-le-bouchon-ASAP sur certaines choses en ce moment, donc c'était frais dans mon esprit. Il semble que vous n'ayez pas autant d'exigences immédiates pour arrêter le serveur dès que possible.

Cela dit, je ne change pas ma suggestion, car je la préférerais toujours. Tacking l'IP supplémentaire sur un contrôleur de domaine existant a bien fonctionné pour moi dans le passé dans des scénarios très similaires, et je préférerais cela plutôt que d'avoir un appendice vestigial étrange d'un serveur assis là pendant une durée indéterminée.

Ryan Ries
la source
1
Je pense que cela relève good subjectivedu bon article subjectif, mauvais article subjectif qui a défini la règle des «questions de discussion». Du moins je l'espère.
MDMarra
@MDMarra Je suis d'accord. +1 pour une question intéressante et stimulante. :)
Ryan Ries
Aussi, juste pour mémoire, je fais généralement le contraire de votre suggestion: D
MDMarra
5

La route vers l'enfer Active Directory est pavée de bandages temporaires. L'attribution de l'adresse IP d'un serveur DNS déclassé ou à déclasser à votre nouveau serveur DC et DNS est un bandage temporaire.

Comme @gravyface l'a noté dans les commentaires, dans le scénario idéal, vous changeriez toutes les étendues DHCP et les configurations statiques pour mettre à jour la préférence DNS du client vers la nouvelle IP au lieu de l'ancienne, avant de déclasser complètement l'ancien DC.

Je comprends que la certitude que tous les clients ont été reconfigurés n'est pas nécessairement possible à temps, mais je considère certainement l'option numéro 2 (transférer l'intégralité de l'espace de noms) comme l'option la moins répréhensible ici.

En plus de laisser les anciennes demandes de transfert de serveur même après l'avoir rétrogradé, je recommanderais d'activer la journalisation de débogage pour les demandes entrantes sur le serveur DNS - cela facilite un peu l'évaluation non seulement si les clients pointent toujours vers l'ancien serveur DNS mais aussi identifier lesdits clients.

Cela dit, je pense que vous avez manqué la troisième option évidente: les zones de stub !

  • Rétrograder le contrôleur de domaine, conserver le rôle DNS et ajouter toutes les zones qu'il détenait précédemment en tant que zones de stub - transférer tout le reste. De cette façon, vous obligez les clients à contacter réellement les contrôleurs de domaine qu'ils devraient utiliser, au lieu de faire le travail pour eux
Mathias R. Jessen
la source