VB 6.0 in terminal server launches “Preparing to install” windows installer for non admin users

Question

This may seem to be a IT question, but most IT people I asked couldn't help me. Where I work we have a Windows 2003 server where several developers connect via RDP. We downgraded the privileges of some of them (they were admin). And now when they start Visual Basic 6.0, they get the Windows Installer "Preparing to install" dialog. It disappears after about 2 minutes, but it's an annoyance and a waste of time. I tried several things including renaming msi.dll in system32 AND in dllcache, giving the developers full control to the registry and to c:\Program Files, but nothing seems to work.

Any help would be appreciated.

Thanks

Nelson Marmol

Answer 1

None of the solutions provided here fixed the problem. Thanks for your help. After some more research, I found this steps on an article and this fixed the problm: 1) Go to C:\Windows\System32 folder, and look for msi.dll.

2) Rename the msi.dll to any other name.

3) Go to C:\Windows\System32\dllcache folder, and rename msi.dll too.

If you didn't do this step, the msi.dll in System32 folder will automatically be recreated.

If you couldn't find this dllcache folder, you may need to change a property in the Folder options.

In Windows Explorer --> Go to Tools menu --> Select Folder Options --> Click on View tab --> Uncheck the option "Hide protected operating system files (Recommended)".

4) Launch VB6, and now you are able to launch VB6 without getting the error message.

5) Rename the file to msi.dll in System32 folder and dllcache folder.

Answer 2

I would try changing the way that they start VB. Make a link to vb6.exe and use that instead of the existing link created by the installer.

Answer 3

Fire up ProcessMonitor on the server, set up a filter for a particular user login, and then get them to login as normal. This might show you what permissions are failing when trying to access a specific file.

Answer 4

Renaming/killing the msi.dll is not solution to cause of such problems, this just masks problem.

Usually there are two possible causes:

1. Some drive in terminal server, inaccessible to unprivileged users - helps allowing read access to this drive root folder;

2. Some incorrectly installed component (last time for me it was mscomctl32.ocx), what is discoverealble investigating eventlogs (although there is usually recorded only GUID of missing component, it is not always easy to find what real file is missing/incorrectly registered).