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: