VB 6.0 in Terminal Server avvia & # 8220; Preparazione all'installazione di & # 8221; programma di installazione di Windows per utenti non amministratori

Question

Questa potrebbe sembrare una domanda IT, ma la maggior parte delle persone IT che ho chiesto non potevano aiutarmi. Dove lavoro, abbiamo un server Windows 2003 in cui diversi sviluppatori si connettono tramite RDP. Abbiamo declassato i privilegi di alcuni di essi (erano amministratori). E ora quando avviano Visual Basic 6.0 , ottengono Windows Installer " Preparazione all'installazione " dialogo. Scompare dopo circa 2 minuti, ma è un fastidio e una perdita di tempo. Ho provato diverse cose tra cui la ridenominazione di msi.dll in system32 E in dllcache, dando agli sviluppatori il pieno controllo del registro e di c: \ Programmi , ma nulla sembra funzionare.

Qualsiasi aiuto sarebbe apprezzato.

Grazie

Nelson Marmol

Answer 1

Nessuna delle soluzioni fornite qui ha risolto il problema. Grazie per l'aiuto. Dopo alcune ulteriori ricerche, ho trovato questi passaggi su un articolo e questo ha risolto il problema: 1) Vai alla cartella C: \ Windows \ System32 e cerca msi.dll.

2) Rinomina msi.dll con qualsiasi altro nome.

3) Vai alla cartella C: \ Windows \ System32 \ dllcache e rinomina anche msi.dll .

Se non si è eseguito questo passaggio, verrà ricreato automaticamente il file msi.dll nella cartella System32.

Se non riesci a trovare questa cartella dllcache, potrebbe essere necessario modificare una proprietà nelle Opzioni cartella.

In Esplora risorse - > Vai al menu Strumenti - > Seleziona le opzioni della cartella - > Fai clic sulla scheda Visualizza - > Deseleziona l'opzione " Nascondi file protetti del sistema operativo (consigliato) " ;.

4) Avvia VB6 e ora puoi avviare VB6 senza ottenere il messaggio di errore.

5) Rinominare il file in msi.dll nella cartella System32 e nella cartella dllcache .

Answer 2

Proverei a cambiare il modo in cui avviano VB. Crea un collegamento a vb6.exe e utilizzalo al posto del collegamento esistente creato dal programma di installazione.

Answer 3

Avvia ProcessMonitor sul server, imposta un filtro per un determinato utente, quindi procedi al login normalmente. Questo potrebbe mostrare quali autorizzazioni non riescono quando si tenta di accedere a un file specifico.

Answer 4

Rinominare / uccidere il file msi.dll non è la soluzione alla causa di tali problemi, questo solo maschera il problema.

Di solito ci sono due possibili cause:

1. Alcune unità nel Terminal Server, inaccessibili agli utenti non privilegiati, aiutano a consentire l'accesso in lettura a questa cartella radice dell'unità;

2. Qualche componente installato in modo errato (l'ultima volta per me è stato mscomctl32.ocx), ciò che è rilevabile investigando gli eventlog (sebbene di solito sia registrato solo GUID del componente mancante, non è sempre facile trovare quale file reale è mancante / erroneamente registrato).