Windows 2003 Server
Posted 13 July 2004 - 16:29
I'm having problem with performing upgrades on Windows 2003 Server with our installs.
Our installs are currently being built with ISWI 1.52 but when I go to do an upgrade on Windows 2003 Server the install bombs out when it reaches the first custom action in the "Execute" sequence. The following is an excerpt from the log produced by one of the installs:
Action start 15:46:04: SetWebServerEnvironmentVariables.
MSI (s) (28:A4): Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI127D.tmp, Entrypoint: f8
Action ended 15:46:10: SetWebServerEnvironmentVariables. Return value 3.
Action ended 15:46:10: INSTALL. Return value 3.
Clean installs work fine and both clean installs and upgrades work fine on Windows 2000. Has anyone seen this problem before? Is ISWI 1.53 supported on Windows 2003 Server? Any help will be gratefully received.
Posted 13 July 2004 - 16:34
Posted 13 July 2004 - 17:16
Posted 13 July 2004 - 17:54
I've removed all custom actions in the "Execute" sequence and created a custom action which calls the following InstallScript function:
MessageBox("Called 'TestCustomActionWin2003Server'.", INFORMATION);
Initially I chose to not ignore the return code and the install bombed out at the end. The following is the extract from the log:
MSI (s) (3C:20): Doing action: TestCustomActionWin2003Server
Action start 17:53:13: TestCustomActionWin2003Server.
MSI (s) (3C:88): Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3743.tmp, Entrypoint: f9
Action ended 17:53:16: TestCustomActionWin2003Server. Return value 3.
Action ended 17:53:16: INSTALL. Return value 3.
Where does the return code "3" come from if I return "ERROR_SUCCESS"? I then chose to ignore the return code and the install completed successfully but I'd rather not have to ignore the return code.
Posted 13 July 2004 - 20:40
Posted 14 July 2004 - 10:54
MSI (s) (90:88): Doing action: Test
Action start 10:50:23: Test.
MSI (s) (90:B0): Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI1277.tmp, Entrypoint: Test
Action ended 10:50:23: Test. Return value 1.
I would like to stay away from converting all the InstallScript custom actions to DLL custom actions. Also why does the InstallScript custom action work when it is a clean install but not when performing an upgrade? You say InstallScript isn't properly running on the machine but how do I tell if it is? Would a re-install of Windows Installer fix any problems? The version of Windows Installer shipped with Windows 2003 Server is version 2.0.3790.0 but I can't find this version (or a later one) on the Microsoft website. Do you know where I can get this version? The latest version that I can get is 2.0.2600.2.
Posted 14 July 2004 - 15:45
I have no idea why the script function would fail. It could be a permission problem or whatever. Did you try the debugger? Can you reproduce the problem in the latest version (InstallShield X)? Remeber that ISWI was released long before Windows 2003, so it may simply not work properly.
Posted 14 July 2004 - 16:35
We have resisted upgrading to newer versions of InstallShield as newer versions are not backward compatible with the ISWI 1.52 project files. I will try and create an install with Developer 8 and see if that works.
Posted 15 July 2004 - 04:50
A deferred custom action doesn't have access to the installation database in the first place so it cannot retrieve property values unless they are written into the execution script using the ActionProperty feature. In addition, when a deferred action is run in system context you are running the action with the LocalSystem account. This means no user context, so no HKCU, no mapped drives, in short nothing user specific.
My guess is that you are either accessing HKCU, trying to resolve a path that resolves to nothing given that you are in system context, or in a similar manner try to run something that the LocalSystem account cannot run, or is trying to run with an invalid path.
You can detect a server with Terminal Services using the TerminalServer property. Rather than testing this all at once by rewriting the whole custom action and the setup, try adding (Not TerminalServer) to the offending custom action to prevent it from running on Terminal Server.
Finally, if you need the setup to run on a terminal server, there are a number of special settings for custom actions that can only be set using Orca or the direct editor (the Installshield IDE cannot set these).
For more info check out the SDK and "Using Custom Actions on a Terminal Server": http://msdn.microsof...inal_server.asp
Edited by Glytzhkof, 15 July 2004 - 04:54.