Windows Script custom actions should be avoided. They are difficult to debug, get blocked by virus scanners, and are far more susceptible to machine state than native custom actions. That is indicated by Windows Installer error messages 2738 and 2739, which read:
2738, Could not access VBScript run time for custom action [2].
2739, Could not access JScript run time for custom action [2].
As some people have found, re-registering the runtime libraries vbscript.dll and jscript.dll will fix the errors, but that isn't always the solution.
As a security measure, Windows Installer will not load script engines registered in HKEY_CURRENT_USER. As a user-writable store, a normal user could get an elevated install to run their library masking as a script engine if the custom action was not explicitly attributed with msidbCustomActionTypeNoImpersonate (0x0800). This is an elevation of privileges attack; thus, Windows Installer returns error message 2738 or 2739 for custom actions type 6 and type 5, respectively, and returns Windows error 1603, ERROR_INSTALL_FAILURE.
Check that vbscript.dll and jscript.dll aren't registered in HKEY_CURRENT_USER (HKCU), checking for the registry keys below.
VBScript, HKCU\SOFTWARE\Classes\CLSID\{ B54F3741-5B07-11CF-A4B0-00AA004A55E8}
JScript, HKCU\SOFTWARE\Classes\CLSID\{ F414C260-6AC0-11CF-B6D1-00AA00BBBB58}
Remove these keys if they exist in HKEY_CURRENT_USER.
Also be sure that if you need to re-register vbscript.dll or jscript.dll, you run regsvr32.exe in an elevated console on Windows Vista and newer with UAC enabled; otherwise, you'll end up registering the runtimes in HKCU.
http://www.telcan.com/