Início > Active Directory, Directory Services, DNS, Sites and Services, Windows Server, Windows Server 2003/R2, Windows Server 2008/R2 > Replicando alterações no serviço de diretório para servidores intrasite e intersite

Replicando alterações no serviço de diretório para servidores intrasite e intersite

maio 4, 2014

Olá pessoal,

Hoje eu vou escrever um pouco sobre um processo muito importante quando falamos de Directory Services, a replicação de objetos no AD DS, partições do DNS quando integrado ao AD DS, etc.

O processo de replicação de objetos e partições no AD DS é um detalhe de extrema importância em um infraestrutura de serviço de diretório e que merece muita atenção e constante monitoramento para garantir a saúde de seus servidores.

Nâo irei falar sobre o monitoramento deste recurso que é feito com ferramentas como repadmin, repmon, dcdiag, nltest, pois o objetivo deste post é mostrar como efetuar a replicação de objetos no caso de ser necessário refletir uma alteração, adição ou remoção de objetos no serviço de diretório.

Em média e grandes empresas é normal encontrarmos ambientes onde existem diversos controladores de domínio/DNS para permitir alta disponibilidade e otimização de acesso ao serviço de diretório, seja no mesmo site ou em sites remotos.

É uma tarefa comum realizar a criação de objetos como contas de usuários/serviços, grupos, inclusão/exclusão de usuários em grupos, etc.

Também é comum encontrarmos situações onde precisamos criar um objeto e que ele esteja disponível imediatamente para ser utilizado, por exemplo, uma conta de serviço.

Mas o que ocorre se você possuir controladores de domínio em sites distintos e presumindo que foi feito um design adequado do serviço de diretório, separados por sites lógicos e subredes no Active Directory Sites and Services?

Caso você possua um Site1 onde o servidor A está logicamente localizado e um Site2 onde o servidor B está localizado, ao criar um objeto no servidor A, este objeto não estará disponível no servidor B até que o próximo ciclo de replicação intersite seja feita.

Esse processo pode não ser um problema quando estamos falando de replicação intrasite, pois por padrão a cada 15 segundos após uma ação como alteração/criação/remoção de um objeto, desde que está ação não seja nenhum prevista para gerar uma replicação urgente tal como bloqueio/desbloqueio de contas, troca de senhas, etc., o controlador de domínio onde a ação ocorreu notifica seus parceiros de que existe algo novo e então seus parceiros solicitam esta alteração.

No caso da replicação intersite, esse tempo pode ser muito maior, pois este periodo de tempo é definido no momento em que você cria um Site Link no container Inter-Site Transport e que por padrão, possui o valor de 180 minutos ou 3 horas de intervalo.

O que fazer então para forçar uma alteração feita no servidor A no Site1 para que a mesma seja replicada imediatamente para o servidor B no Site2?

A primeira coisa a se fazer é descobrir em qual controlador de domínio você realizou a alteração e isto pode ser feito facilmente através do console Active Directory User and Computers como mostrado na imagem abaixo:

Current Domain Controller

Current Domain Controller

Após identificar o nome do controlador de domínio, o que precisa ser feito é executar dois comandos para que a replicação intrasite seja feita para todos os parceiros no site e em seguida para todos os sites (intersite).

Abra o Commando Prompt elevando os privilégio como Administrador e execute o comando repadmin /syncall DCName /djQSA para iniciar a replicação intrasite como mostrado abaixo:

Start IntraSite Replication

Start IntraSite Replication

Após a conclusão do comando anterior, execute o comando repadmin /syncall DCName /edQSA para iniciar a replicação intersite como mostrado abaixo:

Start InterSite Replication

Start InterSite Replication

Apenas para entendermos a diferença entre os dois comandos, o switch “j” presente no primeiro comando informa que a sincronização deve ser feita apenas para os servidores do mesmo site (intrasite) e o switch “e” do segundo comando informa que a replicação deve ser feito para todos os sites com os quais o site onde o controlador de domínio possui uma conexão lógica através do Site Link.

Para maiores informações sobre todos os switches disponíveis para o comando repadmin /syncall, eu sugiro que você execute o help ou repadmin /syncall /?.

Após efetuar a primeira replicação, minha sugestão é que você também execute o mesmo, mas em ordem inversa no servidor que faz o papel de BridgeHead no site onde a alteração precisa ser refletida.

Neste momento, você pode estar se perguntando: mas como eu sei quem é o servidor que está como BridgeHead em cada site? Simples meu amigo! Abra o console Active Directory Sites and Services, expanda o container Sites > Inter-Site Transport > IP, clique com o botão direito sobre o container IP, escolha Properties e selecione a guia Attribute Editor.

Na parte inferior direita da janela clique em Filter e em seguida marque a opção Backlinks como mostrado na imagem abaixo:

Show BackLinks Attributes

Show BackLinks Attributes

Veja que alguns atributos passaram a ser exibidos na janela, como por exemplo, o atributo bridgeheadServerListBL que irá listar todos os BridgeHead em todos os sites existentes em nossa infraestrutura de serviço de diretório. Selecione com um clique o atributo bridgeheadServerListBL e em seguida clique no botão View na parte inferior esquerda da janela.

Como podemos ver na imagem abaixo, existem 2 sites chamados LATAM e NAM e para cada um deles, existe um BridgeHead Server:

Viewing BridgeHead Servers

Viewing BridgeHead Servers

Seguindo o nosso exemplo, a alteração do objeto foi feita no servidor NYC-DC1 que pertence ao site LATAM e também é o BridgeHead para este site.

Vamos supor que uma conta de serviço tenha sido criada ou um registro DNS tenha sido alterado no site LATAM e você precisa que esta alteração seja refletida imediatamente no site NAM. Como a replicação intersite é feita através dos servidores que desempenham o papel de BridgeHead, você pode reduzir o tempo para que esta alteração seja replicada para o site NAM executando os comandos abaixo para o servidor NYC-DC2 que é nosso BridgeHead para este site.

Então o que precisa fazer a partir do servidor NYC-DC1, caso você esteja conectado ao mesmo é executar o comando repadmin /syncall NYC-DC2 /edQSA para que ele solicite ao BridgeHead (NYC-DC1) do site LATAM todas as alterações que ele possui e também para que o BridgeHead (NYC-DC2) do site NAM envie todas as suas alterações para o site LATAM, sincronizando todos os objetos.

Start InterSite Replication from Destination Site

Start InterSite Replication from Destination Site

Após concluir o comando anterior, você deverá executar o comando repadmin /syncall NYC-DC2 /djQSA para que o mesmo informe a todos os servidores no site NAM que ele possui uma nova informação para que a mesma seja replicada (intrasite) e sincronizada entre todos os controladores de domínio.

Start IntraSite Replication in Destination Site

Start IntraSite Replication in Destination Site

Após executar estes passos, verifique se o objeto alterado/criado/removido no site LATAM foi replicado para o site NAM.

Pode parecer um tanto trivial o procedimento, mas em grandes ambientes este tipo de ação pode ser muito útil. Uma situação muito comum e que normalmente envolve este tipo de ação é um teste de contingencia onde é necessário alterar os recursos acessado do site de produção para o site de contigencia através da alteração de alias no DNS.

Bem pessoal, é isto. Espero que aproveitem a informação e que tenha sido proveitosa para o dia a dia de vocês que trabalho com Directory Services.

Até mais…

%d blogueiros gostam disto: