I have an installer of Minor Upgrade type. (Say MyAppMinor_v.msi)
I built another installer of same application of type Major Upgrade type (Say MyAppMajor_v+1.msi).
Both of these are built using InstallShield 2014.
MyApp has a Windows system service (MyService.exe) running in background.
Also, MyApp has functionality to update itself from App UI; in which the application updates itself using following command:
msiexec.exe /i MyAppMajor_v+1.msi
This command is run from MyService.exe of MyAppMinor version.
After the update process is completed, the service MyService.exe for MyAppMajor version does not get installed.
It gives following error in Installer logs:
MSI (s) (FC:2C) [10:17:54:387]: Product: MyAppMajor -- Error 1923.Service MyService failed to install. Verify that you have sufficient privileges to install system services.
I do have the admin privileges on the target machine.
This behavior is observed only on Windows 8/8.1.
On Windows 7 I do not get this error and MyService runs perfectly fine on MyAppMinor to MyAppMajor upgrade.
You may have admin on the box but it sounds with UAC you only have a standard user token.
Related
I've created an installer for a Windows Service using WiX. The installer installs and configures the service with no issues. It also uninstalls the service with no issues if it's not running. If the service is running, it may or may not stop and uninstall the service with no issues depending on how long it takes the service to stop.
What I'd like to do is check if the service is running on uninstall, and if so, display a message and then rollback the uninstall. I was looking at the WiX Toolset documentation but nothing jumped out at me.
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
In my wix setup, I use InstallScope="perMachine". In the interactive setup, there is no problem and it installs my application perfectly. However, when I try to install it from command line using /qn, I get the following error.
MSI (s) (60:EC) [11:51:05:268]: Product: ClickShare Launcher -- 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.
Could anyone tell me why it gives such problem only in silent installation? Does command line have different user privileges?
Can I somehow detect if the user has required privileges and install the application perUser instead of perMachine? Would this be a solution?
Thanks.
You can try to set the install per user / per machine code as a parameter
C:\Users\xxxxx\Desktop>msiexec /i "program.msi" MSIINSTALLPERUSER=1 ALLUSERS=2 /qn
this helped us on a application that did NOT require admin priviledge on interactive, but did require admin priviledge on silent mode....
maybe it helps some other users in the future... (from google searches)
Starting with Windows Vista, MSI installs running from a standard user process requiring elevation cannot do so when running silent. This is due to UAC. Elevate the process prior to invoking msiexec.
I have an *.msi installation that uses Wix Extensions :
WixFirewallExtension (To create firewall exceptions)
WixNetFxExtention (To create Native Images at install time)
This msi fails with the error "Installation ended prematurely..." when attempting to install on Windows Server 2003 (both 32 and 64 bit). It installs on Server 2008/Windows 7 etc with no issue.
Removing the firewall and native image parts before building the msi allow it to install normally but obviously without the extra options in place.
Does anyone know what the issue could be?
Here is the part of the log file that shows the failure but it doesn't say why it failed.
Other Notes:
Removing the firewall part but leaving the native image part still causes failure which is causing me to believe that any operation that uses an Extension will be affected.
The firewall configuration is set to ignore failures.
I have confirmed the firewall is enabled and running.
I have tried installing from an Administrator command prompt but this makes no difference
It sounds like a bug in the WiX v3.8 toolset. There were issues in earlier builds where the new VS2012 compilers did not support Windows XP. That was fixed in WiX v3.8.422.0 or newer. If you are not running the latest build of WiX v3.8, I recommend upgrading and seeing if the issue is fixed. If you are running the latest build of WiX v3.8 then you might open a bug: http://wixtoolset.org/bugs.
We have an application that gets installed at a customer's location. This application consists of a self-hosted WCF server running as a Windows service, as well as a client application that isn't related to this problem.
We publish updates to our customers by having the service download our WiX-generated .msi file in the background, then it is installed when the customer chooses to install it. The installation procedure is as follows:
The server copies a bootstrapper application to a temporary path and runs it, passing it the path to the MSI file to install
The bootstrapper uses the upgrade code in the MSI file to uninstall the previous version, then install the new version. It invokes the installer using various P/Invoke calls related to MSI's, like MsiInstallProduct.
The bootstrapper restarts the service
The issue is that at almost call customer sites, this automated process fails, though as with everything, it works in both testing and production at our location. Sometimes it fails during uninstallation, but normally it's during installation. Error codes 1601 (InstallServiceFailure) and 1603 (InstallFailure) are as common as they are entirely unhelpful in determining what went wrong.
We have a backup procedure whereby the user can manually invoke the installer by running the bootstrapper from within Windows (Run As Administrator is required, of course). This process works without fail, and it uses exactly the same installation logic as the automated process that fails.
All services are running as accounts with, at minimum, administrative privileges on the server box.
Where can I start in either trying to find more information about what is causing the error(s) or, even better, prevent them in the first place?
EDIT Here's one example of a failed install's verbose log file:
=== Verbose logging started: 3/29/2013 8:23:30 Build type: SHIP UNICODE 5.00.7600.00 Calling process: <<PATH TO MSI>> ===
MSI (c) (00:7C) [08:23:30:194]: Resetting cached policy values
MSI (c) (00:7C) [08:23:30:262]: Machine policy value 'Debug' is 0
MSI (c) (00:7C) [08:23:30:418]: ******* RunEngine:
******* Product: <<PATH TO MSI>>
******* Action:
******* CommandLine: **********
MSI (c) (00:7C) [08:23:30:491]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (00:7C) [08:23:30:520]: Grabbed execution mutex.
MSI (c) (00:7C) [08:23:30:562]: Failed to connect to server. Error: 0x800703FA
MSI (c) (00:7C) [08:23:30:605]: Failed to connect to server.
MSI (c) (00:7C) [08:23:30:637]: MainEngineThread is returning 1601
=== Verbose logging stopped: 3/29/2013 8:23:30 ===
This is too broad of a question to answer but here's what I've designed for other customers:
1) The elevated service downloads the MSI to a local directory and "advertises" (blesses) the MSI using the command msiexec /jm foo.msi
2) The non-elevated client side component then installs the MSI using the command msiexec /I foo.msi
The MSI must be properly designed and UAC compliant. The transition from Install UI to Install Execute will happen without a UAC prompt. Only properly scheduled ( deferred without impersonation ) custom actions will run elevated.
Once all the kinds were ironed out, the customer was very happy with their autoupdate pattern.
Maybe you need to look into another corner:
When I came over strange installation problems in the past, they were usually caused by behavior analysis tools which exidentally blocked something they shouldn’t have. If some such a tool—may be part of a virus scanner suite or a standalone application such as ThreatFire—is installed on the computer in question, make sure no parts required for your update procedure are listed as “blocked” anywhere. If your update performs actions that lead to auto-treatment by the behavior analysis component, make sure to white-list them reliably.