Sysvol e netlogon compartilhar importância no Active Directory
> o que é sysvol e conteúdo que inclui.O Sysvol é um componente importante do Active Directory. A pasta Sysvol é compartilhada em um volume NTFS em todos os controladores de domínio em um domínio específico. O Sysvol é usado para fornecer os scripts de política e logon aos membros do domínio.
por padrão sysvol inclui 2 pastas
1.Políticas – (localização padrão- % SystemRoot% \ Sysvol \ Sysvol\domain_name \ Policies)
2.Scripts – (Lcation padrão – %SystemRoot%\Sysvol\Sysvol\domain_name\Scripts)
Nota-Podemos ir em frente e alterar esses locais padrão.
> Imprtance da parte de Sysvol.
Sysvol contém 2 pastas ou seja, políticas e Scripts.
políticas-na pasta Políticas, existem todas as Políticas de grupo definidas em um domínio particluar. Consulte a captura de tela
observe que você pode ver 3 GPT’s estão disponíveis na captura de tela acima. Quando você cria uma nova Política de grupo no active directory, um conjunto de pastas é criado na pasta Políticas.
por exemplo – Estou criando uma política chamada disable screen saver no meu domínio e vinculando essa política à minha UO. Quando eu pressiono o botão Criar nova política no GPMC, ele criará uma pasta de nome GUID na pasta políticas que será associada para desativar o protetor de tela GPO.
para tornar isso simples, a captura de tela acima tem 3 GPT que significam que 3 Políticas de grupo estão presentes no teste.domínio tld.
portanto, quando você faz alterações em determinados objetos de diretiva de grupo, as alterações serão comprometidas com a pasta de nome GUID Assocaited em Sysvol.
Conclusão
a Importância da pasta Sysvol é , mantém o GPT , e sempre que um administrador faz alterações a qualquer uma das políticas , que as alterações irão ser confirmada para o associado GUID nome de pasta e, em seguida, eles serão replicados para todos os controladores de Domínio.
> métodos de replicação do Sysvol.
o Sysvol pode ser replicado para todos os controladores de domínio usando a replicação do sistema de arquivos distribuídos (DFS-R) Se o nível funcional do domínio este link for externo ao TechNet Wiki. Ele será aberto em uma nova janela. é o Windows Server 2008 ou superior, ou é replicado usando o sistema de replicação de arquivos (FRS).
para FRS, a programação SYSVOL é um atributo associado a cada objeto conjunto de réplicas NTFRS e a cada objeto de conexão NTDS. O FRS replica o SYSVOL usando os mesmos objetos de conexão intrasite e a programação construída pelo KCC para replicação do Active Directory. FRS usa dois protocolos de replicação para SYSVOL:
conexão SYSVOL dentro de um site. A conexão é sempre considerada ativada; qualquer programação é ignorada e os arquivos alterados são replicados imediatamente.
conexão SYSVOL entre sites. A replicação do SYSVOL é iniciada entre dois membros intersite no início do intervalo de 15 minutos, assumindo que o cronograma esteja aberto. A conexão é tratada como um cronograma de disparo. O parceiro upstream ignora seu cronograma e responde a qualquer solicitação do parceiro downstream. Quando o cronograma é fechado, o parceiro upstream unjoins a conexão somente após o conteúdo atual do log de saída, no momento da junção, ter sido enviado e reconhecido.
> erro e problemas comuns do sysvol.
a. As ações da Sysvol e Netlogon estão faltando.
pegue um senario , quando você adiciona um novo controlador de domínio ao seu domínio e vê que não há pasta sysvol e netlogon disponível no controlador de domínio
Nota – Netlogon Share não é uma pasta chamada Netlogon no controlador de domínio . Na verdade , é uma pasta onde, todos os scripts de logon são armazenados. Assim como mencionado acima, a pasta Script na pasta sysvol atuará como Netlogon share (localização – %SystemRoot%\sysvol\sysvol\<nome DNS do domínio>\scripts)
isso ocorre principalmente se a replicação do sysvol borken. Em alguns casos, depois de adicionar um novo controlador de domínio, a replicação do sysvol pode levar algum tempo.(Aproximadamente você precisa esperar por algumas horas).
B. Journal Wrap Error
FRS é um sistema de replicação multi-mestre que cuida da replicação do conteúdo do Sysvol entre todos os dc’s no domínio (também pode replicar dados normais, mas estamos interessados principalmente na replicação do Sysvol na entrada do blog).
com os devidos cuidados e manutenção, O pós-SP2 FRS no W2k3 é bastante estável e felizmente cantarola, desde que não haja uma condição externa, como uma interrupção de rede ou problemas de disco que o façam quebrar (supondo que os dados que você está replicando não sejam completamente inadequados para replicação como .Arquivos PST, dados de perfil ou conteúdo que muda com frequência).
a edição FRS mais frequente é onde ocorre um envoltório de diário; vamos dar uma olhada mais de perto no que acontece durante um envoltório de diário sob o capô.
a maneira como o FRS funciona é que ele possui um banco de dados interno que contém todos os arquivos e pastas que está replicando e cada um deles possui um ID global exclusivo (GUID). O dababase também contém um ponteiro para a última operação de disco NTFS (no USN Journal/NTFS Journal) que o serviço FRS processou.
se um usuário alterar um arquivo ou pasta em um disco, o seguinte acontece:
1) a operação é captada por NTFS e uma entrada é feita no Diário NTFS.
2) o FRS monitora o diário NTFS em busca de alterações e observa que uma alteração foi feita nesse arquivo.
3) o FRS mantém um registro do último evento de diário NTFS que processou e verifica se já o processou.
4) Se ele ainda não o processou, ele analisa se é um arquivo que deve replicar.
5) se ele deve ser replicado, o arquivo entra no processo normal de preparação, replicação, etc.
6) o FRS incrementa a entrada em seu banco de dados sobre o evento NTFS Journal que ele processou para que não o considere novamente.
agora…vamos simplificar um pouco as coisas.
– nosso disco contém um arquivo e uma pasta (e:\Test e teste.txt).
– nosso diário NTFS tem um tamanho de 10 entradas (O tamanho padrão do Diário NTFS em RL é de ~512 Mb, dependendo do seu nível OS/SP).
– Nosso banco de dados FRS contém três entradas
->um GUID para E:\test
->um GUID para E:\test\test.txt
->uma referência à última entrada do Diário NTFS que processamos (digamos #4)
operações normais:
– > alguém faz uma alteração no teste.txt.
– > O Diário NTFS é atualizado para #5.
– > FRS observa que o jornal NTFS diz que uma mudança foi feita para testar.txt e vê que não processou essa mudança.
– >Stage / Replicate e atualize o banco de dados FRS para refletir que processamos essa entrada de diário NTFS.
agora, um administrador interrompe o serviço FRS por 30 minutos.
– alguém faz 10 alterações para testar.txt
o O Diário NTFS é atualizado 20 vezes e agora está em #24 (lembre-se de que temos um limite de tamanho de log das últimas 10 entradas, portanto, precisamos envolver).
o FRS é interrompido, portanto, não está monitorando o log do Diário NTFS.
neste ponto, temos alterações no disco que o FRS não conhece. O FRS ainda conhece a última entrada do Diário NTFS que processou e comparará isso com o diário NTFS atual na próxima vez que reiniciar.
na próxima vez que o serviço FRS for iniciado, ele verá que perdeu as operações NTFS no disco (ele processou pela última vez a operação NTFS #4, mas o diário NTFS está agora em #24 e temos apenas um log que remonta a 10 entradas, então estamos perdendo as operações #5-#14 do banco de dados.
é quando o FRS reclama que atingiu um estado de quebra de diário, o log do Diário NTFS foi enrolado e não sabe o estado atual das coisas no disco.
o impacto disso em um DC afetado é que o FRS não definirá a chave de registro IsSysvolReady para indicar ao serviço Netlogon que tudo está bem, o Sysvol, portanto, não será compartilhado e o DC não poderá autenticar os usuários totalmente até que a condição de envoltório do diário seja resolvida.
compartilhar manualmente o Sysvol ou definir a chave de registro IsSysvolReady como 1 não são métodos válidos para resolver esse problema e não estão abordando o problema real.
para que o FRS se recupere de um wrap de diário, você basicamente terá que começar do zero e redefinir o banco de dados FRS e começar a contar o diário NTFS a partir dos valores atuais que ele possui.
isso significa:
– replicando em dados de um parceiro de entrada existente (a abordagem de restauração FRS D2 ou não autorizada).
– tornar seus próprios dados autoritários e permitir que todos os outros replicem de você (a abordagem de restauração FRS D4 ou autoritária).
d2 abordagem é bastante simples de executar, os requisitos são, no entanto, que você tenha uma boa conexão de rede com o parceiro de replicação de entrada e o tempo que demora depende da quantidade de dados a serem replicados versus a capacidade do link
por outro lado, isso pode não ser suficiente e você pode encontrar-se sendo forçado a ir com o d4 opção.
acima são erros mais comuns quando você considera o sysvol no Active Directory.
finalmente, quais são as etapas que podemos seguir quando esses erros acima são agrupados.
> resolução de problemas de mensagens de erro Sysvol
A. As ações da Sysvol e Netlogon estão faltando.
como mencionei antes, pode ser um problema com a replicação do sysvol quebrada entre controladores de domínio.
Como posso forçar a replicação do Sysvol em um Active directory
você pode reiniciar o serviço FRS para forçar a replicação do FRS
para reiniciar o serviço FRS, inicie os Serviços.msc a partir da opção Executar no Menu Iniciar
e reinicie o serviço FRS e você receberá o ID do evento 13516 no log de eventos FRS isso garantirá que o status FRS esteja bom.
replicação de Sysvol através NTFRSUTL
Se você deseja forçar a replicação de sysvol entre dois controladores de domínio no active directory, em seguida, utilize o procedimento abaixo
NTFRSUTL FORCEREPL Opção de Linha de Comando para Forçar a Replicação
Você pode usar o novo comando ntfrsutl forcerepl para forçar a replicação, independentemente da agenda de replicação predefinidos. Isso só é implementado para o conjunto de réplicas SYSVOL do controlador de domínio.
ntfrsutl forcerepl / r / p
este comando força o FRS a iniciar um ciclo de replicação. Você deve especificar o computador, SetName e DnsName.
Nota Neste comando, os seguintes espaços reservados são usados:
= conecte-se com o serviço NtFrs nesta máquina.
= o nome do conjunto de réplicas.
= o nome DNS do parceiro de entrada para forçar a replicação.
por exemplo:
ntfrsutl.exe forcerepl DestinationDC / r “volume do sistema de domínio (compartilhamento SYSVOL)” / p SourceDC.domain.com
as aspas neste exemplo são necessárias quando você usa a opção /R. Se as aspas não estiverem presentes, o comando não funcionará.
se acima não ajudar,
o método mais popular para resolver isso está abaixo do MS KB.
sintomas:
depois de instalar os Serviços de domínio do Active Directory em um novo controlador de domínio baseado no Windows Server 2008 completo ou somente leitura em um domínio existente, o compartilhamento SYSVOL está presente. No entanto, o compartilhamento NETLOGON não está presente no novo controlador de domínio.
Nota Este artigo não se aplica se ambas as ações NETLOGON e SYSVOL estiverem faltando.
causa:
este problema ocorre quando o serviço Netlogon lê o sinalizador SysvolReady no registro muito rapidamente. Em seguida, o serviço Netlogon tenta compartilhar a pasta \Windows\SYSVOL\domain\scripts antes que o NT File Replication Service (NTFRS) crie essa pasta.
solução alternativa:
Aviso podem ocorrer problemas graves se você modificar o registro incorretamente usando o Editor do registro ou usando outro método. Esses problemas podem exigir que você reinstale o sistema operacional. A Microsoft não pode garantir que esses problemas possam ser resolvidos. Modifique o registro por sua conta e risco.
para contornar esse problema, defina o valor do registro do sinalizador SysvolReady como” 0 “e, em seguida, volte para” 1 ” no registro. Para fazer isso, siga estas etapas:
->clique em Iniciar, clique em Executar, digite regedit e clique em OK.
->Localize a seguinte subchave no Editor de Registo:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
->No painel de detalhes, clique com o botão direito SysvolReady sinalizador e, em seguida, clique em Modificar.
– >na caixa Dados do valor, digite 0 e clique em OK.
– > novamente no painel de detalhes, clique com o botão direito do mouse no sinalizador SysvolReady e clique em Modificar.
– >na caixa Dados do valor, digite 1 e clique em OK.
observe que isso fará com que o Netlogon compartilhe o SYSVOL, e a pasta scripts estará presente.
mais informações:
o problema descrito na seção “Sintomas” ocorre no seguinte cenário:
NTFRS primeiro coloca alterações no seguinte local:
\Windows\SYSVOL\domain \ do_not_remove_ntfrs_preinstall_directory
em seguida, o NTFRS notifica o Netlogon para compartilhar o SYSVOL definindo a entrada do registro do sinalizador SysvolReady como ” 1.”
NTFRS, em seguida, move e renomeia ficheiros de localização que é mencionado no passo 1 para a seguinte pasta:
\Windows\SYSVOL\domain
no Entanto, se o serviço Netlogon lê o Sinalizador SysvolReady entrada no registro muito rapidamente, o serviço Netlogon tenta compartilhar a pasta \Windows\SYSVOL\domain\pasta de scripts antes de NTFRS cria essa pasta. Portanto, o compartilhamento NETLOGON não é criado.
B. Erro de encapsulamento de diário
se ocorrer um erro de encapsulamento de diário, podemos definir um valor blurflag como D2 no registro em um controlador de domínio onde os eventos de erro de encapsulamento de diário estão sendo gerados. Ao fazer isso, o controlador de domínio irá despejar as pastas pré-existentes e começar a replicar novo conteúdo de um de seus parceiros de replicação FRS.
ou
podemos definir blurflag para D4 que faz exatamente o oposto ao acima . Isto é , quando você definir D4 em um perticular controladores de domínio, os seus dados irão atuar como Authorative , Resultado, todos os controladores de domínio em seu domínio irá replicar a partir do controlador de Domínio onde este blurflag é definida como D4
Nota – Definição BlurFlag a D4 é a última opção , 90% dos casos vai ser resolvido pela criação de blurflag para D2.
| artigos do anúncio | Windows FAQ’s |
|---|