Systems Management

The custom action that calls the wait and launch widget is Asynchronous (no wait for completion). - Superfreak3 10 years ago

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. - EdT 10 years ago

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!! - Superfreak3 10 years ago

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. - Superfreak3 10 years ago

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. - EdT 10 years ago

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. - EdT 10 years ago

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. - Superfreak3 10 years ago

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! - Superfreak3 10 years ago

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. - Superfreak3 10 years ago

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...
http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/19/470980.aspx

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

Answer
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. - Superfreak3 10 years ago

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!! - Superfreak3 10 years ago

What are the pros/cons of disabling Restart Manager? - Superfreak3 10 years ago