Hi all,

I guess there really isn't a good area to submit this post so I'll just go with the version of InstallShield I'm using.

Here's my scenario...

We have a 32 bit installer (.msi) that on a 64 bit system will fire off a 64 bit .exe widget stored in the binary table. This widget monitors the currently running .msi process so that, when complete, it can fire off another .msi (native 64 bit installer) that was installed with the 32 bit app.

This additional 64 bit installer was a solution cobbled together under a looming deadline to deliver pieces to native 64 bit areas of the file system and registry. All of this part of our overall install process seems to be working well.

However, we've recently been informed by some users deploying our software with SCCM 2012 that the secondary, 64 Bit installer is not running. Again, that install is kicked off by a widget that waits in the background (while allowing the initial 32 Bit install to complete) then fires off the 64 bit installer. I'm wondering if SCCM, after the parent 32 bit package finishes, kills all process launched from it, thus killing the 64 bit wait and launch widget. Hopefully, if this is the case, there might be a setting that can be tweaked in SCCM to remedy this.

I'm not versed in SCCM deployment, but I will hopefully become so soon, but does anyone have any idea what might be going on to prevent the 64 bit .msi from running?

Any information appreciated and I apologize is this is beyond the scope of this forum.

Thanks in advance!!!
12 Comments   [ - ] Hide Comments


  • The custom action that calls the wait and launch widget is Asynchronous (no wait for completion).
  • Where in the installation sequence is your "widget" fired off? Does it log its activity in the event log or anywhere else? Is the widget 32 bit or 64 bit? Do you have verbose logging enabled in the registry so that you can check whether the 64 bit app has perhaps tried to run but has failed for a reason not related directly to SCCM.
  • The action runs in Deferred Execution sequence after ScheduleReboot. After typing that, I'm wondering if on their systems the installation is requiring reboot. That would tank our current mechanism. I wonder if there is a setting in SCCM for that.

    The widget is 64 bit and we are working on getting some logs.

    I'll have to check into the reboot issue with the customer.

    The unfortunate thing is that we do not have an SCCM environment in house to test so my job isn't going to be easy. Stupid? Believe me, I know!!
  • Here is what I was hoping to do... I would like to leverage ReplacedInUseFiles in my secondary installer firing widget. If set to 1 (reboot required) I would simply write the secondary installer's command line to a RunOnce key so it fires after reboot. If not set, I'll just fire off the install as no reboot was required from the parent so the process won't be killed.

    Here's the issue, what if SCCM is rebooting as part of its process. I'm not sure how I can control that part of things.
  • How does your widget monitor the currently running MSI process? From observation of the task manager while an MSI is installing, it is not unusual for there to be two or three instances of msiexec running, and equally, one instance can remain running even after the install has completed. For a totally different requirement to yours, I once coded an app which monitors MSIEXEC activity, but I used the premise of there being MORE THAN one instance of msiexec in the task list as an indicator of an active MSI installation taking place. Once it reverts to a single instance, the next install can be started.
  • Additionally, it is possible in a 32 bit MSI to create components with a 64 bit attribute. You could try doing this and using the VersionNT64 property as a condition on these 64 bit components to determine when they need to be installed.
  • Yes, I search for the single instance of msiexec to start the next install.

    I use InstallShield and I don't believe it is possible to mark a component as 64 bit when the template summary property is set for 32 bit.
  • I created a small dummy install that places a Hello World win form app. I simply start the app then run an updated installer over top to force the file in use issue. In this install, I eventually got it to function by adding an InstallExecute action immediately following ScheduleReboot. Then, after the InstallExecute action, I created an Immediate Execute custom action that grabbed ReplacedInUseFiles and set a new Public Property to its value.

    I pass this new Public Property to my Execute Deferred .exe and it seems to work great.

    Now, using this as a model, I add this stuff to my 'real' installation template, compile and test - no go!!! The deferred .exe is not really getting the correct value as the Immediate Action does not seem to be getting the correct value of ReplacedInUseFiles. This would again indicate that it has not been set/detected files in use. The property is set to 1 in the verbose log.

    I have no idea what is going on AGAIN! There has got to be an easier way to determine if a reboot is needed.

    So, still looking for help!
  • Here's is where I am at currently... I'm trying to test my latest changes and I answer No to close apps on the Restart Manager dialog, which should require a reboot. From the log it seems to set the associated RestartManagerOption property to Reboot.

    However, later in the log, it indicates that ScheduleReboot is skipped as the condition is false. The condition on my ScheduleReboot action is ISSCHEDULEREBOOT. I don't know why this isn't getting set properly to trigger the reboot. ???

    My test consists of installing an earlier version, launch one of the .exe then initiate a Major Upgrade. This does see the file in use and displays the Restart Mgr dialog as mentioned.
  • I think I may have stumbled onto something. I first thought maybe Restart Manager was doing something funky causing the need for reboot not to be there in the end. However, I think I may have found something...

    What happens if a user does not shut down the app thus the files remain in use?

    A verbose log will include one or more of the errors 1603, 1732, 1902, 1903, 3010 (per Logging of Reboot Requests [Windows Installer], Windows Installer Error Messages [Windows Installer] and Error Codes [Windows Installer]). If the file isn’t hard locked, then the windows installer will move the in use file to the rollback cache and place the new file in the place of the in use file. If the move to the rollback directory is blocked (by hard locking) the PendingFileRenameOpertions hive is used. For the former case, shutting down and restarting the app is required. For the latter case, rebooting the OS is required.

    I'm guessing the app file I launch to hopefully cause a reboot condition is being moved to the roll back cache.

    Now to figure out how to cause a hard lock condition so I can test my changes if a reboot is really prompted.
  • Here's the latest in the saga....

    On several machines, I've noticed the following message on uninstalls while trying to test my other changes...

    "The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup."

    If OK is selected, the uninstall runs to completion with no reboot.

    I do see in the log that a need for reboot has been detected, but I don't see any clue as to what may be triggering this need. I search for some related error codes like 1603, 1732, 1902, 1903, 3010, but nothing. There are also no services as part of this app install/uninstall.

    All of my reboot changes posted earlier are conditioned to run if Not Installed and VersionNT64 so I don't believe any of my changes are coming into play here. I even tested this by using an early backup that didn't contain any related reboot handling changes and received the same result.

    I then thought that Restart Manager might be doing something 'funky'. I added MSIRESTARTMANAGERCONTROL=1 to the Property table, installed then uninstalled = NO MESSAGE!

    So, it appears Restart Manager is involved. I could simply set the control property as stated above and be done with it an simply rely on the older Files In Use mechanism, but I would like to know what is causing the issue on some machines. I'm perplexed as to what Windows Installer is detecting as in on uninstall. I was hoping the log would show, but nope.

    Any help appreciated!!
  • What are the pros/cons of disabling Restart Manager?
Please log in to comment

There are no answers at this time
Answer this question or Comment on this question for clarity