Archivo de la etiqueta: windows server

Actualización de Failover Clusters

En Windows Server tenemos disponibles la funcionalidad de clúster gracias a los Failover Cluster o clústeres de conmutación por error. Con ellos, cuando tenemos un fallo de uno de los host, el resto de dispositivos se encargan de gestionar sus funciones dentro del clúster, permitiéndonos tener alta disponibilidad de infraestructuras o aplicaciones.

Pero Windows necesita instalar las actualizaciones del sistema cada cierto tiempo, y gracias a la característica de Actualización compatible con clústeres podremos instalarlas de una forma fácil y sencilla. Además, permite configurar una auto-actualización basada en una programación, con lo que podremos olvidarnos (en parte) del mantenimiento de este. Para ello, ese necesario instalar el rol CAU (Cluster-Aware Updating) en el clúster.

Pero, ¿no vale con instalar las actualizaciones en un nodo, reiniciarlo y seguir en los siguientes? No, ya que de esta manera únicamente cambiaríamos los roles en cada reiniciado, pudiendo tener problemas durante la instalaciones de las actualizaciones. La sucesión de pasos que realiza la Actualización compatible con clústeres es la siguiente:

  1. Poner cada nodo en modo mantenimiento.
  2. Mover los roles del nodo que se va a actualizar.
  3. Instalar las actualizaciones en dicho nodo.
  4. Reiniciar si es necesario.
  5. Sacar el nodo de modo mantenimiento.
  6. Restaurar los roles del nodo.
  7. Repetir los pasos con el siguiente nodo.

Se podrían hacer todos estos pasos de manera manual, pero mejor hacerlo con un único clic o automatizarlo.

Para acceder a función, tenemos que acceder al Administrador de clústeres de conmutación por error y entrar a la ventana principal del clúster en cuestión. Dentro de esta, donde podemos ver es estado actual, en la parte de acciones (en la zona izquierda), seleccionamos Acciones adicionales y Actualización compatible con clústeres.

clip_image001

En la ventana de Actualización compatible con clústeres podremos ver información general del estado actual:

  • Nombre del clúster
  • Estado de los nodos
  • Estado del clúster
  • Estado de actualizaciones en curso
  • Diferentes acciones

clip_image002

Las acciones disponibles son las siguientes:

  • Aplicar actualizaciones a este clúster: permite aplicar actualizaciones en ese mismo instante en los nodos del clúster. También se puede hacer con el comando de PowerShell:
  • Vista previa de las actualizaciones para este clúster: genera una lista de las actualizaciones disponibles para todos los nodos del clúster.
  • Crear o modificar perfil de ejecución de la actualización: modificación las diferentes opciones disponibles para la actualización.
  • Generar informe sobre ejecuciones de actualización anteriores: nos muestra los informes de todas las actualizaciones llevadas a cabo.
  • Configurar opciones de auto-actualización de clúster: permite configurar la auto-actualización del clúster basada en una programación. Para ello necesitamos instalar el rol CAU (si no está ya instalado, el asistente nos ayudará). También podemos elegir instalar actualizaciones recomendadas por defecto.
  • Analizar preparación de la actualización del clúster: realiza un análisis para comprobar el estado del clúster en los parámetros necesarios para llevar a cabo las actualizaciones.

Gracias a esta característica tan sencilla, que puede pasar desapercibida, podemos mejorar el proceso de mantenimiento de nuestros servidores siempre y cuando formen un clúster entre ellos.

Clonar registros DNS externos en Microsoft DNS Server

Ya explicamos en otro post como resolvimos el problema de conectar la oficina de Sevilla, que sólo podía tener IP dinámica. Para mantener el direccionamiento actualizado, en el gateway de la oficina de Sevilla tenemos un pequeño script programado que comprueba si la IP asignada por nuestro ISP ha cambiado y en caso afirmativo lo modifica en nuestro proveedor DNS.

Sin embargo, y dado que en Plain Concepts usamos split-brain DNS, necesitamos alguna forma de propagar ese cambio a nuestros DNS internos. Aunque esto podemos conseguirlo de muchas formas, dado que asumimos que esta situación en la que una de nuestras oficinas sólo tiene IP dinámica será temporal, queríamos solucionar el problema de la forma más sencilla posible, pero sin que por ello dejase de ser elegante.

Como era de esperar, todo lo que necesitábaos era una estupenda combinación de PowerShell y el programador de tareas. Una de las grandes novedades del servidor DNS de Windows Server 2008 R2 fue que este podía administrarse desde PowerShell, dejando -desde mi punto de vista- de lado al ya clásico dnscmd.exe. Así pues construí rápidamente un pequeño script que realiza las siguientes tareas:

  1. Consulta a un DNS externo (como Google u openDNS) la resolución del dominio pertinente, ej: oficina-sevilla.plainconcepts.com. Recordad que este dominio lo mantenemos siempre actualizado en nuestro proveedor DNS.
  2. Obtenemos de nuestro DNS interno el registro pertinente al dominio oficina-sevilla.plainconcepts.com. Como de costumbre, se nos devuelve un objeto de PowerShell.
  3. Clonamos el objeto y aplicamos la IP obtenida en el paso 1.
  4. Actualizamos el registro de nuestro DNS interno con el nuevo objeto clonado

El resultado sería el siguiente:

Todo lo que nos quedaría ahora es incluir este escript en el programador de tareas para que se ejecute automáticamente de forma periódica y tendríamos la IP siempre sincronizada con el DNS externo.

Happy resolution!

Como llevar nuestro servidor a la nube

Actualización (2015/07/03): Añadida otra forma de autenticación en Azure con PowerShell.

Cada vez es más común aprovechar las ventajas de la nube para nuestros servidores, y en Azure se puede hacer de una manera sencilla. Pero no siempre empezamos desde cero, muchas veces necesitamos migrar los servidores físicos. En este artículo vamos a ver cómo podemos realizar esta migración.

En este último caso, lo primero es comprobar que está habilitada la opción de Remote Desktop (o escritorio remoto), ya que la vamos a utilizar cuando nuestra máquina este en Azure. También tenemos que permitir las conexiones RDP en el Firewall de Windows para las redes públicas, ya que Azure crea una nueva interfaz de red, que de manera predeterminada es de este tipo.

clip_image001

Después tenemos que crear un VHD (Virtual Hard Disk), que es el formato que utiliza Azure para sus máquinas virtuales, al igual que Hyper-V. Para ello tenemos varias opciones, dependiendo de nuestros servidores:

  • Si tenemos un servidor virtualizado en Hyper-V, deberemos comprobar si el disco tiene formato VHD o VHDX. En el caso de tener el segundo formato, deberemos convertirlo con el comando:
  • Si tenemos un servidor virtualizado (que no sea Hyper-V), deberemos hacer una conversión como ya nos explicó Elena.
  • En el caso de tener un servidor físico, podemos usar la herramienta Disk2vhd que ya mostró Antonio.

Subir VHD a Azure

El siguiente paso es crear una cuenta de almacenamiento en Azure, que será donde subiremos el disco creado. Es importante tener en cuenta que la máquina virtual solo se podrá situar en la región donde este localizada la cuenta de almacenamiento.

clip_image002

Dentro de esa cuenta de almacenamiento hay que crear un contenedor, donde estarán los VHDs.

clip_image003

Para subir la imagen, tenemos que utilizar PowerShell y el comando Add-AzureVhd:

Opción 1, autenticación por certificado:

Opción 2, autenticación por credenciales:

Crear disco de máquina virtual

Una vez subido el disco, vamos al apartado máquinas virtuales y seleccionamos discos. Ahí tenemos la opción de crear un nuevo disco a partir de un VHD existente en nuestra cuenta de almacenamiento.

clip_image004

Usar el disco al crear una máquina virtual

Por último, debemos crear una máquina virtual nueva. Para ello, lo realizamos seleccionando la opción desde la galería.

clip_image005

De entre todas las opciones que aparecen, debemos seleccionar mis discos, y ahí aparecerá el disco que acabamos de añadir.

clip_image006

Después de esto, solo nos queda señalar las características de la máquina, y comenzar a disfrutar de ella en la nube.

Alta disponibilidad en VDI de Windows Server

Cada vez es más común utilizar infraestructuras de escritorios remotos para utilizar como ordenadores principales. Este puede ser el caso de una organización que en vez de comprar un número elevado de equipos, compran unos servidores que ofrezcan este servicio y unos clientes para acceder a este. En este artículo vamos a mostrar cómo establecer alta disponibilidad en los hosts que ofrecen las máquinas virtuales, que son el principal punto de fallo.

Infraestructura

Lo primero que vamos a hacer es definir la infraestructura. Para ello necesitaremos 4 máquinas (mínimo), todas ellas con Windows Server. Dos de ellas serán servidores “simples”, que harán los roles de RD Licensing, RD Connection Broker y RD Web Access. Los otros dos servidores serán más potentes, y albergarán las máquinas virtuales mediante el rol de RD Virtual Host. A parte, necesitaremos un espacio de almacenamiento compartido por estos últimos servidores.

La alta disponibilidad de los Virtual Host la ofreceremos gracias a la posibilidad de crear en Windows Server un Failover Cluster. A este Cluster le añadiremos el espacio de almacenamiento compartido como Cluster Shared Volume (CSV). Las interfaces de red recomendadas en estos servidores son cuatro: una para los clientes, una para las migraciones en caso de fallo, una para el heartbeat (comprobará si los servidores están caídos) y otra para el CSV.

El mapa de red será el siguiente:

clip_image001

Remote Desktop Services

Se va a hacer una instalación estándar de los roles de Remote Desktop Services. Podéis seguir esta guía. Las opciones a elegir en el asistente son:

  • Instalación de Remote Desktop Services.
  • Standard deployment.
  • Virtual machine-based deployment.
  • Elegir RD Connection Broker.
  • Elegir RD Web Access (puede ser el mismo que RD Connection Broker).
  • Elegir RD Virtualization Host (seleccionamos los dos).
  • Instalar.

El asistente se encargará de instalar los roles y herramientas necesarias en cada máquina.

Failover Cluster

Lo siguiente es configurar el Cluster. Para ello, desde el asistente de instalación de roles y características de Windows Server, seleccionamos Failover Clustering en características.

clip_image002

Esta característica hay que instalarla en todas las máquinas que harán de RD Virtual Host. Podéis seguir esta guía para configurarlo. Una vez acabado, deberéis agregar el disco compartido al Cluster como Cluster Shared Volume, que previamente deberéis haber añadido a cada servidor.

clip_image003

Una vez completado esto, y configurado las redes, tanto en el Cluster para el cliente, heartbeat y CSV, en Hyper-V para la migración, y un switch virtual para las máquinas de Hyper-V, ya podemos crear la colección de escritorios virtuales.

Virtual Desktop Infraestructure

La creación de escritorios virtuales la podemos hacer con los parámetros que necesitemos. En el momento de elegir el almacenamiento, debemos elegir la opción de Cluster Shared Volume, que será una carpeta montada dentro del disco duro de cada nodo del cluster.

clip_image004

Tras esto, podemos finalizar el asistente y crear las máquinas. Estas se unirán automáticamente al Failover Cluster, por lo que a partir de ese momento ya nos beneficiaremos de todas las ventajas: tendremos las opciones de un Cluster, como la migración y alta disponibilidad, y el acceso mediante escritorio remoto.

clip_image005

Si, además, queremos que por defecto las máquinas virtuales pertenezcan a un nodo (si este está operativo) deberemos marcarlo en el clúster, junto con el rollback. Además, podremos desplegar las actualizaciones en los virtual host con la ayuda del clúster para asegurarnos de que los usuarios no se vean afectados.

Como veis, gracias a las opciones de VDI y Failover Cluster de Windows Server, conseguiremos desplegar un servicio de escritorio remoto en alta disponibilidad ante fallos.

Aging y Scavenging en DNS

Los equipos con Windows permiten actualizar dinámicamente su registro A en el servidor DNS local al que consultan, permitiendo que los administradores tengamos una visión y control de los equipos que están conectados a nuestra red, así como tener resolución DNS de los equipos cliente de manera automática. Sin embargo, si el registro no se elimina correctamente cuando los equipos salen de la red, se quedan como registros obsoletos, lo que puede darnos varios quebraderos de cabeza:

  • Si un número elevado de registros obsoletos permanece en las zonas, pueden ocupar espacio en disco del servidor y provocar transferencias de zona innecesariamente largas.
  • Los servidores DNS que cargan zonas que contienen registros obsoletos pueden usar información no actualizada para responder consultas de clientes, lo que puede hacer que los clientes experimenten problemas de resolución de nombres en la red.
  • La acumulación de registros obsoletos en el servidor DNS puede reducir su rendimiento y capacidad de respuesta.
  • En algunos casos, la presencia de un registro obsoleto en una zona puede evitar que otro equipo o dispositivo use un nombre de dominio DNS.

Es por eso que los servidores DNS de Microsoft cuentan con varios mecanismos que permitan el borrado de estos registros obsoletos. Al final todo gira en torno a 3 conceptos: marca de tiempo en los registros (timestamp), envejecimiento (aging) y borrado de los considerados obsoletos (scavenging).

Cuando te pones a jugar con estos valores y con el miedo a que se borren registros que realmente no están obsoletos, con el paso del tiempo hemos visto muchas dudas que pretendemos resolver con este “Preguntas y respuestas frecuentes”:

1. El valor de TimeStamp (Marca de Tiempo) ¿indica la hora y la fecha en la cual el registro fue creado?

Cuando una máquina cliente utiliza actualizaciones dinámicas para registrar su entrada en DNS, el timestamp se crea/modifica en los siguientes casos:

  1. Cuando el registro es creado por primera vez por un cliente que no existía en la zona, se considera una “Actualización, y el timestamp es establecido con la fecha y la hora del sistema en ese momento.

  2. Si el cliente tiene un registro ya creado en DNS y cambia su dirección IP, se considera una “Actualización, y se actualiza el timestamp con la fecha y la hora del sistema en ese momento.

  3. Si el cliente tiene un registro ya creado en DNS y mantiene la misma dirección IP, se considera un “Refresco”, y la actualización del timestamp dependerá de la configuración de la zona (lo veremos más adelante).

  4. Si el DHCP es el propietario de los registros, y está configurado dentro del grupo DnsProxyUpdate para la creación de los registros en DNS, la actualización de los timestamp los llevará a cabo cuando renueve una concesión IP.

    Una vez el timestamp se ha establecido para un registro, este valor es replicado a todos los servidores que mantienen la zona DNS donde se encuentra dicho registro. Para ello el Aging/Scavenging debe estar habilitado en la zona.

    2. Si se configura el Scavenging con un valor de 7 días y no se reinicia el cliente en 7 días, ¿el registro correspondiente es borrado?

    Creo que lo mejor para entender la respuesta a esta pregunta es resumir como funciona el proceso de Aging y Scavenging y los tiempos que se manejan en cada caso.

    Antes de que un servidor DNS vaya a comprobar si un registro es susceptible de ser eliminado, deberemos habilitar Aging/Scavenging en la zona donde se encuentre el mismo.

    Para acceder a la configuración de Aging/Scavenging para una zona deberemos hacer click derecho sobre la misma, seleccionar “Propiedades”, pestaña “General” y pulsamos en el botón “Aging”.

    image

    Cuando estableces por primera vez Aging/Scavenging para una zona, la fecha y la hora que vemos en la parte inferior de la imagen se establece con la fecha y hora actual del sistema (la hora se redondea hacia abajo) + el valor de refresco “Refresh interval”.

    Ese valor indica el primer momento en el que la zona es susceptible de poder ejecutar el servicio de Scavenging (borrado de registros obsoletos).

    Una vez que se ejecute el servicio, comprobará los registros para ver cuales son susceptibles de borrado, esto es, los que hayan pasado sin actualizarse durante su intervalo de No-Refresco + Refresco.

    Refresh and No-Refresh intervals

    Estos valores son los que indican los tiempos de espera hasta que el servicio de Scavenging pueda actuar. Ambos deben expirar antes de que un registro pueda ser borrado.

    El valor de No-Refresco es un periodo de tiempo durante el cual un registro DNS no puede ser “refrescado”. Como vimos antes, consideramos un “refresco” a una actualización dinámica donde no existe un cambio de IP para el registro, sino que simplemente se actualiza el Timestamp. Si un cliente cambia su IP, es  considerada una “actualización”, la cual está exenta del tiempo de No-Refresco, y su entrada será actualizada siempre.

    Este intervalo de No-Refresco tiene como propósito reducir el tráfico de replicación entre los servidores DNS en los casos en los que el cliente no ha cambiado su configuración. Un cambio en un registro es un cambio que sí que debe ser replicado.

    Una vez que el Timestamp del registro + el intervalo de No-Refresco acaban, entramos en el Intervalo de Refresco. Este intervalo es en el cual están permitidos los “refrescos”, es decir, cuando se permite que un registro actualice su Timestamp.

    Durante este intervalo es cuando los clientes deben actualizar su Timestamp para “demostrar” que siguen activos. Una vez se actualice, será replicado al resto de servidores DNS que mantienen la zona, y ese registro volverá a entrar en el intervalo de No-Refresco.

    Si por cualquier razón, un cliente no consigue actualizar dinámicamente su Timestamp durante el intervalo de refresco, pasa a ser elegible de ser eliminado por el Scavenging.

    Nota: Debemos establecer los valores para los intervalos de No-Refresco y de Refresco de manera que estemos seguros de que les estamos dando tiempo suficiente a los clientes a realizar varios intentos de registro o actualización durante el intervalo de Refresco.

    Opciones de Scavenging en el Servidor

    Ahora mismo ya tenemos tanto los registros (con el Timestamp) como la zona (con lo que hemos hecho en el paso anterior) preparadas para poder ser ejecutado el proceso de Scavenging.

    La configuración del servicio de Scavenging a nivel de Servidor se establece haciendo clic derecho en el servidor dentro de la consola DNS, seleccionando Propiedades, pestaña Avanzada y habilitando “Enable automatic scavenging of stale records”.

    image

    El periodo que establecemos aquí, es el intervalo que va a esperar el servicio de Scavenging para ejecutarse en cada ciclo. Cuando este servicio se ejecuta, va a registrar un Evento 2501 que indica cuantos registros van a ser eliminados. Un Evento 2502 va a ser registrado cuando no haya ningún registro que eliminar.

    Sólo es necesario tener configurado Scavenging en un servidor, dado que los datos de la zona DNS serán replicados a todos los servidores que mantienen dicha zona.

    Aunque podríamos establecer el servicio de Scavenging en cualquier servidor que mantenga la zona, mi recomendación es hacerlo sólo en uno. La razón es que si el servidor falla al realizar el Scavenging, el problema no es demasiado grave, y además tendremos un único sitio donde comprobar qué es lo que ha fallado.

    Podemos saber cuando el servidor va a realizar el próximo proceso de Scavenging, observando los últimos eventos 2501 o 2502 y añadiendo el periodo de Scavenging que hayamos establecido en el paso anterior.

    Podemos también forzar manualmente la ejecución del servicio de Scavenging haciendo clic derecho en el servidor y seleccionando la opción “Scavenge Stale Resource Records”.

    Una vez tengamos todos los parámetros configurados (Actualizaciones dinámicas habilitadas en la zona, Aging/Scavenging en la zona, Scavenging en el servidor, etc), el servicio de Scavenging, que se ejecutará con una periodicidad que hemos establecido en el paso anterior, comprobará el Timestamp de cada registro en las zonas que tengan habilitado Aging/Scavenging y comparará si la fecha/hora actual es superior al valor del Timestamp + No-Refresh + Refresh, y si es así, eliminará el registro.

    image

    3. ¿Es necesario reiniciar el cliente cada 7 días para que actualice su registro en DNS?

    No, por defecto, los clientes Windows intentarán realizar una actualización dinámica de su registro DNS cada 24 horas.

    4. Si se añade un registro en DNS de manera manual, cual es el valor del Timestamp y cuál es el comportamiento del Scavenging en este caso?

    Cuando un registro en DNS es añadido de manera manual, el Timestamp se establece como “estático” lo que supone un valor de 0. En este caso el servicio de Scavenging ignorará estos registros y no los eliminará.

    5. Buenas prácticas

    Fase de configuración:

    1. Debemos asegurarnos de que el servicio de Scavenging está deshabilitado a nivel de servidor en todos los DNS.

    2. Habilitamos Aging/Scavenging en las zonas en las que queramos tener esta funcionalidad. Estableceremos los intervalos de No-Refresco y Refresco como vienen por defecto (7 días). La recomendación es que estos valores sean inferiores al tiempo de concesión del DHCP (en nuestro caso de 8 días) para evitar resultados inconsistentes.

    3. Sumamos la fecha actual más el intervalo de No-Refresco más el intervalo de Refresco, y volvemos en esa fecha a revisar si los Timestamp de los clientes han sido actualizados correctamente.

    Fase de saneamiento:

    Comprobamos si existe algún registro que tenga su Timestamp anterior a los tiempos de No-Refresco+Refresco (no se ha actualizado durante el tiempo que hemos esperado). Si existe alguno, tenemos que revisar si se trata de un cliente activo ya que puede haber fallado la actualización dinámica y debemos corregirlo antes de continuar. Aunque sea costoso, es importante realizar una comprobación exhaustiva en este momento.

    No debemos continuar a menos que podamos explicar los registros obsoletos, ya que serán eliminados en la siguiente fase.

    Fase de activación:

    El paso final es habilitar Scavenging a nivel de servidor. Como vimos antes es recomendable hacerlo únicamente en un servidor DNS.

    6. Podemos encontrar mucha más información en los siguientes artículos:

    Using DNS Aging and Scavenging

    http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx

    Don’t be afraid of DNS Scavenging. Just be patient.

    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Using DNS servers with DHCP

    http://technet.microsoft.com/en-us/library/cc787034(WS.10).aspx

    Integrating DNS with DHCP

    http://technet.microsoft.com/es-es/library/cc757867(WS.10).aspx

    Espero que os sea de utilidad.

    ¡Hasta la próxima!

    Túneles Site-2-Site en Azure con Windows Server 2012

    Hola a todos,

    Hoy nos toca hablar de un tema que afecta a toda empresa que quiera integrar su infraestructura local con su infraestructura en Azure. Por supuesto, me refiero a los túneles S2S. Aunque ya hemos hablado de ellos, en este post vamos a detallar cómo hacer la configuración en el caso de usar una máquina Windows Server 2012.

    A modo de resumen, un túnel Site-to-Site (S2S para los amigos), nos permite extender nuestra red local hasta Azure, de forma que las máquinas virtuales allí hospedadas puedan acceder a nuestros recursos locales y viceversa, todo de forma transparente al usuario.

    Diagrama básico de la conexión.
    Diagrama básico de la conexión.

    Para llevar a cabo esta tarea, los requisitos no son muy elevados. En uno de los casos más básicos, nos basta con disponer de una suscripción a Azure, y una máquina con Windows Server 2012 (o 2012 R2) en nuestra intranet, que esté conectado directamente a Internet (con una IP pública). Hay otras posibles configuraciones, como una implementación con GNU/Linux que ya publicamos en nuestro blog.

    Seguir leyendo Túneles Site-2-Site en Azure con Windows Server 2012

    Problemas mezclando controladores de dominio de Windows Server 2003 con controladores de dominio de Windows Server 2012 R2

    Actualización (2015/1/22): Ya hay disponible un hotfix en http://support.microsoft.com/kb/2989971

    Estoy trabajando en un proyecto donde estamos haciendo una extensión de red en Microsoft Azure a través de tunel Site to Site y entre las primeras tareas a llevar a cabo es replicar un par de controladores de dominio en máquinas de Azure.

    El dominio se encuentra en modo funcional de Windows Server 2003 y los servidores son, evidentemente, Windows Server 2003 (en efecto, ¡están fuera de soporte!). Más allá de lo poco recomendable que es a día de hoy mantener sistemas con Windows XP o Windows Server 2003, me he topado con este post del blog oficial del equipo de soporte de AD DS.

    El problema consiste en un fallo en la autenticación por Kerberos que ocasiona que los usuarios no puedan iniciar sesión de forma aleatoria. El problema aparece si tenemos el siguiente cóctail:

    • Controladores de dominio con Windows Server 2003.
    • Controladores de dominio con Windows Server 2012 R2.
    • Ambos tipos de controladores sirviendo para el mismo dominio.

    El problema se produce por el cifrado utilizado a la hora de generar los hashes de las contraseñas en la autenticación por Kerberos, debido a que:

    • Los DC con Windows Server 2003 no soportan usar AES para generar los hashes. Estos utilizan DES.
    • Los DC con Windows Server 2012 R2 no soportan usar DES para generar los hashes. Estos utilizan AES.

    Algunas de las posibles soluciones son:

    • Utilizar Windows Server 2012 para nuestros controladores de dominio, que no está afectado por el problema.
    • Desactivar el cifrado por AES en el apartado de “Tipos de cifrado soportados” en las GPO. Esto hará que los controladores de dominio usen RC4-HMAC que está soportado tanto en 2003 como en 2012 y 2012 R2.
    • Otras opciones detalladas en el artículo original.

    Mientras tanto, Microsoft ha confirmado oficialmente que están trabajando en un hotfix para el problema.

    Enlace relacionado: It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers