I\'m trying to prevent our wix installers from prompting the user for a reboot when uninstalling. Our services are set to be uninstalled and deleted on an uninstall. Unfor
Ran into this also.
The problem is that the restart manager does NOT think the user has permission to stop the service even though it does because at the time that it checks (InstallValidate), the install has not elevated yet.
My solution is to give the Users group permission to start and stop the service. I used the sc sdset
command to change the service permissions.
Or you can use a bootstrapper to start the MSI after elevating.
You can suppress window's RestartManager by setting the MSI property MSIRESTARTMANAGERCONTROL= "Disable" (see documentation here - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370377(v=vs.85).aspx). The only problem with this approach by itself is that instead of prompting users with a reboot-required dialog, they will see the file-in-use dialog (and be asked to shut down any applications that might be using those files/services). This dialog is displayed during the InstallValidate standard action of the InstallExecute Sequence.
If you want a sneaky way around either of these dialogs you can schedule a custom action before InstallValidate that manually shuts down any running services before the RestartManager has a chance to inspect the system. This does not follow standard MSI practices because normally you would mark a custom action that modifies the system as a 'deferred' action, but MSI doesn't allow any deferred actions to run before InstallValidate. So, you would have to mark the action as 'immediate', but in the code you would go ahead and modify the system by shutting down the services. The drawback here is that there's no such thing as an immediate rollback action, so if your uninstall/upgrade fails and does a rollback the services you stopped will be left in a stopped state. The upside is that users never have to see any additional dialogs during their uninstall/upgrade.
Restart Manager will not normally prompt for any files-in-use situations for services that are marked to be stopped in the current operation. In other words it goes through the ServiceControl table to see if the service will be stopped anyway, and will not automatically prompt for in-use files.
Unfortunately this behavior was compromised at one time by a bug - only the first entry in the ServiceControl table was checked. I don't know if this bug was ever documented so I can't cite anything. The original question was posted in 2011, so I would assume that this particular issue has been corrected. The only issues of this kind that occur now tend to be situations where the service is multi-process in some sense, or jacketed (some java services are like this) or when the service does indeed stop being a service but the containing process does not complete promptly, or the ServiceControl doesn't do a full wait and it is still in fact running.