Solucionando Problemas: Journal Wrap - Event ID 13568 (pt-BR)

Artigo
17/01/2024

Entendendo o que é USN Journal

O sistema de arquivos NTFS contém um recurso de gerenciamento do sistema que faz o acompanhamento de cada mudança em arquivos e pastas no volume. Ele armazena essas alterações em um log e funciona de forma cíclica, ou seja, quando esse log alcança seu tamanho máximo, o registro de alteração mais antigo é substituído por um mais novo.
Existe uma ‘tabela’ com essas alterações para cada volume.
Para ficar mais fácil, podemos traduzir a palavra ‘Journal’ com a palavra ‘Diário’.

O USN Journal (Update Sequence Number Journal) é o log que armazena essas alterações, e ele funciona de forma bem simples: cada alteração realizada em pastas ou arquivos é adicionada nesse log, sendo que esse registro de alteração é identificado por um USN de 64-bit.
O log possui a seguinte estrutura: o USN, o nome do arquivo, e a informação sobre a alteração realizada.
O USN Journal não armazena o conteúdo alterado de cada arquivo ou pasta, mas sim o tipo de mudança que foi realizada.
O USN Journal pode ser trabalhado com o comando ‘fsutil usn <parâmetros>’

Como o FRS utiliza e trabalha com o USN Journal

File Replication Service (FRS) é a tecnologia responsável pela replicação de arquivos e pastas armazenadas na pasta compartilhada Sysvol em Domain Controllers, além de trabalhar também com DFS.
O FRS também possui sua própria database, sendo que usa o USN Journal para monitorar mudanças feitas na ‘replica tree’.

Se há uma mudança em um arquivo, o seguinte processo ocorre:
    a. É adicionada uma entrada no USN Journal
    b. O FRS (que monitora o USN Journal) nota que houve uma mudança no arquivo ou pasta
    c. O FRS compara o valor de sua database com o do USN Journal, notando que o arquivo/pasta foi atualizado e precisa ser replicado
    d. O arquivo sofre o processo padrão de replicação: staging, replicating, etc.
    e. O FRS marca em sua database aquele USN como ‘processado’.

Um exemplo prático:
    a. O arquivo ‘teste.txt’ é modificado.
    b. FRS nota a mudança no USN Journal e baseado em seu database percebe que não foi processada a replicação.
    c. O arquivo/pasta sofre o processo de staging, replicating
    d. O FRS atualiza o database para refletir essa mudança do USN Journal.

Para os amantes da dificuldade, segue todo o processo:

Como acontece o Journal Wrap

Após bastante conceito vamos para o prático. Como acontece o Journal Wrap?
O Journal Wrap ocorre quando o FRS por algum motivo não está monitorando o USN Journal, e ocorre tantas mudanças em arquivos e pastas de forma que o USN Journal (que tem um log cíclico) apaga informações ainda não armazenadas no database do FRS, que por sua vez reclama a falta desses dados.
Nessa hora, o valor do registro ‘SysvolReady’ (HKLM\System\CurrentControlSet\Services\Netlogon\Parameters) é alterado para ’1′, avisando o Netlogon que algo está errado, e fazendo com que a Sysvol não seja mais compartilhada. O servidor entra no estado ‘Journal Wrap’.

Os eventos 13568 e 13569 podem ser encontrados no Event Viewer, nos logs do FRS.

Um exemplo prático:
    a. Um arquivo é alterado e o USN Journal vai para #3
    b. O FRS faz o procedimento normal e realiza a replicação.
    c. Supondo agora que o tamanho máximo do nosso USN Journal como 10 entradas.
    c. O FRS service é parado, e o USN Journal é alterado mais algumas vezes, ficando com #28 (lembrando que o arquivo é cíclico, logo tivemos sobreposição de informação)
    d. Como nosso USN Journal possui tamanho máximo de 10, quando o FRS volta ele nota a falta das informações entre #3 (que foi o último que ele processou) até #18 (28 – 10 entradas que ele suporta).

Resolvendo o Journal Wrap

A parte fácil: resolver o Journal Wrap.
Agora não tem mais conversa, vamos resolver o problema.
Para conseguirmos resolver o problema de Journal Wrap, precisamos basicamente resetar a database do FRS e iniciar a contagem do USN Journal a partir de onde ele está.
Para fazer isso podemos utilizar uma excelente documentação da MS, um procedimento conhecido como "Burflags" ou D2D4:

Pare o serviço de FRS dos servidores em questão.
Chave: HKLM\System\CurrentControlSet\Services\NTFRS\Parameters\Cumulative Replica Set\GUID]
Valor: "Burflags"
D2 – Setando esse valor estamos dizendo que esse servidor não é autoritativo para o FRS, sendo assim ele irá copiar toda a Sysvol de seu parceiro, fazendo uma ‘full replication’.
D4 – Setando esse valor estamos dizendo que esse servidor é autoritativo para o restore de FRS.

Por exemplo temos o DC01, DC02 e DC03. Infelizmente o DC02 entrou em ‘Journal Wrap’ pois o serviço FRS ficou parado muito tempo!
Para resolver, seguimos os passos:
    a. Paramos o NTFRS service no DC02 e DC03.
    b. Definimos na chave Burflag do DC03 o valor ‘D4′ (eu mando)
    c. Definimos na chave Burflag do DC02 o valor ‘D2′ (eu obedeço)
    d. Iniciamos o serviço NTFRS no DC03 e aguardamos pelo evento 13516 (ok, estou pronto!)
    e. Iniciamos o serviço NTFRS no DC02 e aguardamos pelo evento 13516 (ok, peguei os dados e estou sadio!)

**
Importante: os conectores de replicação precisam estar sadios também! Garanta que a replicação do AD está funcionando antes de seguir os passos mencionados.**

Referências:

http://blogs.technet.com/instan/archive/2009/07/14/what-happens-in-a-journal-wrap.aspx
http://support.microsoft.com/kb/221111/en-us
http://support.microsoft.com/kb/290762/en-us
http://technet.microsoft.com/pt-br/library/cc781134(WS.10).aspx
http://en.wikipedia.org/wiki/USN_Journal
http://technet.microsoft.com/en-us/library/cc758169(WS.10).aspx
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_usn.mspx?mfr=true
http://support.microsoft.com/kb/292438/en-us
http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx

Compartilhar via