¿La mejor práctica para desmantelar un controlador de dominio que también es un servidor DNS?

Hay dos escuelas de pensamiento para el proceso de desmantelamiento de los controladores de dominio de Active Directory que se utilizan mucho como servidores DNS.

Agregue la dirección IP del DC saliente a un nuevo DC y asegúrese de que DNS esté escuchando en esa dirección.
Degrade el viejo DC, deje el rol de DNS en él y configure un reenviador de DNS global para su nuevo servidor.

Obviamente, ambos son puntos intermedios hasta que todos los servidores y dispositivos se hayan configurado para usar la dirección IP principal de un nuevo servidor, pero a veces ese período de transición puede ser relativamente largo dependiendo del tamaño del entorno.

¿Existe una mejor práctica clara aquí?

windows domain-name-system active-directory

— MDMarra
fuente

¿O un tercero, cambiar alguna / todas las referencias al antiguo servidor DNS a través de la red?

— gravyface

Por supuesto, ese es el objetivo final, por lo que lo llamé un recurso provisional. Pero en algunos entornos muy grandes, esa no es una opción si desea que se haga de manera oportuna. Yo dije:

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.

¿verdad?

— MDMarra

semántica ... tiene razón, pero prefiero simplemente cambiar sistemáticamente la configuración DNS de los dispositivos, monitorear la actividad, comenzar con ámbitos DHCP, luego trabajar a través de servidores en orden de menos importante a importante (servidores miembros a otros DC) ) que suplantar el antiguo servidor y / o dejarlo persistiendo más tiempo del necesario.

— gravyface

Por supuesto, esa es la mejor opción, pero cuando digo un entorno "muy grande", estoy hablando de infraestructura distribuida globalmente con más de 300 DC y muchos equipos de TI diferentes que administran diferentes componentes de la infraestructura. A veces, realmente no es posible asegurarse de tener todos los dispositivos en el primer swing durante una actualización.

— MDMarra

@gravyface No te equivocas, pero en entornos grandes y geográficamente dispersos con gestión descentralizada de diferentes componentes, no siempre es factible acordar un plan de juego, poner a todos en línea y trabajar hacia un objetivo común. A veces solo tiene que tomar una decisión para avanzar y encontrar una solución o solución alternativa para asegurarse de que tenga la menor implicación posible para los demás

— Mathias R. Jessen

Respuestas:

Dudo en responder porque creo que esta es más una pregunta de "debate" que una pregunta estrictamente de preguntas y respuestas ... pero es un vago sábado por la mañana, así que lo haré de todos modos.

¿Existe una mejor práctica clara aquí?

No. (Maldición, tal vez esta fue una respuesta fácil para todos ...)

Microsoft proporciona una guía Bingable muy genérica y fácil de ~~Google~~ sobre cómo degradar los controladores de dominio y realizar migraciones de AD y DNS, pero no me molestaré en vincularlos ni fingiré que abordan su pregunta específica, porque Microsoft obviamente no puede documentar cada caso específico para el entorno de cada organización diferente.

Por lo tanto, los administradores / ingenieros de sistemas como nosotros tenemos que llenar los vacíos con nuestra propia experiencia y experiencia donde Microsoft no ha escrito un script especial solo para nosotros, y eso es lo que nos hace valiosos.

Puedo darle un ejemplo de algo que hemos hecho para abordar este mismo problema, ya que también trabajo en entornos que abarcan todo el mundo con docenas o más controladores de dominio, bosques dispares de AD que conviven en las mismas redes, dispositivos que no son de Windows que también consumen Los servicios DNS de los mismos DC, etc. Mudarse a nuevos centros de datos y salir de los antiguos, la necesidad de migrar a un nuevo hardware o nuevas versiones del sistema operativo, y las políticas comerciales antiguas y simples son todas las posibles razones por las que necesitaríamos retirar los controladores de dominio que potencialmente todavía se usaban. Y cuando tiene varias organizaciones heterogéneas que actualmente usan esos servidores DC / DNS, generalmente es un proceso agotador y agotador de reconfigurar cada cliente (muchos de los cuales pueden no estar bajo su control) antes de desmantelar el controlador de dominio, involucrando a los gerentes de proyecto,

Por eso digo que no creo que nadie pueda darte la respuesta a esta pregunta. Hay mil maneras de hacerlo y algunas serán mejores que otras dependiendo de la estructura y las necesidades de su organización.

Algo que hemos hecho para enfrentar este problema es hacer un VIP para cada centro de datos y agrupar todos los controladores de dominio en ese centro de datos detrás de ese VIP. (Este VIP es para el servicio de DNS solamente por razones obvias, estoy no hablar de equilibrio de carga de Kerberos y LDAP.) De esta manera, los clientes puede ser configurado para utilizar ese VIP para su resolución de DNS, y somos libres para agregar y quitar controladores de dominio detrás de ese VIP cuando y como queramos.

Pero no está al frente del problema ... así que dadas las opciones que proporcionó:

Agregue la dirección IP del DC saliente a un nuevo DC y asegúrese de que DNS esté escuchando en esa dirección.

Degrade el viejo DC, deje el rol de DNS en él y configure un reenviador de DNS global para su nuevo servidor.

Elegiría la opción n. ° 1, porque su objetivo es desmantelar el servidor anterior lo más rápido posible, y la opción n. ° 2 no le ayuda a deshacerse del servidor anterior. Con la opción # 2, la existencia del servidor sigue siendo necesaria. Tampoco iría con la sugerencia de Mathias R. Jessen de zonas de código auxiliar, porque una vez más, todavía tiene que dejar el antiguo servidor en su lugar y en servicio, lo que no es propicio para su objetivo final.

Con la opción n. ° 1, por muy feo que sea, puede retirar el servidor anterior, reclamar ahorros de costos para su empresa, evitar tener que pagar otro mes de alquiler en ese centro de datos y recibir un premio por ser tan buen empleado.

Editar: Pensando en nuestro chat un poco más, creo que puedo haber proyectado mis propios requisitos sobre ti, porque tengo requisitos de desconectar lo antes posible en algunas cosas en este momento, así que eso estaba fresco en mi mente. Parece que no tiene un requisito inmediato para apagar el servidor lo antes posible.

Dicho esto, no voy a cambiar mi sugerencia, ya que todavía lo preferiría. Agregar la IP adicional a un controlador de dominio existente me ha funcionado bien en el pasado en escenarios muy similares, y preferiría eso en lugar de tener un extraño vestigio de un servidor sentado allí durante un período de tiempo indeterminado.

— Ryan Ries
fuente

Creo que esto se incluye good subjectiveen la publicación Buena subjetiva, Mala subjetiva que definió la regla de "preguntas de discusión". Por lo menos eso espero.

— MDMarra

@MDMarra Estoy de acuerdo. +1 para una pregunta estimulante e interesante. :)

— Ryan Ries

Además, solo para el registro, normalmente hago lo contrario de su sugerencia: D

— MDMarra

El camino al infierno de Active Directory está pavimentado con vendajes temporales. Asignar la dirección IP de un servidor DNS fuera de servicio o fuera de servicio a su nuevo servidor DC y DNS es un vendaje temporal.

Como @gravyface señaló en los comentarios, en el escenario ideal, cambiaría todos los ámbitos DHCP y las configuraciones estáticas para actualizar la preferencia de DNS del cliente a la nueva IP en lugar de la anterior, antes de que desarme por completo la antigua DC.

Entiendo que asegurarse de que todos los clientes se hayan reconfigurado no es necesariamente posible a tiempo, pero ciertamente considero la opción número 2 (reenviar todo el espacio de nombres) como la opción menos objetable aquí.

Además de permitir que el servidor anterior reenvíe solicitudes incluso después de degradarlo, recomendaría habilitar el registro de depuración para las solicitudes entrantes en el servidor DNS; esto hace que sea un poco más fácil evaluar no solo si los clientes todavía apuntan al servidor DNS antiguo, sino también identificando dichos clientes.

Dicho esto, creo que te has perdido la tercera opción obvia: ¡ Zonas Stub !

Degrade el DC, mantenga la función DNS y agregue todas las zonas que anteriormente tenía como zonas de código auxiliar - reenvíe todo lo demás. De esta manera, está obligando a los clientes a ponerse en contacto con los controladores de dominio que deberían usar, en lugar de hacer el trabajo por ellos.

— Mathias R. Jessen
fuente