Oops!! Onde está a conexão de rede?
Mais uma vez , um incidente que parecia simples de ser solucionado acabou por se tornar algo interesssante, que indica o quão abrangente os nossos conhecimentos necessitam ser para que possámos solucionar problemas com sucesso.
Tudo começou com um chamado , onde o problema estava corretamente definido; os ícones da placa de rede desapareceram das propriedades do Network Neighborhood. No início me pareceu simples e indiquei ao cliente o seguinte artigo de suporte - 825826 How to troubleshoot missing Network Icons in Windows Server 2003 and Windows XP .
Mas como tudo que parece muito fácil , as vezes nos surpreende e temos que exercitar os nossos conhecimentos e processos de resolução de problemas. E claro que o incidente não foi resolvido ao aplicar os passos do artigo de suporte.
Como o escopo está bem definido, vamos partir para coletar dados que nos deêm pistas da causa do comportamento . Iniciei por abrir o msinfo32 para verificar se os componentes de rede podem ser observados , mas para minha surpresa nada estava listado lá , indicando um possível problema com o WMI. Com essa pista parti para testar o WMI , podemos começar por tentar conectar com o repositório ao utilizar o computer management e selecionar o WMI Control , ao fazer isso recebemos uma mensagem de acesso negado. Para comprovar o estado do WMI utilizei o WMIDiag , o resultado foi o seguinte:
.1454 11:29:00 (1) !! ERROR: WMI CONNECTION errors occured for the following namespaces: .................................................. 5 ERROR(S)!
.1455 11:29:00 (0) ** - Root, 0x80070005 - Access is denied..
.1456 11:29:00 (0) ** - Root, 0x80070005 - Access is denied..
.1457 11:29:00 (0) ** - Root/Default, 0x80070005 - Access is denied..
.1458 11:29:00 (0) ** - Root/CIMv2, 0x80070005 - Access is denied..
.1459 11:29:00 (0) ** - Root/WMI, 0x80070005 - Access is denied.
Com certeza temos um problema com permissão , todavia o lugar ainda é desconhecido. Antes de partir para as ferramentas do sysinternals , decidi coletar mais dados.
Habilitei o verbose logging do WMI no próprio WMI Control , reiniciei os serviços de WMI ( net stop winmgmt && net start winmgmt ) e verifiquei os logs do serviço ( %windir%\system32\WBEM\logs).
Ao verificar um dos arquivos , wbemprox.log , uma mensagem chamou atenção:
ConnectViaDCOM, CoCreateInstanceEx resulted in hr = 0x80070005
Mais uma vez , acesso negado . No system log também verifiquei:
Event ID: 512
Source: CryptSvc
Description:
The Cryptographic Services service failed to initialize the VSS backup "System Writer" object.
Details:
System Writer object failed to subscribe to VSS.
Chegou a hora de fazer um LIVE Search por - ConnectViaDCOM, CoCreateInstanceEx resulted in hr = 0x80070005 - e um artigo chamou a atenção ao mencionar problemas com COM+ e MSDTC - kb 909444 - e menciona as mensagens observadas .
Basicamente comenta por permissão em uma pasta chamada REGISTRATION , que impede que aplicações COM acessem o catálogo , pois antes do MS05-051 permissões explícitas a pasta não eram necessárias mas agora são.
Ao verificar a pasta em questão %windir%\registration , as permissões não estavam configuradas de acordo com o artigo.
Administrators |
System |
Everyone |
Authenticated users |
Server operators |
|
Windows 2000 Non-Domain Controller |
Full Control |
Full Control |
Read |
||
Windows 2000 Domain Controller |
Full Control |
Full Control |
Modify |
Read & Execute |
|
Windows Server 2003 Non-Domain Controller |
Full Control |
Full Control |
Read |
||
Windows Server 2003 Domain Controller |
Full Control |
Full Control |
Read & Execute |
Prossegui com a configuração das permissões e após um reinício do servidor os ícones voltaram a ser visualizados.
O que podemos tirar deste exemplo , é que a maioria dos problemas podem ser resolvidos pela simples ação de coletar dados e se concentrar no comportamento e dados apresentados.
Espero que tenham apreciado a leitura e obrigado pela visita.
Comments
- Anonymous
July 01, 2008
Muito bom! Gostei do "Step to step" Abrazo.