Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Windows 2003 Server


8 replies to this topic

sean.smith

sean.smith
  • Members
  • 7 posts

Posted 13 July 2004 - 16:29

Hi,

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.

Thanks,
Sean.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 13 July 2004 - 16:34

I don't think it's an ISWI problem. It looks like your custom action returns some other value than 0. Take a look at the source code of your custom action. maybe a permission problem?

sean.smith

sean.smith
  • Members
  • 7 posts

Posted 13 July 2004 - 17:16

I've put a "return ERROR_SUCCESS;" at the end of each custom action in the "Exceute" sequence and I still get the same problem. I've also inserted message boxes at certain points in the custom action to trace where the custom action is going wrong but it all seems to function properly but the installation still bombs out.

sean.smith

sean.smith
  • Members
  • 7 posts

Posted 13 July 2004 - 17:54

Some more information.

I've removed all custom actions in the "Execute" sequence and created a custom action which calls the following InstallScript function:

function TestCustomActionWin2003Server(hMSI)
begin
MessageBox("Called 'TestCustomActionWin2003Server'.", INFORMATION);
return ERROR_SUCCESS;
end;

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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 13 July 2004 - 20:40

There's a layer of InstallScript engine between MSI and your script. Apparently it is returning 3. Note that the log says it's calling a function in a DLL and the entry point is f9 (not your function name). Try with a DLL custom action. Maybe InstallScript isn't properly running on that machine.

sean.smith

sean.smith
  • Members
  • 7 posts

Posted 14 July 2004 - 10:54

I created a test DLL custom action and it seems to work fine. See below for the log:

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.



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 14 July 2004 - 15:45

I don't think it's a MSI problem. If reinstalling anything would help, then reinstall (or upgrade) the InstallScript engine, not the MSI engine.
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.

sean.smith

sean.smith
  • Members
  • 7 posts

Posted 14 July 2004 - 16:35

I tried removing and re-installing the InstallScript engine (downloaded from http://support.insta...rnelUpdate.exe) but that didn't work. I inserted a message box into the custom action and executes successfully but the install still bombs out.

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.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 15 July 2004 - 04:50

Not sure, but it might be worth checking if your deferred custom actions are run in system context on this computer. I know that computers where the terminal server / service is enabled run all deferred custom actions in system context (terminal installations are crazy, really).

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.

Regards
-Stein Åsmul