none
Movimiento de Roles entre DC bajo windows 2003 Srvr RRS feed

  • Pregunta

  • Buenos días.

    Quería compartir algo que me esta ocurriendo a fin de compartir el caso y ver si alguien más le ocurrio lo mismo.

    Teniendo una red bajo Windows 2003 con D.Activo, todo funcionando bien, decido agregar un segundo controlador de dominio aprovechando un server nuevo que llego al área.

    Realicé la instalación, updates, lo hice member server y luego lo promoví a Controlador de Dominio.

    Leyendo la documentación de Ms. sobre el tema Roles FSMO, muevo los 3 roles RID, INFrastructure y PDC Emulator al nuevo Servidor, dejando el Schema master y Domain naming master en el viejo server con la opción de ser Global Catalog.

    Resumiendo quedó de la siguiente manera

    Server Viejo

    -Schema Master

    -Domain naming master

    -Global Catalog

     

    Server nuevo

    -RID

    -Infrastructure

    -Pdc Emulator

     

     

    Hasta aquí todo bien.  Surge un tema cuando apago el Server Viejo , al dar de alta objetos nuevos en el Server nuevo , se genera una Latencia (lentitud) en el momento de utilizar la MMC para la creación de cuentas u otra modificación, lo que llama mi atención. Toma lo que ingreso, pero tarda demasiado en el momento del procedimiento.

    Una vez que levanto el Viejo server , sincronizan sin inconvenientes y se replican todos los ABM realizados.

     

    Ahora me surgen las siguientes dudas:

    - A que se debe esa lentitud al estar apagado el otro server?

    - Cual es el orden de encendido de servidores en caso de que tuviese que apagar toda la red? Que DC enciendo primero y cual luego?

    - Que ocurre si el viejo Server no funciona más? Que pasa con los roles Schema y Domain naiming? Se los puede regenerar en el nuevo server llegado el caso?

     

    Espero vuestros comentarios.

    Tengan muy buena semana!

    Saludos

    Mauricio

    lunes, 8 de noviembre de 2010 11:47

Respuestas

  • Aver que me aclare

     

    ? porque apagas un dc que tiene  2 roles principaless, sin haberlos transferido? Es algo sin ningun sentido

    Estas dejando tu red sin catalogo global? Es una practica recomendada con varios sites, hacer al dc catalogo global, para que se resuelva mas rapido la ejecucion de aplicaciones, que se encuentre donde estan los recursos

    Podemos asignar todos los roles a un mismo controlador de dominio pero dependiendo de las necesidades de nuestro entorno probablemente esto no sea lo mas adecuado, también debemos intentar que estos roles esten en maquinas lo mas estables posible ya que algunos son vitales para un correcto funcionamiento del dominio. Además también hay que tener en cuenta que no debemos asignar el rol de maestro de infraestructura a un controlador de dominio que sea a la vez global catalog a menos que todos los controladores del dominio sean global catalog ya que no actualizaría la información de objetos que no tiene lo que ocurre porque el catalogo global contiene copias parciales de todos los objetos del bosque. http://julianrv.com/blog/2005/12/descripcion-de-roles-fsmo.html

    Osea que al apagar el cg, si realizas cambios, le duelen ya que el cg tambien ha de cambiar

     

    Si se muere el dc1, en el 2 mediante ntdsutil create en el 2ª esos roles. Y borra el 1 servidor ntdsutil /metadata cleanup

    Transferir y asumir funciones fsmo http://support.microsoft.com/kb/255504/es

     

    Entendamonos el dc1 de la red, como minimo ha de ser y estar encendido. Y nunca se puede apagar: Son funciones unicas. Su ambito es el bosquo

    - Servidor de catalogo global.

    - Maestro de esquema

    - Maestro de nombres de dominio

     

    Todas tus preguntas estan resueltas en

    http://www.agapea.com/libros/Active-Directory-para-Microsoft-Windows-Server-2003-Referencia-Tecnica-isbn-8448139542-i.htm

    Salut

     

    • Marcado como respuesta Ismael Borche lunes, 22 de noviembre de 2010 14:35
    sábado, 13 de noviembre de 2010 10:40

Todas las respuestas

  • La lentitud puede deberse a varias causas. Desde cómo está configurado el orden de los DNSs en las propiedades de red, hasta que todavía esté en memoria (cacheada) la dirección del otro.
    Quizás si luego del apagado le dieras un poco de tiempo, no notarías la demora.

    El orden de encendido es indistinto, en caso que ambos estén apagados, el primero demorará mucho más tiempo porque va a buscar al otro.

    Antes de sacar un servidor deberías pasar los roles. Pero si no fuera así, siempre se puede apoderarse por la fuerza de los roles, pero no es aconsejable pues pueden producirse errores que aunque en muy pocos casos, son muy difíciles de solucionar.

    En el momento que no estén disponibles los roles dde Schema Master y Domain Master no podrías:
    - Editar el Schema
    - Agregar o quitar dominios del bosque
    Pero en el trabajo normal, no deberías detectar nada anormal.

     


    Guillermo Delprato - Buenos Aires, Argentina
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    lunes, 8 de noviembre de 2010 12:55
    Moderador
  • Hola

    Hay algún avanzo en la solucion de este problema?

    Saludo

    Ismael Borche
    jueves, 11 de noviembre de 2010 15:05
  • Hola MsecBa

    El problema de lentitud puede deberse a que en el primer servidor (viejo) estan los roles de Catalogo Global y de esquema, entonces, cuando apagas el servidor viejo, el servidor nuevo tardará un poco mas en registrar usuarios y máquinas en el dominio ya al momento de de crear el usuario nuevo, el servidor intentará replicar los cambios al servidor de catalogo global, al cumplirse el timeout de respuesta el servidor guarda los cambios y cuando encuentre el otro servidor, replicará los cambios.

    El orden de encendido es indiferente, pero mi sugerencia es que primero debes encender el servidor que tiene el rol de domain naming.

    Si el priemr servidor no funciona mas, es bueno tener una copia de seguridad del mismo ya que si se perdieran los roles que tines en este servidor, es posible que tuvieras que volver a crear y promover el dominio, y creo que esto traeria consecuencias en cuanto a aplicaciones y usuarios en la red corporativa.

    Cualquier duda me comentas...


    DIEGO FERNANDO NICOLS ARIZALA
    jueves, 11 de noviembre de 2010 16:45
  • Guillermo y Katarochi, muchas gracias por sus comentarios.

    Este fin de semana con tiempo, voy a ver más a fondo el tema y pasaré nueva información como  ser el orden de los DNS en cada server.

    Aprovecho y consulto, que ocurre si ambos server son Global Catalog? pueden coexistir en el mismo dominio? No es un práctica recomandada? porque en tal caso?

     

    Vuelvo a postear durante estos días, gracias una vez más!

    Saludos

    MAuricio

    viernes, 12 de noviembre de 2010 18:47
  • Es una práctica recomendada tener más de un Catálogo Global.

    La función Catálogo Global, no es una función del tipo "Maestro de ...", o sea no es un "FSMO Rol" que cumple sólo un equipo.

    El Catálogo Global, se utiliza para búsquedas en el AD, y lo más importante es que es necesario para el inicio de sesión de los usuarios normales, ya que es el que informa la pertenencia a Grupos Universales, y además resuelve el UPN.

    Si cuando un usuario normal inicia sesión, no se puediera contactar a un Catalogo Global, el mismo no podrá iniciar sesión.

    Luego, tienes que asegurarte que exista tolerancia a fallas sobre el Catálogo Global.

    Si tienes un único dominio, es recomendable que todos los controladores de dominio sean Catálogo Global.

     


    Guillermo Delprato - Buenos Aires, Argentina
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    sábado, 13 de noviembre de 2010 10:28
    Moderador
  • Aver que me aclare

     

    ? porque apagas un dc que tiene  2 roles principaless, sin haberlos transferido? Es algo sin ningun sentido

    Estas dejando tu red sin catalogo global? Es una practica recomendada con varios sites, hacer al dc catalogo global, para que se resuelva mas rapido la ejecucion de aplicaciones, que se encuentre donde estan los recursos

    Podemos asignar todos los roles a un mismo controlador de dominio pero dependiendo de las necesidades de nuestro entorno probablemente esto no sea lo mas adecuado, también debemos intentar que estos roles esten en maquinas lo mas estables posible ya que algunos son vitales para un correcto funcionamiento del dominio. Además también hay que tener en cuenta que no debemos asignar el rol de maestro de infraestructura a un controlador de dominio que sea a la vez global catalog a menos que todos los controladores del dominio sean global catalog ya que no actualizaría la información de objetos que no tiene lo que ocurre porque el catalogo global contiene copias parciales de todos los objetos del bosque. http://julianrv.com/blog/2005/12/descripcion-de-roles-fsmo.html

    Osea que al apagar el cg, si realizas cambios, le duelen ya que el cg tambien ha de cambiar

     

    Si se muere el dc1, en el 2 mediante ntdsutil create en el 2ª esos roles. Y borra el 1 servidor ntdsutil /metadata cleanup

    Transferir y asumir funciones fsmo http://support.microsoft.com/kb/255504/es

     

    Entendamonos el dc1 de la red, como minimo ha de ser y estar encendido. Y nunca se puede apagar: Son funciones unicas. Su ambito es el bosquo

    - Servidor de catalogo global.

    - Maestro de esquema

    - Maestro de nombres de dominio

     

    Todas tus preguntas estan resueltas en

    http://www.agapea.com/libros/Active-Directory-para-Microsoft-Windows-Server-2003-Referencia-Tecnica-isbn-8448139542-i.htm

    Salut

     

    • Marcado como respuesta Ismael Borche lunes, 22 de noviembre de 2010 14:35
    sábado, 13 de noviembre de 2010 10:40
  • Hola MSecBa

    Hay alguna actualización de este tema?

    Saludos


    Ismael Borche
    jueves, 18 de noviembre de 2010 19:03