cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rgh184
Level 3

MAINTENANCE mode issues

Hello,

I was recently put in charge of the installer for one of our products and was charged with adapting the installer for the new version. Our product is always upgraded, never installed cleanly. We sell the hardware with the suite preloaded. This version that is being built is the first one to use IS 2008, previously, we were on DevStudio 9. I upgraded the previous versions installer to IS 2008 and added components for any new files, etc. The installer is working fine, except it always thinks it is in maintenance mode. I have changed the Package and Product GUIDs. I was under the impression that it was these GUIDs that trigger maintenance mode if they show as already being installed. The upgrade goes fine, except that in the installscript, there are several sections that are triggered during an installation of a new version, but not if the user is doing an overlay install of the same version. For example, we have a registry value that indicates the currently installed version of the product. On the first installation of a new version (i.e. NOT maintenence mode), we want that reg key to be updated at the end of the upgrade. The Installscript that updates that reg key (and all other post-installation tasks) is inside a block that beings with "if (!MAINTENENCE)"

I am simplifying somewhat, but I basically need to figure out why the installer thinks it is maintence mode all the time, even when this is the first time this version has been installed on a given machine.

Thanks,
Reed
Labels (1)
0 Kudos
(6) Replies
rgh184
Level 3

Can anyone point me in the right direction on this? All I am really looking for is what will trigger maintenance mode in this situation.

Thanks
0 Kudos
esiemiat
Level 9

Is this a pure InstallScript project? If so, then leave the GUID alone and just change the version number.
0 Kudos
rgh184
Level 3

Unfortunately, it is not pure installscript. There are many DLLs that are loaded as components. There are several prerequisites as well. The version number has been changed from 8.0.5.7 to 10.0.0.1. Instinct is telling me that this might have something to do with the options that are set in the Upgrades view. Can anyone give me a quick overview of this view and how it relates to maintenance mode?

Thanks again,
Reed
0 Kudos
Kelter
Level 10

You'll want to add an Upgrade Item to the upgrades view to identify the upgrade GUID of the products that you want to upgrade, and you'll want to test the IS_MAJOR_UPGRADE property instead fo the "MAINTENANCE" property.

The help documentation on upgrades is pretty concise. KLook for "Preventing the Current Installation from Overwriting a Future Major Version of the Same Product" in your help.
0 Kudos
Sairen
Level 7

rgh184 wrote:
The Installscript that updates that reg key (and all other post-installation tasks) is inside a block that beings with "if (!MAINTENENCE)"


This may have just been a typo, and I'm certainly not here trying to start a grammar flame - goodness knows I've spent hours tracking down sillier things... but if that's the exact text of your block, it may help to note that the spelling would be (!MAINTENANCE)...

Best wishes with your problem.
0 Kudos
rgh184
Level 3

Sairen, you gave me a teasing glimmer of hope, as I always mistype that word, but alas, it is spelled correctly.

Kelter, I will look into your suggestion, It seems promising.

I also discovered something else somewhat odd. Elsewhere in my installscript, there is a function that writes all kinds of IS properties to the logfile: Product Name, Version, MAINTENANCE, CMDLINE, etc. It is called twice during the course of an upgrade and the first time, right at the beginning, everything is as you would expect:


1: *********** 11-9-2007 11:23:13: setup.rul, Line 99
1: ** INFO ** OnBegin(), Start
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 35
1: ** INFO ** ExFn_InitializeSetup(), Start
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 168
1: ** INFO ** Setup Info: Product Name = (OBFUSCATED)
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 176
1: ** INFO ** Setup Info: Product Version = 10.0.0.1
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 185
1: ** INFO ** Setup Info: MAINTENANCE = FALSE
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 188
1: ** INFO ** Setup Info: CMDLINE = /verboseC:\MercurySoftware.log /v"REINSTALLMODE=vaums REINSTALL=ALL"
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 191
1: ** INFO ** Setup Info: DISK1TARGET = C:\Program Files\InstallShield Installation Information\{ACC998E8-EF24-4091-BB96-A058FD2D2A1C}
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 204
1: ** INFO ** Setup Info: MODE = NORMALMODE
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 207
1: ** INFO ** Setup Info: SRCDIR = D:\
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 210
1: ** INFO ** Setup Info: SUPORTDIR = D:\
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 213
1: ** INFO ** Setup Info: INSTALLDIR = C:\Program Files\Wings\
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 221
1: ** INFO ** Setup Info: REINSTALLMODE = vaums
1: ***********
1: *********** 11-9-2007 11:23:13: mercury_commonfunctions.rul, Line 229
1: ** INFO ** Setup Info: REINSTALL =
1: ***********


And the second time, Its run right before the block of code I want to execute is skipped due to it being in MAINTENANCE mode:


1: *********** 11-9-2007 11:33:07: mercury_customactions.rul, Line 87
1: ** INFO ** ExCa_MercuryPostInstallTasks(), Start
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 168
1: ** INFO ** Setup Info: Product Name = (OBFUSCATED)
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 176
1: ** INFO ** Setup Info: Product Version =
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 185
1: ** INFO ** Setup Info: MAINTENANCE = TRUE
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 188
1: ** INFO ** Setup Info: CMDLINE =
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 191
1: ** INFO ** Setup Info: DISK1TARGET = C:\Program Files\InstallShield Installation Information\
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 204
1: ** INFO ** Setup Info: MODE = NORMALMODE
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 207
1: ** INFO ** Setup Info: SRCDIR = C:\DOCUME~1\admin\LOCALS~1\Temp\{E072E72D-E42A-41F7-AA5E-973A57090AA0}\
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 210
1: ** INFO ** Setup Info: SUPORTDIR = C:\DOCUME~1\admin\LOCALS~1\Temp\{E072E72D-E42A-41F7-AA5E-973A57090AA0}\
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 213
1: ** INFO ** Setup Info: INSTALLDIR =
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 221
1: ** INFO ** Setup Info: REINSTALLMODE =
1: ***********
1: *********** 11-9-2007 11:33:07: mercury_commonfunctions.rul, Line 229
1: ** INFO ** Setup Info: REINSTALL =
1: ***********


Now this is strange for several reasons: First, the CMDLINE property seems to have changed. I didn't think this was possible. Second, it doesn't seem to be getting the product version information correctly the second time around. And third, it seems as though the MAINTENANCE property has changed. How is this possible?

The only thing I can think of is that, during an upgrade, our installer set the system to auto-login to a known windows account and the restarts itself with the CMDLINE properties as seen in the first block. So I guess its possible that the first time this logging function is run, it is during the first instance of setup being run, and the second is during the second.

This all worked correctly in the last version of the product. I haven't changed much beyond upgrading the installer from DevStudio 9 to IS 2008 Pro and adding some new pre-reqs and adding a few new single-dll components.

Kelter, I will report back on weather your idea worked and if anyone else ans any thoughts on this given all this new information, I would greatly appreciate any help.

Thanks again and sorry for the delay in responding (was in the hospital and not looking at this for a few weeks)
0 Kudos