Por Alessandro Gonçalves

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.

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.