O que poderia estar causando o MsiInstaller a reconfigurar continuamente os aplicativos (EventID 1035)?

4

Eu tenho uma máquina novinha em folha que acabamos de instalar o Windows Server 2008 Enterprise há cerca de dois meses. No log de eventos, estou vendo milhares de eventos do EventID 1035 registrados. Este é o MsiInstaller reconfigurando cerca de uma dúzia de produtos repetidamente, fazendo loop a cada meia hora.

Alguém viu isso? Inicialmente, fiz uma pesquisa geral na Web e a maioria das soluções girava em torno do Dell System Center ou da barra de ferramentas do Google que estava sendo instalada como o culpado.

Não temos nenhum desses produtos instalado.

Obrigado pela sua ajuda,

Dale

    
por user7862 20.07.2009 / 19:07

3 respostas

4

UPDATE :

O Windows Installer possui " auto-reparo " para aplicativos instalados. Em essência, isso significa que ele continuará verificando se os arquivos no disco e as configurações no registro correspondem ao que o respectivo pacote instalou originalmente. Essas verificações geralmente não são executadas para tudo o que o pacote instalou, mas para o que é chamado de "caminhos chave ".

Em situações em que você vê autorrecuperação sendo executado em ciclos , geralmente significa que algum processo no sistema ou outro MSI alterou as configurações no sistema que o pacote que posteriormente auto-repara também mudou. Como o cara disse, é como um umidificador e um desumidificador lutando na mesma sala - ou um cachorro perseguindo a própria cauda. Você não chega a lugar nenhum até que o conflito seja encontrado e eliminado. O arquivo MSI vai continuar "este é o meu recurso, estou mudando de volta" de novo e de novo.

O que é necessário é identificar o conflito que os arquivos MSI ou processos do sistema estão discutindo: link .

Existem também outros erros de design nos arquivos MSI que podem acionar o mesmo problema, como caminhos-chave configurados para caminhos codificados específicos do usuário: C: \ Documents and settings \ usuário1 \ Desktop . Este caminho não será encontrado para outro usuário que estiver efetuando logon e para os resultados de reparo automático. Outro exemplo são caminhos-chave definidos para pastas que não são graváveis para a conta do sistema. Outro exemplo ainda é um caminho de chave definido para um arquivo temporário (que o sistema excluirá eventualmente).

Como você pode ver, há muitos cenários, mas sempre o mesmo problema: um arquivo MSI verifica se a instalação atual está correta e encontra uma discrepância que, então, tenta corrigir.

    
por 20.09.2009 / 21:43
3

Após uma pesquisa difícil, encontramos este artigo da base de conhecimento da Microsoft , indicando que essas mensagens podem ser geradas pelo filtro de diretiva de grupo OU pelo aplicativo consultando a classe WMI Win32_Product. Infelizmente, restringir qual aplicativo está causando o problema é difícil.

    
por 16.03.2012 / 08:57
2

Posso confirmar que o problema é acionado por consultas WMI para a classe Win32_Product. Mas como documentado nesta outra questão abaixo, você não pode usar o Win32reg_AddRemovePrograms se você não tiver o SCCM / SMS instalado e mesmo que você precise usar o Win32reg_AddRemovePrograms64 para obter uma lista de programas de 64 bits

link

Nada disso foi documentado antes como algo ruim, na verdade, como a maneira correta de fazê-lo. Eu acho que a escolha da Microsoft para fazer uma verificação de reparo, ao mesmo tempo em que responde à consulta, é apenas um design ruim. Uma consulta nunca deve causar alterações em um sistema, que deve ser uma "função" diferente (método WMI). Um projeto sensato poderia ter incluído uma verificação periódica na sua "manutenção do sistema" dos novos sistemas operacionais, porque isso também é configurável e faz sentido para os usuários / administradores.

De qualquer forma, este era um servidor antigo, na verdade prestes a ser descomissionado (Windows 2003 de 64 bits). Mas isso aconteceu em todos os nossos servidores por muitos anos (que foi um grande sucesso para o desempenho agora está confirmado). Então, terei que verificar novamente nos servidores mais recentes do 2008 R2 para ver se isso será um problema de produção em andamento ou não.

Mas o que realmente me pergunto é como explicar às equipes de empacotadores e engenheiros de suporte que eles não devem usar essa consulta / API do WMI. Temos centenas de scripts e ferramentas escritos por muitas pessoas diferentes para milhares de pacotes. Não tem como isso acontecer. Portanto, esse comportamento deve ser corrigido como uma falha de design crítica pelo MS, se ainda estiver ocorrendo em 2008 R2 e em outras versões de sistema operacional suportadas. Nós certamente vamos escalá-lo se ainda for o caso!

    
por 24.10.2013 / 21:42