Problemas de replicação DFSR? Já verificou o back link? Parte 2

Artigo escrito por Roger Gnochi

Olá pessoal,

Estamos de volta conforme mencionado no episódio 1, vamos verificar agora se o caminho contrário do objeto CN=WIN12DC02,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=adatum,DC=com está “em dia”.

Os backlinks servem para fechar o apontamento tanto para um objeto válido quanto um membro de um Grupo de Replicação também válido.

Quando tratamos de um objeto Domain Controller em um grupo de replicação, devemos considerar o apontamento de seu Objeto DSA válido, que é o que veremos aqui.

Como vimos anteriormente, o Objeto Domain Controller WIN12DC02(1) é membro do Grupo de Replicação “Domain System Volume”(2) e utiliza da replicação DFS-R(3) para isso.

Como podem ver, nas propriedades do grupo, temos o atributo “msDFS-RMemberReference”. O valor deste atributo, aponta para o objeto contido em CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=adatum,DC=com

 

Mas…..para quem este objeto aponta?

A idéia desta série é mostrar os apontamentos de backlink todos “fechados” e funcionais. É muito raro encontrar um cenário onde esta seja a real causa do problema pois são informações definidas automaticamente pelo Sistema.

Existem situações onde máquinas morrem (hardware) porém ainda continuam existentes na base, sendo recriada posteriormente com o mesmo nome, porém com o objeto não reanimado, os problemas começam.

Então, pra quem o objeto em Topology aponta?

Acessando as propriedades do objeto, temos dois atributos muito importantes:

msDFSR-ComputerReference

 

Este atributo aponta para o objeto da máquina desta topologia, neste caso, um Domain Controller, e por isso então este caminho no valor

msDFSR-ServerReference

 

Este atributo aponta para o objeto DSA por se tratar de um DC.

Finalizando os apontamentos, verificamos então este caminho começando pelo Objeto WIN12DC02 em

CN=WIN12DC02,CN=SERVERS,CN=DEFAULT-FIRST-SITE-NAME,CN=SITES,CN=CONFIGURATION,DC=ADATUM,DC=COM

Notem que ele possui um atributo serverReference que aponta para o mesmo caminho válido do objeto da máquina, mantendo então este, ativo.

E por final, o próprio objeto NTDS Settings (de classe nTDSDSA, mencionado acima)

CN=NTDS Settings,CN=WIN12DC02,CN=SERVERS,CN=DEFAULT-FIRST-SITE-NAME,CN=SITES,CN=CONFIGURATION,DC=ADATUM,DC=COM

Sendo que estes atributos aqui listados, são agora totalmente voltados para a funcionalidade correta do Domain Controller e poderemos em breve discutir algum deles.

Bom, concluimos aqui então a parte 2 dos backlinks, verificando os apontamentos e como rastreá-los.

IMPORTANTE!!!

1. Vale lembrar que toda e qualquer alteração realizada no ADSIEDIT pode comprometer o seu DOMÍNIO TODO!! Não é nada comparado a uma alteração no registro onde comprometerá somente a máquina e aí você vai lá e resolve, neste caso o impacto é bem maior, por isso, não recomendamos nenhuma alteração no ADSIEDIT sem acompanhamento de um especialista ou caso você esteja seguindo um artigo que detalhe passo a passo do que está fazendo.

2. As ações listadas na parte 1 e 2 (e futura 3ª parte) podem sim, ser facilmente resolvidas removendo a máquina do domínio, despromovendo e promovendo novamente, porém a idéia é mostrar algo além de forma visual e não sugerir que ações sejam feitas direto no ADSIEDIT.

Em breve a 3ª parte finalizando este tema.

Obrigado

 

Este post faz parte das ações colaborativas do Grupo MTI:

12647017_583542658465374_5300065646273916730_n

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s