Problemas com DFSR - Não Replica

Dia desses consegui um problema FDP. Simplesmente os servidores de arquivo não estavam mais realizando a sincronização entre as pastas compartilhadas. O meu ambiente estava configurado da seguinte forma: 2 servidores de arquivo, executando "NAMESPACE"  e "Replicação DFS", nomeados a partir de agora de fs1 e fs2. Nestes servidores tenho vários "GRUPOS DE REPLICAÇÃO".

Meu problema era seguinte: apenas um "GRUPO DE REPLICAÇÃO" não funcionava e o mais estranho, apenas em uma via, ou seja, quando fazia a alteração no fs2 ela era replicada imediatamente para o fs1, mas o contrário não acontecia.

Realizei os seguintes passos:

1 - Chequei a topologia. OK, estava tudo conectado e pronto para replicação;

2 - Criei um "Relatório de Diagnóstico" para verificar obtive um erro;

3 - De olho no "Event Viewer" observei vários eventos 4304* (Violação de Compartilhamento);


4 - Como tive alguns problemas com o Symantec Backup Exec e Replicaçaõ DFSR, minha primeira tentiva foi "PARAR" o "Agente do Backup Exec". Em seguinda reiniciei o "Serviço de Replicação". Nada aconteceu;

5 - Próximo, sincronizei os horários dos "Servidores de Arquivos" com o "Controlador de Dóminio". Nada;

6 - Parei o serviço de Anti-Vírus. NADA.

7 - Nesse ponto, precisa realmente saber o que estava acontecendo, ou seja, monitorar a "Replicação DFS". Fui para Internet e encontrei um programa chamado DfsrMon (no site tem um How to), e através dele consegui descobir que "Backlog" do fs1 para o fs2 estava com mais de 10000 versões sem atualização, ou seja, havia mais de 10000 arquivos para serem replicados.

8 - Neste ponto, eu precisava saber quais eram estes arquivos. Com algumas pesquisas descobri que existe o cmdlet dfsrdiag, um "irmão" do dcdiag. Com um simples leitura no Help dele no próprio CMD, consegui executar os comandos abaixo que me ajudaram na tarefa de saber quais arquivos estavam "entupindo" a replciação.

8.1 - Verifica o backlog da Pasta replicada entre o SenderServer e ReceiverServer
dfsrdiag backlog /SendingMember:fs1 /ReceivingMember:fs2 /RGName:Deptos /RFName:"Deptos" /v

8.2 - Verifica arquivos que esão sendo "baixados" e arquivos que estão na "lista de espera"
dfsrdiag replicationstate /Member:fs1 /V

9 - Quando executei o arquivos acima percebi que havia uma série de arquivos *.mp3; *.wav, etc aguardando o envio. Neste momento liguei os pontos. Como havia configurado "COTA" e "TRIAGEM" para os arquivos, poderia ser este o problema.

10 - Chequei todas as "COTAS" e incrementei as que estavam "penduradas".

11 - Marquei a "Triagem de Arquivos" para tipo "PASSIVO" (apenas avisa, mas não bloqueia).

12 - Executei o comando para visuarlizar a lista de arquivos "presos" mencionado acima no CMD e percebi nas primeira linhas que alguns deles estava com o sufixo ("Baixando").

13 - Através da Ferramenta DfsrMon, pude confirmar que o "BackLog" começou a baixar rapidamente. UFA.

14 - De olho os Logs do "Event Viewer" recebi mais um evento diferente (4202). Esse evento comunicava algo relacionado com "Espaço de Preparação está acima da marca d´água alta". Como havia pesquisado muita coisa antes, este problema foi fácil de resolver.

14.1  - Na ferramenta "Gerenciamento DFS" no grupo "Replicação", marque o "Grupo de Replicação" com problema e navegue para a ABA "Associações" no painel central. Você irá visualizar uma tal de "Cota de Preparação". É este "cara" que deve ser alerado. Clique com o botão da diretita sobre a "Pasta Replicada" e escolha "Propriedades". Vá para aba "Preparação" e incremente um pouco mais a "Cota". No meu caso aumentei de 4GB para 6GB.

Até a próxima.

* Em pesquisas realizadas, descobri que este evento ocorre quando se tem um número muito grande de "alterações" nos arquivos e estas alterações não têm tempo suficiente para serem replicadas.

Servidor de Horário Windows

Para anunciar um servidor DC como "Servidor de Horário" e apontar o ntpclient para algum servidor externo ou interno, digite o seguinte comando:

w32tm /config /manualpeerlist:<nome_servidor_ntp> /syncfromflags:manual /reliable:yes /update

Resolvi um problema de "Advertising" no Windows 2008 R2 com relação ao "Servidor de Horário" quando executada o dcdiag.

Problemas de Replicação - SYSVOL Corrompido

Tive um problema de repliação entre os DCs muito estranho. Mesmo executando o dcdiag /test:replications, dcdiag /test:conectivity e o repadmin /showrepl mostrando OK/SUCESSO durante os testes, no Event Viewer do Windows apareciam LOGs informado que a pasta SYSVOL estava corrompida (SYSVOL Formatado, Serviço de replicação não iniciado, Impossível resolver nome dc2.empresa.com, etc). Esse erro nos LOGs aparecia todas as vezes que o Serviço NTFSR era reiniciado.

Mais um vez segui alguns procedimentos que resolveram o problema. Vamos lá:

1) Carregue o regedit;

2) Navegue até a HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters;

3) Adicione a entrada "Enable Journal Wrap Automatic Restore" do tipo REG_DWORD com valor 1. Esta entrada ativa exclusão dos arquivos dos SYSVOL e força uma nova replicação;

4) Reinicie o serviço NTFrs (Serviço de Replicação de Arquivos);

5) Acompanhe os LOGs pelo "Event Viewer", irão aparecer alguns "warnings", e pelo comando NETSHARE o recompartilhamento automático da pasta SYSVOL.

Assim que a replicação foi concluída, automaticamente a compartilhamento SYSVOL foi recriado.
Para confirmar a resolução, limpei os LOGs e reiniciei o serviço NtFsr. Pelos LOGs foi possível constatar que o problema foi resolvido.

ERRO em Compartilhamento com CNAME

Criei uma entrada no DNS do tipo CNAME apontando para o servidor de Arquivo. Quando tentei acessar o compartilhamento via Windows Explorer ocorria um erro de "Nome duplicado de REDE". A partir deste ponto, realizei uma série de testes. Conseguia "PINGAR" no FQDN do servidor e também no "CNAME", porém conseguia acessar o compartilhamento somente via FQDN.

Em uma busca pela Internet, encontrei que isso é um problema conhecido e para resolver este problema, realizei os seguintes procedimentos, no servidor apontadado pela entrada CNAME.

1) Carregue o REGEDIT
2) Navegue até a chave "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters"
3) Crie a "ENTRADA" com o nome de "DisableStrictNameChecking" do tipo "REG_DWORD" com valor Decimal "1".

Após estas configurações, temos que reiniciar o servidor.

Caso as configurações não funcionem, podemos tentar adicionar SPN (Service Principal Names) para o CNAME recém criado. Para isso:

1) Abra o CMD
2) Digite "setspn -a host/<cname> <nome_servidor>", confirme com "ENTER"
3) Digite "setspn -a host/<cname>.<dominio> <nome_servidor>", confirme com "ENTER"

Essas configurações resolveram meus problemas.