O FRS acrescenta "_NTFRS_<xxxxxxxxx>" a nomes de pastas
Este artigo ajuda você a corrigir um problema no qual o FRS (Serviço de Replicação de Arquivos) adiciona "_NTFRS_<xxxxxxx>" a nomes de pastas.
Aplica-se a: Windows Server 2012 R2, Windows Server 2016
Número de KB original: 328492
Sintomas
Quando você cria uma pasta replicada pelo FRS (Serviço de Replicação de Arquivos), o FRS acrescenta "_NTFRS_<xxxxxxxx>" ao nome da pasta.
Observação
Neste exemplo, <xxxxxxxxx> representa oito dígitos hexadecimal aleatórios.
A tabela a seguir mostra como o FRS pode alterar os nomes de duas pastas.
Nome da pasta original | Novo nome da pasta |
---|---|
07/29/2002 09:58a Policies |
07/29/2002 09:58a Policies_NTFRS_000add30 |
07/29/2002 10:18a scripts |
07/29/2002 10:02p scripts_NTFRS_000874bb |
Observação
O FRS foi preterido em versões mais recentes do Windows Server. Para obter mais informações sobre como migrar para uma solução mais recente, confira os seguintes artigos:
Motivo
Se dois usuários criarem uma pasta em réplicas separadas e as pastas tiverem o mesmo nome, o FRS detectará um conflito de nomes durante a replicação.
Uma das operações de criação tem precedência e essa pasta mantém o nome original. O FRS altera o nome da outra pasta.
Há duas causas comuns desse problema:
Uma pasta é criada em vários membros do conjunto de réplica antes que a pasta possa ser replicada. O administrador ou programa pode criar pastas duplicadas em vários membros do FRS. Isso poderá ocorrer, por exemplo, se o administrador tentar tornar os dados consistentes entre todos os membros copiando pastas manualmente.
Você inicia uma D4 (restauração autoritária) em um servidor, mas não executa as seguintes preparações:
Antes que o serviço NTFRS seja reiniciado após a restauração autoritativa, interrompa o serviço em todos os outros membros do conjunto de réplica reinitializado.
Antes que qualquer servidor possa replicar alterações de saída para membros reinitializados do conjunto de réplica, configure a chave do registro D2 em todos os outros membros do conjunto de réplica reinitializado.
Resolução
Observação
Política de Grupo processamento de pastas afetadas não funciona durante o processo de limpo. Isso ocorre porque o caminho UNC na política não corresponde ao nome da pasta.
Para resolver este problema, execute as seguintes etapas:
Renomeie as pastas originais e as pastas alteradas e aguarde a propagação dos novos nomes por todo o sistema.
Isso garante que cada pasta tenha um nome comum em todo o SYSVOL e que os nomes e GUIDs correspondam a todos os membros.
Observação
Não exclua a pasta indesejada e renomeie a outra. Isso pode causar ainda mais conflitos de nomenclatura.
Depois que a renomeação se propaga, escolha a pasta que você deseja manter e reverter o nome para o nome original. Em seguida, você pode excluir com segurança as outras pastas renomeada.
Observação
Antes de excluir as pastas, é uma prática recomendada garantir que você tenha um backup dos dados originais (e concluídos).
Mais informações
Todos os arquivos e pastas que o FRS gerencia são identificados exclusivamente por um GUID de arquivo ou pasta. O FRS usa GUIDs como os identificadores canônicos de arquivos e pastas que estão sendo replicados.
O FRS tenta garantir que o GUID para cada arquivo ou pasta seja exatamente o mesmo em todos os membros do conjunto de réplica. Para FRS, o nome do arquivo ou da pasta que está visível no Windows Explorer ou na saída do DIR
comando é apenas uma propriedade de um arquivo ou pasta. O nome e o caminho não identificam o arquivo. O GUID identifica o arquivo.
Se um membro do FRS receber uma ordem de alteração para criar uma pasta usando o nome de uma pasta existente, o FRS detectará um conflito de nomenclatura. A pasta existente e a nova pasta têm GUIDs diferentes. Portanto, a nova pasta não pode ter o mesmo nome que a pasta existente. Nessa situação, a nova pasta recebe um novo nome na forma de <FolderName>_NTFRS_<xxxxxxxxx>.
Observação
Neste exemplo, <FolderName> representa o nome solicitado (o nome da primeira pasta) e <xxxxxxxx> representa oito dígitos hexadecimal aleatórios, como "001a84b2".
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de