0

I'm trying to install a package on a Windows 2008 server. The package is refusing to install. I have run the install with the following command line switched to get a log file:

/lxv InstallLog.txt

This is the error that I see in the file:
Error 2738.Could not access VBScript run time for custom action

I have looked around and found some people saying that this is needed:
Regsvr32 vbscript.dll

This because on a Windows Server 2008 system, the VBScript.dll is not registered for the HKeyCurrent_User only the HKeyLocal_Machine due to security issues. This doesn't quite "smell" right.

I initially tried running the install as an administrator but no luck.
I have written a small VBScript program that displays a message box and it appears to run properly. In the file: Test.VBS I have this:

msgbox("Hello world")

When I double click on it I get a message box appearing implying that VBScript is indeed functional.
I have disabled UAC on the machine and I still get the error.

As suggested by Evan I have verified the following registration:

HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}

It does exist and looks fine.
As another test, I ran the Regsvr32 vbscript.dll from an Administrator console and tried again. Still no luck, I get the same errors as before.

John Dyer
  • 725
  • 1
  • 10
  • 12

2 Answers2

1

VBScript for custom actions is bad form. You should slap around whoever made that installer package.

Have you double-checked that the following registry key doesn't exist:

HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}

Secondly, when you ran the "REGSVR32 vbscript.dll" command, did you do so from an elevated command-prompt?

The reason that MSIEXEC won't load a VBscript.dll registered in HKEY_CURRENT_USER is that MSIEXEC is running elevated, and an unprivileged user could, potentially, register a trojan-horse VBscript.dll and use that as a mechanism to execute code in an elevated context. It's a security feature, and not a mistake.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 1
    I have been holding off on running "REGSVR32 vbscript.dll" because it just doesn't seem right. I'm trying to not mess around too much so that I know what exactly fixes the issue in the end. – John Dyer Jun 30 '09 at 21:32
  • +1 for changing one thing at a time. You're safe to run the "REGSVR32 vbsript.dll" from an elevated command prompt because you can easily undo it. If that doesn't resolve the issue, a "REGSVR32 /u vbscript.dll" will undo the changes made. I predict, however, that you'll find that the installer works fine after doing that from an elevated command-prompt. Make the change, try the install, and if it fails, back-off the registration with the "/u" version of the command. – Evan Anderson Jun 30 '09 at 21:44
0

Did you run the install as "an administrator" or "the administrator"? If the former then it's probably UAC interfering. Log in as Administrator and rerun the installation.

This problem is cropping up a lot on ServerFault these days. If you insist on using UAC on a (non-Terminal) Server then logging in as Administrator is the easiest way to avoid this sort of problem.

JR

John Rennie
  • 7,756
  • 1
  • 22
  • 34
  • The domain account I'm using is also a local administrator on the machine. – John Dyer Jul 01 '09 at 09:27
  • If UAC is on then just being a member of the local administrators group does not give you the same privileges as the local administrator account. Strange but true. Try logging on as the local administrator instead of some domain account that happens to be in the local administrators group. – John Rennie Jul 01 '09 at 09:35
  • As stated above, I disabled UAC and it still would not install. However, I took your advice and logged in as a local user in the Administrator group and then the install worked. I'm at a loss as to why a domain user in the Administrator group would be any different from a local user in the Administrator group. Why would some Administrators be different that others? – John Dyer Jul 01 '09 at 15:56