Problemas com DFSR - Não Replica

Dia desses consegui um problema FDP. Simplesmente os servidores de arquivo não estavam mais realizando a sincronização entre as pastas compartilhadas. O meu ambiente estava configurado da seguinte forma: 2 servidores de arquivo, executando "NAMESPACE"  e "Replicação DFS", nomeados a partir de agora de fs1 e fs2. Nestes servidores tenho vários "GRUPOS DE REPLICAÇÃO".

Meu problema era seguinte: apenas um "GRUPO DE REPLICAÇÃO" não funcionava e o mais estranho, apenas em uma via, ou seja, quando fazia a alteração no fs2 ela era replicada imediatamente para o fs1, mas o contrário não acontecia.

Realizei os seguintes passos:

1 - Chequei a topologia. OK, estava tudo conectado e pronto para replicação;

2 - Criei um "Relatório de Diagnóstico" para verificar obtive um erro;

3 - De olho no "Event Viewer" observei vários eventos 4304* (Violação de Compartilhamento);


4 - Como tive alguns problemas com o Symantec Backup Exec e Replicaçaõ DFSR, minha primeira tentiva foi "PARAR" o "Agente do Backup Exec". Em seguinda reiniciei o "Serviço de Replicação". Nada aconteceu;

5 - Próximo, sincronizei os horários dos "Servidores de Arquivos" com o "Controlador de Dóminio". Nada;

6 - Parei o serviço de Anti-Vírus. NADA.

7 - Nesse ponto, precisa realmente saber o que estava acontecendo, ou seja, monitorar a "Replicação DFS". Fui para Internet e encontrei um programa chamado DfsrMon (no site tem um How to), e através dele consegui descobir que "Backlog" do fs1 para o fs2 estava com mais de 10000 versões sem atualização, ou seja, havia mais de 10000 arquivos para serem replicados.

8 - Neste ponto, eu precisava saber quais eram estes arquivos. Com algumas pesquisas descobri que existe o cmdlet dfsrdiag, um "irmão" do dcdiag. Com um simples leitura no Help dele no próprio CMD, consegui executar os comandos abaixo que me ajudaram na tarefa de saber quais arquivos estavam "entupindo" a replciação.

8.1 - Verifica o backlog da Pasta replicada entre o SenderServer e ReceiverServer
dfsrdiag backlog /SendingMember:fs1 /ReceivingMember:fs2 /RGName:Deptos /RFName:"Deptos" /v

8.2 - Verifica arquivos que esão sendo "baixados" e arquivos que estão na "lista de espera"
dfsrdiag replicationstate /Member:fs1 /V

9 - Quando executei o arquivos acima percebi que havia uma série de arquivos *.mp3; *.wav, etc aguardando o envio. Neste momento liguei os pontos. Como havia configurado "COTA" e "TRIAGEM" para os arquivos, poderia ser este o problema.

10 - Chequei todas as "COTAS" e incrementei as que estavam "penduradas".

11 - Marquei a "Triagem de Arquivos" para tipo "PASSIVO" (apenas avisa, mas não bloqueia).

12 - Executei o comando para visuarlizar a lista de arquivos "presos" mencionado acima no CMD e percebi nas primeira linhas que alguns deles estava com o sufixo ("Baixando").

13 - Através da Ferramenta DfsrMon, pude confirmar que o "BackLog" começou a baixar rapidamente. UFA.

14 - De olho os Logs do "Event Viewer" recebi mais um evento diferente (4202). Esse evento comunicava algo relacionado com "Espaço de Preparação está acima da marca d´água alta". Como havia pesquisado muita coisa antes, este problema foi fácil de resolver.

14.1  - Na ferramenta "Gerenciamento DFS" no grupo "Replicação", marque o "Grupo de Replicação" com problema e navegue para a ABA "Associações" no painel central. Você irá visualizar uma tal de "Cota de Preparação". É este "cara" que deve ser alerado. Clique com o botão da diretita sobre a "Pasta Replicada" e escolha "Propriedades". Vá para aba "Preparação" e incremente um pouco mais a "Cota". No meu caso aumentei de 4GB para 6GB.

Até a próxima.

* Em pesquisas realizadas, descobri que este evento ocorre quando se tem um número muito grande de "alterações" nos arquivos e estas alterações não têm tempo suficiente para serem replicadas.

Servidor de Horário Windows

Para anunciar um servidor DC como "Servidor de Horário" e apontar o ntpclient para algum servidor externo ou interno, digite o seguinte comando:

w32tm /config /manualpeerlist:<nome_servidor_ntp> /syncfromflags:manual /reliable:yes /update

Resolvi um problema de "Advertising" no Windows 2008 R2 com relação ao "Servidor de Horário" quando executada o dcdiag.

Problemas de Replicação - SYSVOL Corrompido

Tive um problema de repliação entre os DCs muito estranho. Mesmo executando o dcdiag /test:replications, dcdiag /test:conectivity e o repadmin /showrepl mostrando OK/SUCESSO durante os testes, no Event Viewer do Windows apareciam LOGs informado que a pasta SYSVOL estava corrompida (SYSVOL Formatado, Serviço de replicação não iniciado, Impossível resolver nome dc2.empresa.com, etc). Esse erro nos LOGs aparecia todas as vezes que o Serviço NTFSR era reiniciado.

Mais um vez segui alguns procedimentos que resolveram o problema. Vamos lá:

1) Carregue o regedit;

2) Navegue até a HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters;

3) Adicione a entrada "Enable Journal Wrap Automatic Restore" do tipo REG_DWORD com valor 1. Esta entrada ativa exclusão dos arquivos dos SYSVOL e força uma nova replicação;

4) Reinicie o serviço NTFrs (Serviço de Replicação de Arquivos);

5) Acompanhe os LOGs pelo "Event Viewer", irão aparecer alguns "warnings", e pelo comando NETSHARE o recompartilhamento automático da pasta SYSVOL.

Assim que a replicação foi concluída, automaticamente a compartilhamento SYSVOL foi recriado.
Para confirmar a resolução, limpei os LOGs e reiniciei o serviço NtFsr. Pelos LOGs foi possível constatar que o problema foi resolvido.

ERRO em Compartilhamento com CNAME

Criei uma entrada no DNS do tipo CNAME apontando para o servidor de Arquivo. Quando tentei acessar o compartilhamento via Windows Explorer ocorria um erro de "Nome duplicado de REDE". A partir deste ponto, realizei uma série de testes. Conseguia "PINGAR" no FQDN do servidor e também no "CNAME", porém conseguia acessar o compartilhamento somente via FQDN.

Em uma busca pela Internet, encontrei que isso é um problema conhecido e para resolver este problema, realizei os seguintes procedimentos, no servidor apontadado pela entrada CNAME.

1) Carregue o REGEDIT
2) Navegue até a chave "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters"
3) Crie a "ENTRADA" com o nome de "DisableStrictNameChecking" do tipo "REG_DWORD" com valor Decimal "1".

Após estas configurações, temos que reiniciar o servidor.

Caso as configurações não funcionem, podemos tentar adicionar SPN (Service Principal Names) para o CNAME recém criado. Para isso:

1) Abra o CMD
2) Digite "setspn -a host/<cname> <nome_servidor>", confirme com "ENTER"
3) Digite "setspn -a host/<cname>.<dominio> <nome_servidor>", confirme com "ENTER"

Essas configurações resolveram meus problemas.

Forçar Layout de Teclado via GPO

Na empresa que trabalho atualmente, temos uma série de modelos e marcas de ThinClients e alguns deles insistem em alterar o Layout do Teclado para Inglês toda as vezes que o usuário realiza um LOGON no servidor de WTS, o que sempre acaba gerando uma série de Incidentes para a Central de Serviço. Este problema está relacionado com a própria configuração de Idioma e Layout de Teclado do ThinClient.
Para resolver este problema, fiz uma série de pesquisas na Internet, e acabei encontrando uma solução prática que irei descrever em linhas gerais neste post.

1 - Criar um arquivo .reg com o conteudo abaixo. Este arquivo será importado via GPO.

------- START KeyboradLayoutBR.reg -------
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Keyboard Layout\Preload]
"1"="00000416"
"2"=-
"3"=-
------- END KeyboradLayoutBR.reg -------

O valor "00000416" é o código para o Layout de Teclado ABNT2. As demais chaves com valor "-" será excluídas/zeradas do regeistro.

2 - Crie um GPO e vincule com OU e/ou Dominio, conforme achar melhor

3 - Navegar até “Configurações de Usuário > Modelos Administrativos > Painel de Controle > Opções Regionais e de Idioma”

4 - Habilitar as Chaves “Restringe os idiomas da UI que o Windows deve usar para o usuário selecionado” e “Restringir a seleção do idioma dos menus e caixas de diálogo do Windows” e ajustar ambas configurações para “Português (Brasil)”

5 - Na GPO recém criada, navegue até “Configurações de Usuário > Configurações do Windows > Scripts (Logon/Logoff)”

6 - Adicione um script de "Logon" com os seguintes paramêtros: em "Nome do Script:" digite "regedit /s" para realizar a importação do ".reg" em modo silencioso. Em "Paramêtros do Script:" digite o caminho completo incluindo o nome do arquivo. Neste ponto a GPO está pronto.

7 - A próxima configuração será realizada no Terminal Server. Abra o "regedit" e navegue até a chave “\HKLM\SYSTEM\CurrentControlSet\Control\KeyboardLayout”.

8 - Crie uma chave do tipo "DWORD" com o nome de "IgnoreKeyboardLayout" com o valor "1".

9 - Entre nas sessões dos usuários e execute "gpupdate /force" e depois faça um LOGOFF.



As configurações realizadas acima resolveram os problemas com o Layout de Teclado dos ThinClients.

WSUS não Atualiza Desktops XP

Certo dia alguns desktops com Windows XP simplesmente não estavam mais atualizando através do WSUS. Realizei uma série de pesquisas e configurações, mas nenhum acabou surtindo o efeito desejado.

Depois de muitas pesquisas e análises do LOG do WSUS em um cliente, juntamente com as configurações testadas acima, encontrei uma solução para o problema. Gostaria de dizer que ela funcionou no meu caso, mas com são muitas opções/erros que podem acontecer, em certos casos, ela poderá não ser muito útil.

Ai vai ela:

:: Atualização no Servidor WSUS

Aplique a atualização WSUS-KB272011 referente à sua plataforma (x86 ou x64).

:: Teste de Conexão

Você pode realizar a conexão com o WSUS utilizando o utilitário WSUS Client Diagnost Tool. Esta ferramenta mostra como está a saúde da conexão entre o Cliente e o Servidor de Atualização.

:: Verificação de LOGs

Para a verificação de LOGs utilizei um aplicativo com o nome de Tail for Win32. Facilitou muito para mim a visualização dos acontecimentos dentro do arquivo c:\WINDOWS\WindowsUpdate.log.

:: Mão na Massa

De posse dos artifícios mencionados, execute o programa “TAIL”, abra o arquivo “C:\WINDOWS\WindowsUpdate.log” e clique no botão “Resume Scrolling” para iniciar o monitoramento do arquivo. Abra um “Prompt de Comando” e execute o comando wuauclt /detectnow. Fique de olho no TAIL. Surgirá uma linha informando uma falha no download e qual a atualização que está apresentando problema (Veja exemplo abaixo).

DnldMgr    Failed file: URL = 'http://wsus/Content/44/2B03B54C0972C16AB6CE75F42AC4877AF87CE844.exe', Local path = 'C:\WINDOWS\SoftwareDistribution\Download\789de410a60b090acadde68e4e4933ac\2b03b54c0972c16ab6ce75f42ac4877af87ce844'

DnldMgr    Error 0x80246002 occurred while downloading update; notifying dependent calls.

O texto sublinhado no log acima era a atualização que estava bloqueando as atualizações no Windows XP. De posse do nome da atualização problemática, vá para o servidor WSUS, abra a pasta que contem os repositórios da atualização e localize a pasta “44” (Ex.: C:\WSUS\WsusContent\44).

Iremos para os serviços de atualização, excluir a pasta, resetar as atualizações e reiniciar os serviços novamente. Para isso, abra o “Prompt de Comando” no Servidor WSUS e digite os seguintes comandos:

C:\>net stop wuauserv

C:\>net stop bits

Exclua a pasta que possui a atualização com problemas. Então:

C:\>Program Files\Updates Services\Tools\wsusutil.exe reset

C:\>net start wuauserv

C:\>net start bits

Vá para o Desktop no “Prompt de Comando” e execute os seguintes comandos:

C:\>net stop wuauserv

C:\>net stop bits

Exclua a pasta "C:\WINDOWS\SoftwareDistribution"

C:\>net start wuauserv

C:\>net start bits

C:\>wuauclt /resetauthorization /detectnow

Fique de olho nos LOGs e confirme se atualização com problema não é mais exibida. Da forma descrita acima, consegui contornar o problema de atualização dos Desktops Windows XP através do WSUS. No meu caso a atualização era do .NET Framework 3.0, e como a versão atual era 3.5, não tive receio nenhum em manda-la para o espaço.

Valeu!

Certificados com SAN para IIS

Tive uma tarefa muito complicada um pouco tempo atrás, os usuários da empresa onde trabalho estavam reclamando muito em clicar na mensagem "Continuar neste site - não recomendado" do iExplorer devido ao certificado.

Depois de muita pesquisa e testes consegui gerar um certificado para atender vários nomes (SAN - Subject Alternative Name) e aplica-lo na configuração do IIS no aplicativo do OWA, assim economizei muito ouvido com relação as reclamações. Vou repassar as informações de forma bem simples, observando que isto foi utilizando em um ambiente interno. Para ambientes externos existe a necessidade de adquirir um certificado de autoridades como SERASA, Correio, etc.

:: Instalar Autoridade Certificadora no Windows 2008 R2
1) Entre em Gerenciar Servidores > Funções > Adicionar Função
2) Você deverá instalar todos os serviços desta função, mas isto deve ser feito em duas etapas, pois o Windows não permite a instalação direta dos 4 itens em uma única vez, então marque "Autoridade de Certificação" e "Registro na Web de Autoridade de Certificação".
3) Marque a opção "Servidor Corporativo".
3) Volte em funções na sessão "Serviços de Certificados do Active Directory" e instale as demais funcionalidades.

Obs.: Instalei com opções padrão, apenas criei um usuário especifico para esta finalidade e o incluí no grupo IIS_IUSRS. Utilizei este usuário para autenticação no site e aplicativos.


:: Habilitando SAN para certificados
Por padrão o SAN não vem habilitado, então precisamos configurar esta opção:
1) Abra o CMD e digite os seguintes comandos:

c:\> certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
c:\> NET stop certsvc
c:\> NET start certsvc

:: Solicitando o Certificado
Vamos solicitar o certificado pelo IIs
1) Abra o console de gerenciamento e clique no servidor (neste caso, o servidor IIS que executado o OWA)
2) Na sessão IIS escolha a opção "Certificado de Servidor"

3) À direita na parte superior clique em "Criar Solicitação de Certificado..."

4) Preencha os campos da forma que achar melhor, mas no campo nome comum digite a URL completa do servidor
5) Na última etapa escolha o local onde o arquivo de solicitação será salvo e clique em concluir

:: Gerando o Certificado
1) Abra o navegador e aponte para o servidor de Autoridade Certificadora". https://<servidor-autoridade-certificadora>/certsrv
2) Clique em "Solicitar um Certificado > Solicitação Avançada de Certificado > Envie uma solicitação de certificado [...] na Base 64"
3) Na TextArea (primeiro campo do formulário, sessão "Solicitação salva:") cole o conteúdo do arquivo gerado na solicitação
4) Selecione "Servidor WEB" em "Modelo de Certificado"
5) Em "Atributos Adicionais" iremos informar os vários SAN para o certificado seguindo a sintaxe: SAN:dns=dnsname1[&dns=dnsname2...]. Ex.: SAN:dns=webmail&dns=webmail.contoso.com
5) Clique em enviar e faça o download do arquivo .cer

:: Importando Certificado para o IIS
1) Na opção "Certificados de Servidor" clique na opção "Concluir Solicitação de Certificado..."

2) Aponte para o arquivo .cer baixado
3) Informe um nome amigável e clique em Ok
4) No site do OWA, altere a ligação 443 para utilizar o certificado recém Instalado.

Alguns computadores importaram sozinho o certificado da Autoridade de Certificação Raiz Confiável, as que não fizeram automaticamente podemos instalar o certificado através do site https://<servidor-autoridade-certificadora>/certsrv, opção "Fazer Download de um certificado de autoridade de certificação...", ou instala-lo através de GPO em "Diretivas de Computador > Diretivas de Segurança > Diretivas de Chave Pública".

Consegui economizar algumas horas de ouvido com essas alterações.

Até a próxima.