Hola
Algunos enlaces a información sobre temas que suelen surgir frecuentemente:
Otro día escribiremos algo más elaborado.
Saludos
David Cervigón
Como cualquier almacén de datos, el Directorio Activo puede convertirse en un lugar poco recomendable donde acumular toda clase de roña, sobre todo si las operaciones que se llevan a cabo sobre el mismo se descuidan.
Agregar objetos es particularmente sencillo, y esto es precisamente la base de su diseño y su funcionalidad para hacer posible que muchos productos se apoyen en su capacidad de servir todo tipo de información. Sin embargo la eliminación de lo que ya no nos sirve es algo que en ocasiones se deja para luego o se hace de aquella manera. A mayor complejidad de la arquitectura del AD en lo tocante a numero de Dominios, Sites y controladores de dominio, más pueden acentuarse este tipo de problemas y mayor será la necesidad de definir y respetar una buena guía de operaciones para el Directorio Activo.
Lo complicado en este punto es definir que es lo que entendemos por roña. En este post nos vamos a centrar en tres tipos:
1.- Identificar cuentas de usuario y equipos en desuso
Las cuentas de usuario/servicios deberían borrarse en el momento de que el usuario o aplicación que las ha estado utilizando no la necesiten más. Igualmente la cuentas de las máquinas debería hacerse desaparecer sacando al equipo del dominio antes de proceder a reconfigurarlo/reinstalarlo/eliminarlo. Sin embargo las prisas hacen que esto se deje demasiado a menudo para luego, y que llegue el momento de preocuparse cuantos de mis miles de objetos de usuario/equipo solo están ocupando espacio y haciendo al AD más gordito y pesadote.
Salvo que a alguien se le ocurra algo mejor, lo que se suele utilizar para detectar estos objetos olvidados es buscar un atributo que sepamos que haya cambiado seguro la última vez que el usuario/equipo las utilizaron y que no cambie salvo que sea vuelto a utilizar. Esto sucede cada vez que un alguien (usuario o equipo) inicia sesión. En ese momento el controlador de dominio encargado de llevar a cabo la operación de autenticación actualiza un par de atributos de la cuenta en particular con la fecha y la hora en la que se ha iniciado sesión. Si lo que queremos es hacer una operación de borrado masiva de este tipo de roña, deberemos establecer una fecha límite a partir de la cual, todo objeto que no haya iniciado sesión será considerado en desuso. El último inicio de sesión se almacena en dos atributos presentes tanto en la cuentas de usuarios como de los equipos: LastLogonTimeStamp y LastLogon.
El valor de estos atributos almacena los tiempos en un tipo de dato especial llamado Integer8, que almacena el número de intervalos de 100 nanosegundos desde el 1 de enero de 1601. Para realizar la conversión de una fecha/hora a este formato es conveniente tener a mano herramientas como esta. El paso contrario es sencillo, pues basta con usar w32time /ntte.
Veamos como podemos sacar fácilmente esta información:
Si buscáis por Internet sobre estos atributos, obtendreis un montón de referencias a scripts basados en VBS, powershell, etc que hacen esto mismo
2.- Dominios / Controladores de Dominio perdidos en combate
Esto sucede cuando no se ha utilizado DCPROMO para eliminar los DCs de un dominio, y en el caso de los dominios cuando hemos olvidado la graciosa casilla “este es el ultimo DC del dominio”. Es decir, apagar DCs y borrar ramas del DNS no es ni mucho menos equivalente a eliminar dominios del AD:
El proceso de eliminar del AD este tipo de objetos huérfanos se llama Metadata Cleanup, y suele incluir también un proceso de “seize” de los roles que tuvieran los DCs perdidos y que no han sido reasignados. Los paso a seguir están bien documentados en estos dos artículos de la Knowledge Base:
3.- Lingering Objects
Lo cierto es que a mi este nombre siempre me ha hecho gracia, ya que dando una enorme patada al diccionario de la lengua de Shakespeare, lo de los “objetos en paños menores” representa bien lo que son. Cuando borramos un objeto, por ejemplo como hemos hecho en el primer punto, no desaparece realmente de la base de datos sino que se le pone a TRUE el valor de su atributo IsDeteled, lo que se conoce como ponerle un tombstone. Los objetos así marcados serán borrados cada cierto tiempo (60 días en 2000 y 2003, o 180 días en 2003 SP1) mediante un proceso que hace las veces de camión de la basura (“garbage collection"). Pues bien, supongamos que hemos tenido un controlador de dominio parado o sin replicar por algún tipo de problema durante más tiempo que lo definido en el “Tombstone Lifetime”. Pues bien, en ese DC, los objetos borrados y eliminados están más frescos que una rosa, y se quedan en ahí, en paños menores, ya que el resto de DCs no quieren saber nada de ellos. dado que el camión de la basura ya pasó, no queda más remedio que llevarlos personalmente al vertedero:
Todo esto así contado parece fácil de entender, pero en el fondo no lo es tanto ya que la forma en la que replica el Directorio Activo tiene su aquel. Así es que nunca está de más tener a mano la información de How the Active Directory Replication Model Works.
Agradecimientos especiales a mis compañeros del grupo de soporte de Directorio Activo, quienes estarán encantados de responder a todas vuestras preguntas a través de su blog, que me ayudaron a acotar lo que podía caer bajo la categoría de “roña” en AD, y en especial a Javier Rama que encima tuvo la paciencia de ponerlo por escrito. En su correo me decía que tenía la sensación de que se nos olvidaba algo, y yo de hecho estoy seguro de que si (de hecho, no hemos hablado nada de NTFRS ni de sus colisiones, grupos vacíos, objetos de políticas de grupo…).
¿Que más roña te has encontrado tu en un AD?
Hola de nuevo
Tras un par de semanas en las que he tenido el blog hibernando, vamos a aprovechar la llegada de la primavera con un post sencillito sobre algunos anuncios que se me han ido acumulando entre el ajetreo diario y algunos días de asueto en el prado de la cabecera de esta página:
Y por último en el apartado de destacados, el Evento Virtualización Inteligente que tendrá lugar en Madrid y Barcelona los días 31 de Marzo y 2 de Abril respectivamente. Intel, Microsoft, HP, Dell, Sun, Fujitsu-Siemens, Quest, Citrix y NetApp todos juntos y revueltos mágicamente para hablar de virtualización en un evento de mañana y tarde.
O lo que es lo mismo, cómo evitar que dos máquinas virtuales coincidan en el mismo nodo de un cluster. Esto puede tener ciertas aplicaciones para aumentar la alta disponibilidad y la tolerancia a fallos de lo que quiera que sea que este corriendo por encima. Por ejemplo:
Esto obviamente se puede hacer solo si tenemos más de dos nodos en el cluster, y generalmente se logra mediante la configuración de los “Possible Owners” del grupo. A mayor número de nodos, más podemos confiar en que de este modo disminuya la probabilidad de que ciertos grupos coincidan en el mismo host.
Si queremos un mayor grado de control podemos usar una propiedad pública que puede tener todo grupo de cluster llamada AntiAffinityClasNames. Dicha propiedad puede almacenar un cierto numero de cadenas de caracteres que actúan a modo de etiquetas de modo que si en ese nodo está corriendo un grupo con una etiqueta coincidente, pasaremos al siguiente “possible owner”. Se especifica mediante este simple comando:
Siguiendo los ejemplos anteriores supongamos que en un cluster tenemos dos VMs que son dos controladores de dominio, que están definidas en dos grupos de cluster llamados DC1 y DC2. Además, DC2 es también a su vez un nodo de un cluster virtual de tres nodos, nodo1, nodo2 y DC2 (estupenda mala idea, pero si no no me sale el ejemplo). Entonces:
De este modo, DC1 y DC2 evitarán coincidir porque tienen "NoAjuntoAOtroDC" y nodo1, nodo2 y DC2 también se evitarán porque tienen ”NoAjuntoAOtroNodo”.
Es importante mencionar que aquí la palabra evitar no significa una prohibición total. Es decir, en caso de ser necesario, en última instancia los grupos pueden acabar por levantarse en el mismo nodo. Basta con probarlo en un cluster con solo dos nodos. La propiedad no evita el failover en ningún caso al no existir mas posibles propietarios que el único nodo que queda vivo.
La descripción exacta del comportamiento del sistema de failover, un artículo un poco más extenso sobre todo esto, y la descripción de la propiedad AntiAffinityClasNames se pueden encontrar en estos enlaces:
Como reza el título, esto vale para cualquier tipo de grupo de recursos de cluster, y no solamente para VMs en HA. Huelga decir que estamos hablando de tolerancia a fallos. Los movimientos de maquinas virtuales entre nodos, manuales o automáticos, pueden llegar a tener una riqueza en su control mucho más fina.
Elemental. Al igual que es evidente que una instantánea no es igual que una instantánea, no sea que alguien me riña por usar los anglicismos.
Cuando se habla de hacer copias de seguridad de máquinas virtuales surgen técnicas y métodos para todos los gustos, y el problema es que a dos de ellas se les da desafortunadamente el mismo nombre. Vamos a ver algunas opciones:
Una buena estrategia de recuperación de desastres debe pasar por una combinación de los puntos 3 (automatizado), 4 y 5, dejando los 1, 2 y 3 (manual) para pruebas sin importancia e informática recreativa.
Ya hablaremos más en detalle de como usar Virtual Machine Manager y sobre todo Data Protection Manager para todo esto, sin ser desde luego los únicos productos del mercado que lo hacen. Mientras tanto, algunas lecturas interesantes al respecto:
Llevo toda la semana de acá para allá y en los ratos libres he estado dando una vuelta a la configuración de mis máquinas de trabajo, aprovechando el cambio de una de ellas. Desde Octubre he estado utilizando equipos prestados para una u otra cosa, y durante este tiempo me he dado cuenta de que necesitaba cambiar un poco la forma de trabajar y aplicarme un poco el cuento de la virtuazación y el “cloud computing”. En mi caso Microsoft tiene a bien dotar la posición que ocupo con dos equipos, uno pensado para trabajar y otro para pruebas y demos. El cómo se utilicen finalmente esas máquinas, es asunto de cada uno.
Había estado usando un equipo portátil grandote (17” y 8GB) como estación de trabajo y a la vez para correr la miríada de VMs que necesito en mi día a día. Es una estrategia útil, pero:
Viendo por donde vienen los tiros a corto plazo, he decidido trabajar de la siguiente manera:
De esta manera, en “modo demo” cuento con un dominio virtual basado en dos hosts físicos con Hyper-V, capaces de correr lo que quepa que 12 Gb, dos discos SATA internos y dos o tres discos USB externos. Mientras me dedico a otros menesteres, disfruto de Windows 7 mientras que el otro equipo es capaz de mover todo lo que 8Gb, un SATA interno y varios USB externos son capaces de albergar.
Cuando se vaya acercando el lanzamiento de las versiones finales de Windows 7 y Windows Server 2008 R2 / Hyper-V Server R2 esta aproximación seguramente evolucionará. Tengo pendiente contar un poco más de lo que cuenta Cesar acerca del arranque de VHD que soportan estas versiones, y de las posibilidades que esto ofrece, y de alguna otra cosa más que ya contaremos.