FRS não replicando C: \ WINDOWS \ SYSVOL \ domain \ scripts após a restauração não autorizada

Question

Estamos executando vários controladores de domínio do Windows Server 2008 R2. A replicação do sysvol é feita pelo NTFRS.

Ontem, nosso controlador mestre relatou um "JRNL_WRAP_ERROR" para o compartilhamento SYSVOL. Eu corri um chkdsk em C: \ mas não mostrou nenhum problema. Depois disso, iniciei uma restauração não autoritativa interrompendo o ntfrs.exe, definindo o BurFlags como "D2" em HKLM / SYSTEM / CurrentControlSet / services / Ntfrs / Parâmetros / Backup \ Restore / Process na inicialização e reiniciar o ntrfs.exe novamente.

Embora isso pareça funcionar para C: \ WINDOWS \ SYSVOL \ domínio \ Políticas , por algum motivo ele não extrai C: \ Windows \ Sysvol \ domain \ scripts dos outros DCs. A pasta de scripts possui alguns diretórios após a restauração não autoritativa e, de fato, esses devem estar lá. No entanto, ele não contém todos eles e os que ele contém são incompletos.

Também renomei C: \ Windows \ ntrfs \ jet e iniciei a restauração não autorizada novamente para descartar problemas relacionados ao cache, mas isso também não resultou em nenhum sucesso.

Depois de reiniciar a restauração não autoritativa, também notei que o diretório de scripts estranhamente não aparecia em C: \ Windows \ SYSVOL \ domínio \ NtFrs_PreExisting

windows windows-server-2008 sysvol file-replication-services

por Albert 14.11.2013 / 13:23

Answer 1

O problema aconteceu novamente em outro DC. Acontece que alguns arquivos estavam na pasta C: \ Windows \ Sysvol \ domain \ scripts - alguns arquivos exe em execução. NTFRs.exe não pôde concluir sua tarefa.

ntrfsutl foi útil para depurar este problema. O link é certamente útil. Eu usei ntrfsutl inlog para ver o estado dos arquivos sendo transferidos. No meu caso, a pasta de scripts estava no estado IBCO_INSTALL_REN_RETRY o tempo todo. Em seguida, localizei todos os arquivos que continham bloqueios no diretório de script (e em seus subdiretórios). Esses foram alguns programas que também estavam sendo executados em computadores clientes (mas abertos no compartilhamento NETLOGON).

Você pode usar o handles.exe da SysInternal Tools para identificar identificadores de arquivos abertos. No meu caso, alguns arquivos foram abertos pelo processo "System". Na verdade, eles foram abertos no compartilhamento de rede por computadores clientes. Eu fechei a alça via compmgmt.msc.

Depois que todas as alças abertas foram fechadas, a replicação finalmente foi bem-sucedida.