Luciano Brena

1000 visitas!!!

2012-11-06T10:20:00.001-02:00

Mesmo sem nenhuma divulgação o blog atingiu a marca de 1000 visitas!! Obrigado à todos que acessaram!

Serviço do File Server Resource Manager não inicia - Erro -2147200234.

2012-09-05T19:12:00.000-03:00

Olá pessoal, vamos a mais um post. Desta vez irei descrever como resolver o problema onde o File Server Resource Manager não inicia apresentando o erro -2147200234

O problema:

Não é possível iniciar o serviço do File Server Resource Manager. A seguinte mensagem é exibida ao abrir a console do File Server Resource Manager

Como resolvemos?

Identificamos que o serviço do File Server Resource Manager estava parado e com o status Automático, ou seja deveria ser iniciado juntamente com o servidor.
Ao tentarmos iniciar o serviço do File Server Resource Manager a seguinte mensagem de erro era exibida:

*****************************************************
Windows could not start the File Server Resource Manager on Local Computer. For more information, review the System Event Log.
If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -2147200234.
*****************************************************

No event Viewer a seguinte mensagem de erro era exibida toda vez que tentávamos iniciar o serviço:

A mensagem de erro acima diz que temos um problema de acesso negado ao arquivo: 'C:\System Volume Information\SRM\Settings\SrmGlobalSettings.xml'.

Apenas para efeitos de testes demos a permissão full control para grupo everyone para as pastas:

• C:\System Volume Information
• C:\System Volume Information\SRM
• C:\System Volume Information\SRM\Settings

Tambem demos permissão full control para grupo everyone para o arquivo

• C:\System Volume Information\SRM\Settings\SrmGlobalSettings.xml

Após darmos as permissões iniciamos o serviço com sucesso.

Retiramos as permissões, paramos o serviço e identificamos as permissões que estavam faltando utilizando a ferramenta Process Monitor, disponível em http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

O Process Monitor é uma ferramenta de monitoramento avançado para Windows que nos mostra em tempo real as atividades no sistema de arquivos, registro, processos, e atividades de threads.
Com isso, simulamos o problema (Tentando iniciar o serviço do File Server Resource Manager) rodando o monitoramento do Process Monitor e obtivemos o seguinte resultado:

• Acesso negado na pasta: C:\System Volume Information\SRM\
• Acesso negado no arquivo: C:\System Volume Information\SRM\Settings\SrmGlobalSettings.xml

A imagem abaixo nos mostra o resultado acima na interface do Process Monitor

Para identificar qual o tipo de permissão e para qual usuário estava faltando a permissão apenas demos um duplo clique nas entradas exibidas no Process Monitor e com isso podemos identificar qual usuário estava tendo o acesso negado:

Com isso demos permissão para System através da aba segurança da pasta C:\System Volume Information fazendo com que a pasta herdasse a permissão da raiz e fosse aplicada a pastas e arquivos filhos

Após darmos as permissões, iniciamos o serviço do File Server Resource Manager com sucesso e todas a features do FSRM voltaram a funcionar (Quotas, File Screening entre outros).

Espero ajudar a todos que tenham esse mesmo problema.

Abraços e até o próximo post!

Usuários restristos não conseguem acessar conteúdo da lixeira!

2012-08-24T12:02:00.002-03:00

Olá pessoal,

Neste post falaremos sobre um caso onde os usuários que não tem direito administrativo, não conseguem visualizar o conteúdo da lixeira do Windows.
Ao acessar a lixeira, nada é exibido, mesmo que o icone da lixeira apareça como cheio.

Usuários que tem o perfil de administrador conseguem acessar e visualizar o conteúdo da lixeira normalmente.

Uma vez que usuários com direitos administrativos são capazes de visualizar o conteúdo da lixeira do Windows sem nenhum problema e os usuários restritos não conseguiam, o primeiro ponto a ser verificado são as permissões e direitos para os usuários.

Para identificarmos qual acesso estava sendo negado, utilizamos a ferramenta Process Monitor, disponível em http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

O Process Monitor é uma ferramenta de monitoramento avançado para Windows que nos mostra em tempo real as atividades no sistema de arquivos, registro, processos, e atividades de threads.

Com isso, simulamos o problema (acessando a lixeira com o usuário restrito) rodando o monitoramento do Process Monitor.
O Process Monitor nos trouxe a informação de que o acesso estava sendo negado para o usuário para a pasta $Recycle.bin no disco C:\

A partir desse ponto, partimos para verificar que tipo de permissão estava faltando nesta pasta, comparando-a com a de um sistema sem problemas.
Usamos a ferramenta CACLS, para comparar as permissões:
No disco C: o CACLS nos mostrou as seguintes permissões para a pasta $Recycle.bin

*********************************************
C:\>CACLS $RECYCLE.BIN
C:\$RECYCLE.BIN AUTORIDADE NT\SISTEMA:(OI)(CI)(ID)F
                BUILTIN\Administradores:(OI)(CI)(ID)F
                BUILTIN\Usuários:(OI)(CI)(ID)R
*********************************************

O resultado esperado para as permissões da pasta $Recycle.bin seriam:

*********************************************
E:\$RECYCLE.BIN BUILTIN\Administrators:(OI)(CI)F
                NT AUTHORITY\SYSTEM:(OI)(CI)F
                BUILTIN\Users:(NP)(special access:)
                                  READ_CONTROL
                                  SYNCHRONIZE
                                  FILE_GENERIC_READ
                                  FILE_GENERIC_EXECUTE
                                  FILE_READ_DATA
                                  FILE_APPEND_DATA
                                  FILE_READ_EA
                                  FILE_EXECUTE
                                  FILE_READ_ATTRIBUTES
                                  FILE_WRITE_ATTRIBUTES
*********************************************

A partir desse ponto podemos observar que algumas permissões para o grupo Users estavam faltando.
Verificamos manualmente estas permissões e identificamos que o grupo users não tinham as permissões marcadas abaixo:

• Create Folders / Append data
• Write Attributes

Marcamos as entradas conforme a imagem abaixo, para o grupo Users, e após essas permissões os usuários restritos conseguiram visualizar o conteúdo da lixeira normalmente.

Como diversas máquinas possuíam este mesmo problema e foram instaladas a partir de uma imagem, sugerimos que as permissões da pasta $Recycle.bin fossem restauradas utilizando o comando CACLS abaixo:

*************************************************************************************
cacls C:\$Recycle.Bin /S:"D:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)"
*************************************************************************************

Esta linha de comando restaura as permissões originais para a pasta $Recycle.bin.
Através dessa linha de comando é possível criar um script para que o processo de de restauração das pastas sejam realizados de forma automática. (é necessário direitos administrativos para rodar a linha de comando)

Com o script abaixo você consegue realizar a mudança de forma automática para diversas máquinas.

***************************************************
::BEGIN BATCH FILE
@echo Y> Y.txt
@cacls C:\$Recycle.Bin /S:"D:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)" <Y.txt
@del Y.txt
::END BATCH FILE
***************************************************
Espero que este post ajude quem tem o mesmo sintoma a resolver o problema, caso tenha algum problema parecido você pode seguir a mesma linha de troubleshooting, através do Procmon e verificando se existe algum acesso negado.

Abraços e até o próximo post!

GPO que configura "Trusted Sites" não é aplicada à Servidores de TS 2003

2012-08-10T17:04:00.003-03:00

Neste caso uma GPO que configura a opção de trusted sites (Sites Confiávies ) no Internet Explorer não está sendo aplicada, na verdade a GPO é aplicada, porém o Internet Explorer não traz as configurações. Porquê isso acontece? Hoje vamos falar um pouco deste estranho comportamento e como conseguimos descobrir a causa desse problema e por fim, resolvê-lo de maneira definitiva.

Identificamos que a GPO que configura os sites confiáveis no Ineternet Explorer (TS Group policy Object) estava sendo aplicada com sucesso na máquina cliente, pois através do comando Gpresult /Z e verificando as chaves de Registro as quais as políticas devem ser aplicadas na máquina cliente estava comfiguradas conforme as imagens abaixo:

Trechos do “Output” do comando Gpresult /z (Modo verbose) que identificam que a política estava sendo aplicada:

Além do Gpresult, se abríssemos o registro do Windows na máquina cliente podiámos ver que o registro aceitou as configurações da GPO conforme a saída do Gpresult

Habilitamos o log de userenv para nos certificar se algum erro estava ocorrendo quando a GPO estava sendo aplicada. Para habilitar o log seguimos o procedimento abaixo:

Para habilitar o log de userenv:

Criar a entrada:

Entrada: UserEnvDebugLevel
Tipo: REG_DWORD
Valor: 30002 Hexadecimal

Esta entrada deve ser criada em: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Simulamos o logoff e logon e identificamos que um erro era exibido no log de uservenv ao aplicar a GPO que configura o Trusted Sites ao Internet Explorer.
O log de userenv é salvo em %Systemroot%\Debug\UserMode\Userenv.log

Neste log identificamos que a GPO exibia um erro ao ser aplicada:

O erro 0x57 Significa parâmetro inválido conforme podemos comprovar na ferramenta Err disponível para download em:
http://www.microsoft.com/en-us/download/details.aspx?id=985 - Microsoft Exchange Server Error Code Look-up

Além desses erro, no log de aplication do Event Viewer podiámos perceber que a GPO exibia erros ao ser aplicada:

Partindo desse ponto, sugerimos o plano de ação a seguir para isolar qualquer problema com a sintaxe das URLs configuradas no trusted sites.

Criar ou modificar a GPO existente para que apenas uma entrada seja adicionada aos sites confiávies. Uma entrada simples por exemplo http://www.microsoft.com
O objetivo era verificarmos se a GPO está funcionando como deveria apenas com esta entrada simples, pois na entrada que temos no ambiente atualmente temos listas duplicadas, e com problemas de sintaxe que podem acarretar em problemas como esses.

Configuramos a GPO para que apenas o site http://www.microsoft.com fosse configurado como Trusted Sites.
Após este procedimento o log de userven não registrou mais erros, porém a GPO continuava não sendo aplicada no Internet Explorer.

A partir desse ponto, passamos a verificar outros pontos que não estivessem ligados com a GPO, pois todas as evidências apontavam de que a GPO estava sendo aplicada corretamente, porém o Internet Explorer não exibia as configurações recebidas pela política.

Indentificamos que a feature Internet Enhanced Security estava habilitada no servidor em questão, e que a mesma não podia ser desabilitada, pois no adicionar e remover componentes do Windows o checkbox já encontrava desmarcado.

Imagem que indica que o Internet Enhanced Security estava habilitado no servidor e ao tentar removê-lo no Windows Components o checkbox já se encontrava desmarcado

Com isso identificamos o seguinte cenário descrito no artigo http://support.microsoft.com/kb/933991/en-us - Standard users cannot turn off the Internet Explorer Enhanced Security feature on a Windows Server 2003-based terminal server

Onde o sintoma descrito é exatamente o do checkbox:

“After you configure a Microsoft Windows Server 2003-based terminal server, standard users cannot turn off the Internet Explorer Enhanced Security Configuration feature. When a standard user clicks to clear the Internet Explorer Enhanced Security Configuration check box, the check box remains clear as expected. However, Internet Explorer Enhanced Security Configuration is still enabled.”

Para isso seguimos a solução descrita no método 3 do artigo, deletando a entrada IEHarden do registro em “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zonemap”

Após esse procedimento a política foi aplicada com sucesso e as configurações apareceram no Internet Explorer. Inclusive voltando a GPO antiga que apresentava problemas de sintaxe

Caso você queira realizar este procedimento automaticamente, sugiro que a linha abaixo seja incluída em um script de logon:

*********************************************************************************
REG DELETE "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap" /v "IEHarden" /f
*********************************************************************************

Com a linha abaixo a entrada no registro será deletada desabilitando o Enhanced Security de forma automática para os usuários através do script de logon, automatizando o processo para todos os usuários.

Artigos relacionados:

Abaixo disponibilizo uma lista de artigos que usamos para a resolução deste problema e que nos serviu de apoio em todo o processo de troubleshooting.

http://support.microsoft.com/kb/933991/en-us - Standard users cannot turn off the Internet Explorer Enhanced Security feature on a Windows Server 2003-based terminal server

http://support.microsoft.com/default.aspx?scid=KB;EN-US;221833 - How to enable user environment debug logging in retail builds of Windows (221833)

http://support.microsoft.com/kb/259493 - Problemas ao adicionar domínios de nível superior à lista de Sites da zona

Problemas ao abrir o Server Manager no Win 2K8 R2

2012-02-27T16:24:00.000-03:00

Olá vamos a mais um post!

Desta vez mostraremos um passo a passo de como realizar troubleshooting em casos onde o server manager não abre! Você precisa adicionar uma nova "feature" ou "role" e a seguinte mensagem de erro é exibida:

Para resolvermos este tipo de problema, devemos seguir os passos abaixo:

1. Instalação do checksur
Você precisará baixar e instalar o kb 947821 - disponível em http://support.microsoft.com/kb/947821

2. Após instalar o Kb, você precisa verificar o log checksur.log que está localizado em: C:\Windows\Logs\CBS
No log checksur.log você encontrará algo similar ao log abaixo:
Para identificar o arquivo corrompido você irá procurar pelos arquivos descritos abaixo de “Unavailable repair files:” (Confome o exemplo abaixo)

Neste caso os arquivos corrompidos são:

Package_for_KB2545698_RTM~31bf3856ad364e35~amd64~~6.1.1.3.mum
Package_for_KB2545698_RTM~31bf3856ad364e35~amd64~~6.1.1.3.cat

3. Uma vez que você identificou os arquivos que estão corrompidos, a maneira mais rápida de resolver o problema é copiar estes mesmos arquivos de um servidor que tem o Server Manager funcional
Os arquivos podem ser localizados no diretório C:\Windows\Servicing\Package na máquina que está saudável.

4. Copie ambos os arquivos que você identificou como corrompidos para o desktop da máquina que está tendo problema.

5. Para que você possa copiar os arquivos do servidor de destino para a pasta correta C:\Windows\Servicing\Package você precisára executar dois comandos:

takeown /F c:\Windows\Servicing\Packages /D y /R
cacls c:\Windows\Servicing\Packages /E /T /C /G "UserName":F

O primeiro comando toma o ownership da pasta.
O segundo comando dá permissões para o usuário designado em “Username”

6. Após executar os comandos acima, você será capaz de copiar e substituir os arquivos que trouxemos da outra máquina (Máquina saudável)

7. Após substituir os arquivos feche o server manager (Se estiver aberto) e abra-o novamente. Na maioria das vezes estes passos são suficientes para resolver o problema.

Em alguns casos você poderá ter uma nova mensagem de erro ao Abrir o Server Manager

Unexpected error refreshing Server Manager: The default authentication level for Component Services is currently set to None. It is recommended that you change this setting to Connect. To change the default authentication level, click Start, point to Administrative Tools, and then click Component Services. In the Component Services snap-in hierarchy pane, expand Component Services, expand Computers, right-click My Computer, and then click Properties. In the Properties dialog box, on the Default Properties tab, change the default authentication level to Connect.

Neste caso apenas seguimos as instruções fornecidas pelo erro:

8. Abrimos o menu Iniciar >>> Administrative Tools >>>> Component Services

9. Na console do Component Services expandir Component Services, expandir Computers, clicar com o botão direito do mouse em meu computador e clicar em Properties

10. Em properties, vá até a aba Default Properties e mude o nível de autenticação para Connect, conforme a imagem abaixo:

11. Abra o Server Manager e provavelmente ele está funcionando!

Espero que este post ajude muitas pessoas a resolverem este tipo de problema, não só para o erro mencionado acima o 0x800F0818, mas também outros como por exemplo 0x80070490 e o 0x800706BE.

Em todos os casos o sistema operacional é o Windows Server 2008 R2

Abraços e até o próximo post!

O que é isso no meu computador???

2012-01-19T23:52:00.002-02:00

Ola Pessoal,

Primeiramente um Feliz 2012 à todos que estão lendo este post!!!

Hoje vamos abordar um assunto que causa muitos problemas em ambientes Windows, tanto em máquinas clientes (XP, Vista e Windows 7) como servidores (Win 2003, 2008 e 2008 R2) e principalmente em servidores que são servidores de Terminal Services.
O nome desse assunto é o Módulo de proteção, guardião, mais popularmente conhecido como Gbplugin.
O Gbplugin é um aplicativo de segurança utilizado pelos Bancos Brasileiros e destinado aos usuários de Internet Banking. Ou seja, se você costuma acessar sua conta online, provavelmente você tem o Gbplugin instalado.
Você deve estar se perguntando: Mas eu não me lembro de ter instalado esse aplicativo!
Esse aplicativo é instalado quando você utiliza o Internet Banking pela primeira vez em uma determinada máquina. Ao acessar sua conta, o site do banco solicita que você faça a instalação.
Para ajudar a refrescar sua memória seguem exemplos de tela solicitando a instalação de alguns bancos.

Exemplo 01 - Tela de instalação do ~~Gbplugin~~ (Guardião)

Exemplo 02 - Tela de Instalação do ~~Gbplugin~~ (Módulo de Proteção)

Exemplo 03 - Solicitação de instalação do Gbplugin

Claro que é conveniente a instalação do Plugin, sendo que o plugin torna o Internet Banking mais seguro.
Porém o fato deste plugin ser tão seguro, muitas vezes acaba causando um comportamento estranho nas máquinas, como por exemplo, problemas no Logon, problemas com o internet explorer, bugchecks, (Tela Azul), máquinas reiniciando devido a processo vitais tais como services.exe ou svchost sendo finalizados de forma inesperada entre outros comportamentos estranhos.

E agora? Já instalei,o que faço?

Se você tem o Gbplugin instalado, e não tem nenhum problema no seu sistema operacional você não tem motivos para removê-lo.
Agora, se você instalou e está tendo um dos problemas acima mencionados ou outros comportamentos estranhos onde você desconfie que o Gbplugin esteja causando o problema, o ideal seria removê-lo para procedimento de troubleshooting. É aí que começa o problema!

Vamos imaginar o seguinte cenário, você identificou um problema causado pelo Gbplugin. Este problema torna seu ambiente de produção indisponível. Muitos usuários estão parados pois não conseguem trabalhar nas suas estações pois elas aprensentam tela azul a cada 1 minuto.
Você como administrador da rede imagina, vou desinstalar esse cara! Vai até o adicionar e remover programas e não encontra nada lá para remover.
Você encontra o executável do gbplugin no C:\arquivos de programas\Gbplugin e tenta deletar o arquivo e recebe "Acesso negado" ou simplesmente que o programa está em uso e não pode ser deletado.

Gbplugin em Uso - Não é possível deletá-lo

Você encontra no services.msc um serviço chamado Gbp Service. Tenta parar o serviço. Ops... não tem a opção de parar o serviço.

Serviços - Não é possível parar o Gbp Service

Você então pensa... Ah vou deletar a chave de registro!
Abre o regedit, navega até HKLM\System\CurrentControlSet\Services e encontra uma chave chamada GbpSv ou GbpKm

Informações no regsitro sobre o Gbplugin - Não é possível deletar, as chaves reaparecem!

Você deleta as chave de registros , e simplesmente elas voltam em questão de milissegundos.
Através do Msconfig não é possível desabilitar o serviço.
Como fazer pra desinstalar o Gbplugin? A resposta é simples. Entre em contato com o suporte do banco que é responsável pelo Gbplugin instalado no seu computador.
Como saber qual pe o banco?
Indo até pasta do Gbplugin C:\arquivos de programas\gbplugin, selecione um dos arquivos, clique com o botão direito, propriedades e selecione a aba Assinatura Digital. Lá você conseguirá descobrir á qual banco pertence o plugin.

Descobrindo à qual banco o plugin pertence

Uma vez que você identificou à qual banco pertence o pluginm entre em contato com o suporte do banco, e solicite a remoção do Gbplugin. O banco tem a ferramenta de remoção do Gbplugin.
O único problema é que seu ambiente neste momento está todo parado e você precisa remover o plugin agora! Você liga para o suporte do banco responsável pelo plugin e eles te passam que a será realizado um contato em dois dias (situação hipótetica) e você não pode mais esperar. O que fazer? Como remover o gbplugin sem auxílio do banco de de forma rápida?

Isso você verá no próximo post, que será publicado em breve!

Abraços e até lá!

Clean Boot

2011-09-25T14:25:00.003-03:00

Olá pessoal, vamos hoje ao nosso segundo post!

Você alguma vez já passou por uma situação onde seu computador não iniciava em modo normal porém funcionava normalmente em modo de segurança?

Isso pode acontecer devido à algum problema com software ou serviço que não faz parte do sistema operacional. Quando você inicia o computador em modo seguro esses serviços e aplicações não são inciados e o computador consegue iniciar normalmente.
Mas como descobrir qual o serviço ou software que está causando o problema?
A respota é simples, assim como o procedimento para chegar à resolução
Hoje vamos mostrar como realizar um "Clean Boot"

Clean Boot - Consiste em desabilitar todos os serviços que não são Microsoft, e reiniciando a máquina para verificar se algum outro software ou serviço não Microsoft pode estar interferindo no sistema operacional.

Procedimentos para execução do Cleanboot:

1. Abrir o menu Iniciar >>> Executar e digitar msconfig, conforme a imagem abaixo:
2. No msconfig ir até a aba services, marcar as opções “Hide All Microsoft Services” e “Disable All”
3. O msconfig exibirá somente os serviços que não são Microsoft e desabilitados, conforme a imagem a seguir. Neste caso temos somente 1 serviço não-Microsoft
4. Clique na aba startup e depois em Disable All e em OK

5. Reiniciar a máquina e ver se o problema continua acontecendo sem os serviços e aplicações não Microsoft.
Caso a máquina inicie normalmente após o clean boot, repetir os procedimentos acima, porém ao invés de remover você voltará a adicionar o serviços que foram removidos.

6. Para agilizar o processo você pode adicionar a metade dos serviços, e reinciar a máquina, caso apresente o problema novamente já sabemos que um desses serviços habilitados estão causando o problema.
Realize os procedimentos novamente até estreitar as opções de serviços disponíveis para chegar no serviço ou aplicação que esteja causando o problema.

Este procedimento apesar de ser bem simples acaba nos salvando de grandes problemas, auxiliando na resolução rápida de um servidor que não inicia mais.

Até a próxima!

2011-09-01T23:19:00.000-03:00

O misterioso caso do DHCP

Olá pessoas! Bem vindo ao nosso primeiro post. Espero poder compartilhar com vocês informações úteis e que ajudem na resolução de problemas do dia a dia em ambientes Microsoft.

Neste primeiro post, vamos acompanhar um caso bem curioso, onde o administrador da rede me reportou que o serviço de DHCP estava parando todos os dias pela manhã, e com isso centenas de usuários ao chegarem ao trabalho tinham problemas de logon. Resultado: todo mundo sem trabalhar! \o/

Caso queira conhecer a fundo o como funciona o serviço de DHCP o link abaixo é leitura obrigatória:

How DHCP works - http://technet.microsoft.com/pt-br/library/cc780760(WS.10).aspx (em inglês)

Voltando ao problema, olhando a console de serviços do Windows, verificamos que o serviço de DHCP estava com o status "stopped", e clicando em start o serviço era iniciado normalmente, sem nenhum problema, até o dia seguinte, onde o mesmo parava novamente.

Fomos atrás de mais pistas que nos levassem a causa desse comportamento, esperava que o serviço de DHCP tivesse um "crash" ou algo do tipo, mas olhando o log de Application do Windows não encontrei nada que nos provasse isso.

Os eventos de System, também não nos mostravam informações que nos dessem pistas do problema. Para piorar, por algum motivo nem os logs de que o serviço foi iniciado ou parado eram logados nesse servidor.

Verificando os logs de auditoria do DHCP, (que ficam por padrão em C:\Windows\System32\Dhcp - se estiverem ativados, claro!) podíámos ver que o serviço parava:

25,05/24/07,21:39:31,0 leases expired and 8 leases deleted,,,, 25,05/24/07,21:39:31,0 leases expired and 0 leases deleted,,,, 11,05/24/07,21:49:53,Renew,10.226.149.19,machinename.contoso.msft,0013D32435D, 11,05/24/07,22:24:09,Renew,10.226.161.54,machinename02.contoso.msft,000009D9B9EB, 01,05/24/07,22:30:01,Stopped,,,,

Isso se repetiu por diversos dias, e sempre no mesmo horário.

Minha primeira ação foi atualizar os binários do DHCP para uma versão mais atual, com um update que atualizasse o arquivo dhcpssvc.dll para uma versão mais atual. a versão na desse arquivo na maquina problemática era 5.2.3790.3959

Instalamos o Kb 950574 - que atualizou o arquivo para a versão 5.2.3790.4257.

Porém no dia seguinte o problema aconteceu novamente, e no mesmo horário!

Essa repetição programada, me fez lembrar de alguma tarefa agendada que pudesse estar rodando todos os dias nesse horário.

Perguntei ao administrador da rede, que me confirmou a existência de um script de backup do DHCP a qual estava justamente programada para aquele horário.

O script em si, parecia inofensivo (e realmente era! Explicarei o porquê depois... mais abaixo) com apenas a seguinte linha:

netsh dhcp server export C:\Scripts\DHCP\servername.txt ALL

Mas quando rodávamos o script manualmente, o serviço não parava!

Depois de muita paciência, identificamos que o comando só causava uma parada no serviço de DHCP após modificarmos algo no DHCP.

Se nada fosse modificado, o script rodava normalmente.

Bom, já descobrimos a causa pelo qual o serviço parava todos os dias pela manhã, mas porquê o inofensivo script de backup parava o serviço de DHCP se alguma modificação fosse realizada na console do DHCP? Além disso as alterações realizadas na console eram perdidas.

A solução de contorno (workaround) era deixar por enquanto essa tarefa desabilitada.

Realizei alguns testes em laboratório e não conseguimos reproduzir este problema. Até que encontramos o seguinte Kb da Microsoft.

http://support.microsoft.com/kb/938134 - After you restart the DHCP Server service, some DHCP options disappear on a Windows Server 2003-based DHCP server

Pensei comigo mesmo, achamos o problema! Intalamos a atualização e retomamos o teste. Nada feito, o problema persistia.

Comecei a imaginar que a database do DHCP estivesse corrompida.

Desfragmentamos a base com o comando: jetpack dhcp.mbd tmp.mdb

Importamos de volta para o DHCP, e após novos testes, o mesmo problema!

Resolvi importar a base do DHCP para um ambiente de laboratório e verificar com mais calma.

Existiam diversos escopos, e verificar um à um foi bem trabalhoso.

Verificando escopo por escopo identificamos uma reserva para o IP 10.226.149.0, o qual seria o endereço de rede para a rede 10.226.149.0/24

Como podemos ver na imagem abaixo:

Excluímos esta reserva do DHCP e o problema foi resolvido. Foi possível executar o script sem que o serviço tivesse que ser iniciado manualmente e as configurações modificadas na console do DHCP foram salvas!

Conclusão:

O script não estava causando o problema. Ele apenas não conseguia realizar o backup da base do DHCP por haver uma configuração errada no DHCP. No nosso caso uma reserva de IP.

A quantidade de escopos neste caso dificultou que verificássemos logo de início uma configuração incorreta do DHCP.

Portanto lembrem-se, caso tenham algum problema similar, verifiquem as configurações do DHCP e se possível documentem, toda e qualquer alteração realizada no ambiente.

Com a documentação em dia, seria fácil verificar a última alteração realizada e rastrear o problema com maior rapidez.

Espero que tenham gostado e que esse artigo possa ajuda-los em um possível troubleshooting de DHCP.

Abraços e até a próxima!

Luciano Brena