I've switched some functionality in a BasicMSI project to use VBScript for some CA's.
Some of our customers with XP, Vista and 7 are getting a VBScript error 2738 during install, blocking the install. It's a small percentage.
Looking the error up, it was suggested to delete a reg key (which doesn't exist) and run a regsvr32 on the vbscript exe/dll.
I don't think the VBScripts themselves are a problem, or they would bomb for everyone.
The basic premises of the scripts are to copy files from one folder to another and edit an INI file. While these were in Installscript before, it looks like Installscript doesn't support logging to MSI. So the VBScript logs some info for what files are copied.
Any ideas on how to resolve or further troubleshoot?
To copy files from one folder to another, RemoveFile Table could be an appropriate option. To change INI files, INI File Changes View may do what you want.
Besides the recommendation of using RemoveFile/MoveFile tables and INI File Changes for simple delete, copy/move, and INI changes, it should be noted that a VBScript custom action can behave unpredictably and be rather difficult to determine causes of errors on target machines: VBScript (and Jscript) MSI CustomActions suck - http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx
So a script that seems to run fine on its own or as part of a custom action on one machine can behave completely different on some other machine due to the environment. One thing you may try is disabling any antivirus utilities on the machines where the script is failing. As the above article notes, these applications can cause VBScript actions to fail since they block the script from executing.
Also, on a side note, information can be written to an MSI log in InstallScript custom actions with the SprintfMsiLog function (assuming the action isn't running from a dialog control DoAction event; this is a general limitation imposed on all custom action types due to how the MsiProcessMessage API works).
InstallShield provides a front-end/designer for a number of Windows Installer features, including things like VBScript custom actions. Unfortunately, though, limitations and issues with the Windows Installer cannot controlled by InstallShield beyond the data that is populated in the tables of a built MSI package. Issues in the Windows Installer such as those with VBScript actions have existed for years (the previously linked MSDN blog article is from 2004). Other issues such as those with nested MSI custom actions have even caused Microsoft to officially deprecate such functionality. However, even in this case, all functionality is still available to ensure old MSI packages continue to function as before.
In general, the simpler an installation is, the more resilient it will be against possible failures. VBScript actions tend to introduce a layer of complexity (as do any custom actions that runs code not part of MSI) that increase the number of possible failure points in the install, and are especially subject to interference by other software (antivirus software in particular) on target machines. With VBScript actions, there is an added downside that results in being unable to apply normal troubleshooting and debugging disciplines to resolve the issue through the script itself.
When custom actions are necessary, we would recommend MSI DLL, EXE, or (if allowable) InstallScript custom actions since they can be more easily debugged and are in your direct control (in the case of DLLs or EXEs). (In the case of InstallScript actions, we have the ability to resolve any issues caused by our code when bugs are reported, unlike issues with Windows Installer engine functionality which we do not own.)
