I have an MSI that was authored using WiX. It installs a VSTO office addin. With an office application running (and thus the addin loaded) instead of a FilesInUse dialog with retry, ignore, cancel I only get a retry and cancel. The installer log shows a 1306 then a 1603 error. In interactive mode InstallValidate says there's an exclusive lock on this file. The installer seems incapable of overwriting this file via delayed reboot.
I've set MSIRESTARTMANAGERCONTROL to Disable for testing purposes. Eventually this will be called by a burn exe but I'm trying to get my head around the root issues first. Currently burn displays the retry/cancel dialog and if I run it with /passive /norestart it just tries to install the MSI 4 times and then fails.
The interactive experience isn't too horrible (close the app dummy!) but the silent experience fails and doesn't do the force install /reboot that I normally see.
What important trivia am I not remembering?
Update: I set MSIRESTARTMANAGERCONTROL back to it's default and set MSIRMSHUTDOWN to 1 and this has fixed all the silent MSI installation scenarios. However when I have WiX Burn run it as an MsiPackage it fails. I think it's because Burn is passing MSIFASTINSTALL=7 which skips some of the costing steps. I tried adding MSIFASTINSTALL=0 but I see both getting passed to the MSI and the behavior doesn't change.
Related
I have an MSI and an EXE generated with Burn that warps the MSI. Although I can get the exe to properly run a minor upgrade every day I have a new build, when automatically run on DoD hardened systems (In this one case McAfee Endpoint Security with Access Protection, Exploit Protection and ON-Access Scan all enabled) the burn generated EXE fails with a Failed to launch clear room process error. So I went down the path of manually executing the MSI. Now I can get this to update the binaries are restart my service, however the version in the Add/Remove programs is not updated. Is there anyway to get the version number to update in add/remove programs without Burn and without uninstalling first?
I am using the following command line to run the MSI:
msiexec /I "[myinstaller.msi]" REINSTALL=ALL REINSTALLMODE=vomus -norestart
There is windows installer based on Wix which is not implemented correctly and it has several custom action that should not be executed in uninstallation (msi & msp).
I'm going to add custom action to restart system (by using powershell) in the middle of patch uninstallation process (windows installer uninstalled everything). It looks like the process finalized successfully and the patch uninstalled and application works fine.
Are there any risks to do it?
Are there any flags to set in wix file to resume uninstallation after rebooting?
This sounds potentially dangerous - not sure what happens to MSI when you force reboot out of the blue (there are standard ways to invoke reboots instead).
Generally you should be able to fix anything wrong inside the MSI by patching it with a minor upgrade first and then run the fixed uninstall sequence. (this is because the installation of a minor upgrade does not trigger the existing package's uninstall sequence): MSI cleanup approaches (for broken uninstalls) (older answer).
Is there any reason why this approach would not work? Then you should not need any dangerous rebooting, but let Windows Installer do the rebooting itself.
There are advanced features to deal with reboots in MSI, but it is never a good thing to invoke (undesired complexity) and it needs lots of testing. Avoid if you can. You can call the ScheduleReboot action with proper conditioning and the MSI will trigger a reboot warning or a direct reboot if run in silent mode.
Please provide more details of what is happening in your setup.
I have an MSI installer built with Wix. It does not require elevated privileges, having ALLUSERS=2 and MSIINSTALLPERUSER=1. It works fine in the user unteractive mode, but fails when launched from a non-elevated command prompt in the silent (/qn) or passive (/passive) mode.
The error in the log appearing straight after "Action start: InstallFinalize":
Error 1925. You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.
Interestingly, if I run the installer from an admin command prompt in the silent mode, it succeeds. It installs into the per-user folder and writes registry to HKCU as expected, but when I uninstall it, it triggers the UAC elevation prompt, which suggests that there's some component there that has been installed per-machine, rather than per-user. Again, this does not happen if it was installed in the user-interactive mode.
Any help will be much appreciated.
It turned out that the problem was with the ALLUSERS property. I had a custom action that set its value either to 1 or nothing before FindRelatedProducts to match the scope of any previously installed version so that it can be properly upgraded. Then, there was another custom action that reset the value of ALLUSERS back to 2 and set MSIINSTALLPERUSER appropriately instead. The problem was with that second custom action - apparently you shouldn't reset the value of ALLUSERS to 2 in the InstallExecuteSequence, but it's fine to do so in InstallUISequence.
I'm working on an MSI installer written in Wix. The installer works in both per-user, and per-machine contexts.
In a per-machine installation, everything goes smoothly; the product is installed and configured for the initial user. Upon switching to a test user, the application appears in the start menu correctly. Running it for the first time, a msiexec process starts with the message that the app is being configured. However, if the original .msi has been deleted, this process fails.
The failing setup action gives the following message in its log:
Error 1706. An installation package for the product myProduct cannot be found. Try the installation again using a valid copy of the installation package 'myInstaller.msi'.
=== Logging stopped: 3/16/2017 11:15:52 ===
I understand from reading a blog post by Rob Mensching (Lead of Wix) that it probably isn't possible to just edit the source list to point towards the windows cached .msi, a point backed up by another article I've found. Is that correct?
Is there a way to stop this entire action of calling the msi on first run by users from happening? Caching the msi or keeping the original is not ideal, I'd like to use the .msi in a custom bootstrapper that involves deleting the msi once installation is complete.
Microsoft recommends you keep the original MSI available, Rule 31:
https://blogs.msdn.microsoft.com/windows_installer_team/2006/05/24/tao-of-the-windows-installer-part-3/
and I won't repeat what it says about repair/resiliency, but you cannot guarantee the source MSI won't be needed sometime.
You're probably getting this "repair" because there is some resource (a file most likely) that is being installed to a user-profile location. When another user logs on and uses the application that file is missing, so potentially the application is broken. For example a file installed to User's Application Data needs to be available for all users of the system, not just the user that installed it.
So keeping the MSI might not be ideal but is strongly recommended, and in your case of product use by multiple users it's even more likely to required. There should be an Application Event log entry under MsiInstaller that says something about the missing resource.
I've created an installer using WiX and if the user tries to uninstall my application whilst it is still open, they should get the dialog which gives them the option to have the uninstaller close the application automatically or leave it running but a restart will be required.
It seems though that with User Account Control on, I need to elevate by running the package with msiexec from an elevated command prompt before this will happen. If the user is not elevated, the uninstaller will run, they click the Remove icon (which prompts for elevation), but the setup then simply says:
"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."
I'd like them to have the option to close the app even when just uninstalling without having to manually elevate first
My best guess is that your MSI does not have a FilesInUse dialog box nor a MsiRMFilesInUse dialog box. Those are "well-known" dialog boxes that the Windows Installer will populate with information when it detects files in use. The WiX toolset should give you those dialogs automatically if you use one of the standard UIs. Alternatively, you can create your own dialogs.