VB 6.0 em lançamentos de servidor de terminal “Preparando para instalar” Windows Installer para usuários não administrativos

Question

Esta pode parecer ser uma questão de TI, mas a maioria das pessoas que eu pedi não poderia me ajudar. Onde eu trabalho temos um servidor Windows 2003 , onde vários desenvolvedores conectar via RDP. Nós rebaixou os privilégios de alguns deles (eles foram admin). E agora, quando eles começam a Visual Basic 6.0 , eles obter o Windows Installer "Preparando para instalar" diálogo. Ele desaparece após cerca de 2 minutos, mas é um aborrecimento e um desperdício de tempo. Tentei várias coisas, incluindo a renomeação msi.dll em system32 e, em dllcache, dando aos desenvolvedores controle total para o registro e para c: \ Program Files , mas nada parece funcionar.

Qualquer ajuda seria apreciada.

Graças

Nelson Marmol

Answer 1

Nenhuma das soluções fornecidas aqui corrigiu o problema. Obrigado pela ajuda. Após mais algumas pesquisas, descobri esses passos em um artigo e este fixa o problm: 1) Vá para pasta C: \ Windows \ System32, e olhar para msi.dll

.

2) Renomeie o msi.dll a qualquer outro nome.

3) Vá para C: \ Windows \ System32 \ dllcache pasta, e renomear msi.dll muito

.

Se você não fez esta etapa, o msi.dll na pasta System32 será automaticamente recriado.

Se você não poderia encontrar este dllcache pasta, você pode precisar alterar uma propriedade nas opções de pasta.

No Windows Explorer -> Ir para o menu Ferramentas -> Selecionar Opções de Pasta -> Clique na guia View -> Desmarque a opção " Ocultar arquivos protegidos do sistema operacional (recomendado) ".

4) Lançamento VB6, e agora você é capaz de VB6 lançamento sem receber a mensagem de erro.

5) Renomeie o arquivo para msi.dll na pasta System32 e dllcache pasta.

Answer 2

Gostaria de tentar mudar a maneira que eles começam VB. Faça um link para VB6.exe eo uso que em vez da ligação existente criado pelo instalador.

Answer 3

Fire-se ProcessMonitor no servidor, configurar um filtro para um determinado login do usuário, e, em seguida, levá-los a entrar como normal. Isso pode mostrar o que as permissões estão falhando ao tentar acessar um arquivo específico.

Answer 4

Renomear / matar o msi.dll não é solução para a causa de tais problemas, este máscaras apenas problema.

Normalmente, há duas causas possíveis:

1. Alguns unidade no servidor de terminal, inacessível para os usuários sem privilégios - ajuda a permitir o acesso de leitura para esta pasta raiz da unidade;

2. Alguns componente instalado incorretamente (última vez para mim foi mscomctl32.ocx), o que é discoverealble investigando eventlogs (embora geralmente é gravado apenas GUID do componente em falta, nem sempre é fácil encontrar o arquivo real é faltando / registrado incorretamente).