Problemas ao abrir o Server Manager no Win 2K8 R2

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???

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

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!

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