VB 6.0 en Terminal Server lanza el instalador de Windows "Preparándose para instalar" para usuarios que no son administradores

Question

Esto puede parecer una pregunta de TI, pero la mayoría de las personas de TI que pregunté no pudieron ayudarme. Donde trabajo, tenemos un servidor Windows 2003 donde varios desarrolladores se conectan a través de RDP. Bajamos los privilegios de algunos de ellos (eran administradores). Y ahora, cuando inician Visual Basic 6.0 , obtienen el instalador de Windows " Preparándose para instalar " diálogo. Desaparece después de unos 2 minutos, pero es una molestia y una pérdida de tiempo. Probé varias cosas, incluido el cambio de nombre msi.dll en system32 Y en dllcache, dando a los desarrolladores el control total del registro y c: \ Archivos de programa , pero nada parece funcionar.

Cualquier ayuda sería apreciada.

Gracias

Nelson Marmol

Answer 1

Ninguna de las soluciones proporcionadas aquí solucionó el problema. Gracias por tu ayuda. Después de algunas investigaciones más, encontré estos pasos en un artículo y esto solucionó el problema: 1) Vaya a la carpeta C: \ Windows \ System32 y busque msi.dll.

2) Renombra msi.dll a cualquier otro nombre.

3) Vaya a la carpeta C: \ Windows \ System32 \ dllcache y cambie el nombre de msi.dll .

Si no hizo este paso, la msi.dll en la carpeta System32 se volverá a crear automáticamente.

Si no pudo encontrar esta carpeta dllcache, es posible que deba cambiar una propiedad en las opciones de Carpeta.

En el Explorador de Windows - > Ir al menú Herramientas - > Seleccione Opciones de carpeta - > Haga clic en la pestaña Ver - > Desmarca la opción " Ocultar archivos protegidos del sistema operativo (recomendado) " ;.

4) Inicia VB6, y ahora puedes iniciar VB6 sin recibir el mensaje de error.

5) Cambie el nombre del archivo a msi.dll en la carpeta System32 y en la carpeta dllcache .

Answer 2

Intentaría cambiar la forma en que comienzan VB. Cree un enlace a vb6.exe y utilícelo en lugar del enlace existente creado por el instalador.

Answer 3

Abra ProcessMonitor en el servidor, configure un filtro para un inicio de sesión de usuario en particular, y luego haga que inicien sesión de manera normal. Esto podría mostrarle qué permisos fallan al intentar acceder a un archivo específico.

Answer 4

Cambiar el nombre / matar el msi.dll no es una solución para la causa de tales problemas, esto simplemente enmascara el problema.

Usualmente hay dos causas posibles:

1. Algunas unidades en el servidor de Terminal Server, inaccesibles para usuarios sin privilegios, permiten el acceso de lectura a esta carpeta raíz de la unidad;

2. Algunos componentes instalados incorrectamente (la última vez para mí fue mscomctl32.ocx), lo que es descubrible puede investigar los registros de eventos (aunque generalmente solo se registra GUID del componente faltante, no siempre es fácil encontrar qué archivo real es faltante / registrado incorrectamente).