We have a msi installer which we have created using the wix installer. This installer also includes certain device drivers that need to be installed. We install the device drivers via a custom action. This custom action executes a .bat file that contains the utility dpinst64 to install the driver package. I have used the following option with the dpinst64
#if /I "%PROCESSOR_ARCHITECTURE%" == "AMD64" (
rem echo Installing driver from 64-bit installer on Windows 7
rem dpinst64.exe /SW /S /PATH W7
dpinst64.exe /q /se /PATH W7
) else if /I "%PROCESSOR_ARCHITECTURE%" == "X86" (
rem echo Installing driver from 32-bit installer on Windows 7
dpinst32.exe /q /se /PATH W7
)
)
What happens is when the user double clicks on the msi, the user gets a prompt to enter his / her credentials. After this installation proceeds OK. When the time comes to install the drivers, the user is again prompted with the credential window. I would like to know how can I avoid this coming again. I was thinking since I have already provided my credentials, this should remain for the rest of the session. However this seems to be not the case.
Batch Files Considered Harmful: Batch files must be avoided at all cost for MSI deployment. They are clunky, obsolete and almost without error handling and generally feature no rollback.
WiX Driver Element: Recommend you try to use the WiX Driver Element instead. It uses the DIFx framework under the hood - as far as I know. A small, practical example found on github.com.
Previous Answer: Maybe see this previous answer for more on the difx:Driver construct:
<Component>
<File ... />
<difx:Driver ... />
</Component>
Links:
https://developer.microsoft.com/en-us/windows/hardware
WiX silent install unable to launch built in .EXE: WiX v3
WiX silent install unable to launch built in .EXE: WiX v3
Can't seem to get Wix to install driver
Related
I'm trying to uninstall an older version of our product which was installed using a WiX-built installer and after uninstalling it silently:
msiexec /x{GUID}
the program still appears in Control Panel. I've opened a separate item to
explore that mystery, but another curious issue has popped up. I noticed that after running the install for this program, two entries (GUIDs) are added to HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. One with the product GUID and one that I have no idea where it comes from. I've searched through the .msi and it's not in there. Both are created each time I install, both are removed if I uninstall from the Control Panel and both are left in the registry if I uninstall from the command line. So have a look
Anyone have any ideas what's going on here?
Embedded Setup.exe: In essence it looks like you are installing an MSI that also installs an embedded non-MSI setup.exe via a custom action as part of its own installation sequence. Or, there is a setup.exe launcher that kicks off the MSI and the legacy setup in sequence. Result: two entries in Add / Remove Programs.
Uninstall: It is obvious, but to get rid of the second entry you must run its uninstall sequence - in addition to the uninstall of the MSI. Non-MSI setups are less reliable when it comes to uninstall than MSI packages. The implicitly available uninstall for all MSI packages with reliable silent running is one of the core benefits of MSI: MSI Core Benefits (among other topics).
Uninstall Commands: Try running the silent uninstall string, I guess that is what you have done?
Run commands elevated! With admin rights!
REM Uninstall MSI
msiexec.exe /x {PRODUCT-GUID} /L*v C:\MySetup.log /QN
REM Uninstall legacy setup.exe
"%SystemDrive%\ProgramData\Package Cache\{c5f0cb3e-1de3-4971-843a-abb981ed670c}\MDRSetup.exe" /uninstall /quiet
Silent Running: To run legacy setups silently you sometimes have to record a "response file" to record all settings in the GUI and pass to the uninstall process. I have some previous answers on this. You also need to run with admin rights:
Create MSI from extracted setup files
Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
How to run an installation in /silent mode with adjusted settings
Application Repackaging: What is the name of the software you are installing? MDRSetup.exe, is that Max Data Recovery 1.9? Probably not. Getting rid of legacy software can be challenging. You can always try to re-package it as an MSI if you have the tools to do so, or maybe you have a team in your company to do so (all large companies tend to). Not all legacy setups can be repackaged. There could be constructs that are impossible to capture, such as certain drivers, generated and unique keys per machine etc...
Links:
Create MSI from extracted setup files
How can I use powershell to run through an installer?
Wix - How to run/install application without UI
Capturing all changes during an application install on Windows
I created the msi installer for my software using the wix tool. I am using integration with Microsoft_VC140_CRT.msm.
<DirectoryRef Id="SystemFolder" DiskId ="1">
<Merge Id="VC140_CRT" SourceFile="..." Language ="0"/>
</DirectoryRef>
During installation on Win 10 x64, an error occurs and the installer cancels the changes made in the system. In this case, the installer marks in the system log a warning that the application attempted to install an earlier version of the protected file C: \ WINDOWS \ System32 \ ucrtbase.dll. Event ID 1030.
How to disable msi installer logging in the system log?
Is it possible to run the exe built using WIX burn bootstrap to run in silent mode? I need to do this in order to skip the UAC prompt. Are there any better ways to skip the UAC prompt using the WIX project itself? Without making any changes to the registry keys manually.
Burn supports silent installations. Use the /quiet switch to run installation without any user interface. This will not show the UAC prompt.
AppInstaller.exe /install /quiet
If your installation requires elevated rights to install properly, run it from another already elevated process - either command line, or a management software.
I have an Excel Add-in that uses a Wix (3.10) install script. The installation works fine. However, if the user tries to remove the add-in through System | Apps & Features, it fails with "There is a problem with this Windows Installer package. A program required for this install to complete could not be run." Looking at the uninstall log, I see this:
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: _BDF865EC_34B3_4B29_986C_98D6EC1A9807, location: C:\Windows\Installer\MSI2FE4.tmp, command: /uninstall="C:\Users\Windows10\AppData\Local\myCompany\myProduct\myAddin.dll" /privileges=user
The action that it is balking at is this:
<CustomAction Id="_BDF865EC_34B3_4B29_986C_98D6EC1A9807" BinaryKey="adxregistrator_exe" Execute="deferred" ExeCommand='/uninstall="[TARGETDIR]$(var.myProject.TargetFileName)" /privileges=user' Impersonate="yes" />
However, if I re-run my installer and select 'Remove', it uninstalls fine. Also, If I run the uninstall from a command line (using the msiexec command found in the registry entry for this product), it also uninstalls fine.
Also:
This only happens in Windows 10. Older versions of Windows are fine.
I have replicated on several machines, including a fresh install.
I have an older installer (a VS2010 Setup Project), the problem happens with that installer as well.
I have tried with UAC at different elevations, no difference.
I have seen other posts here about changing the Impersonate setting to "no", no difference.
It seems to me that there is a problem with the new Windows Apps & Features app, but I have yet to find anything on the Microsoft forums.
Update:
A Wix user posted this: DTF Bug with new Windows 10 Apps and Features. Also, we have tried a variety of commands (thinking it was a UAC issue), none of them work, even 'built-in' Windows commands fail.
I have run into the same issue and finally came with this solution:
Win 10 Apps & Features uninstaller checks for the WindowsInstaller registry value and behaves correctly when this value is not present
1) Define the custom action
<CustomAction Id="DeleteWindowsInstallerValue" Return="ignore" Directory="TARGETDIR" Execute="deferred" Impersonate="no"
ExeCommand= "reg.exe DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] /v WindowsInstaller /f" />
2) schedule the action in the InstallExecuteSequence
<Custom Action="DeleteWindowsInstallerValue" Before="InstallFinalize"/>
Honza
As a test case for an issue I'm having with application deployment, I built an MSI following the WiX Simple Setup tutorial and using the latest version of WiX 3.5. My test environment is a virtual machine running 64-bit Window 7 Ultimate.
If I login as an standard user (no administrative privileges), open an elevated command prompt and install the MSI using msiexec /i testproj.msi, the directories and files are created, but the test program is not listed in the Programs and Features section of the Control Panel.
The test program installs completely if I run it from an elevated command prompt while logged in as a user with administrative privileges, or if I run it from a non-elevated command prompt. In all cases, the dialog that says "Please wait while Windows configures Test Package" is displayed.
I'm testing this in a virtual machine, reverting to a preinstall snapshot each time to make sure the failed installations aren't interfering.
I've enabled logging (e.g. msiexec /i testproj.msi /L*v test.log), and in all cases, the log indicates the program was installed with no errors (return code of 0).
Why does the installation fail to register the program in the Programs and Features list when run from an elevated command prompt while logged in as a standard user?
Install the application from normal user account and then check the Add/Remove program in the administrator account. The entry must be present there. This can occur if you haven't specified ALLUSERS value to 1.
<Property Id="ALLUSERS" Value="1" />