3

Context:

We're developing a windows service that runs as Local System Account. One of its features is to detect a new version and perform a self-update by launching msiexec.exe /i file.msi /qn.

We expected the service would be updated and restart with the new version. But, what we observe is the installation finishes with "MainEngineThread is returning 1603".

We've read https://learn.microsoft.com/en-us/troubleshoot/windows-server/application-management/msi-installation-error-1603, and after analyzing the possible causes, we concluded:

  • Windows Installer is attempting to install an app that is already installed on your PC. But, it is a new version. So, there should not be a problem.
  • The folder that you are trying to install the Windows Installer package is NOT encrypted.
  • The drive that contains the folder that you are trying to install the Windows Installer package to is NOT accessed as a substitute drive.
  • The SYSTEM account HAS Full Control permissions on the folder that you are trying to install the Windows Installer package to. You notice the error message because the Windows Installer service uses the SYSTEM account to install software.

Questions:

  1. The current solution of self-update a windows service by calling msiexec.exe from the service or a child process possible? What are we missing?
  2. If the current solution is not possible, what would be the solution for a windows service to perform a self-update?
Mateus Fernandes
  • 31
  • 1
  • I have not tried this approach. Do you have a distribution system instead? Could you schedule an installation from there? API? Maybe you could create a scheduled tasks to kick off the installation with a specific admin account? How do you invoke the installation, via UNC paths? Last time I checked the `LocalSystem` account will access the network using the machine account. You should be able to access local drives via drive letters, but not network drives via drive letters. I think you might be able to access UNC paths from LocalSystem with AD configuration right. Too long ago to remember. – Stein Åsmul Oct 25 '20 at 21:58
  • Just for the record, a good resource for servies (but not necessarily for installation): https://www.coretechnologies.com/WindowsServices/FAQ.html and https://www.coretechnologies.com/blog/windows-services/interactive-services-removed-windows-10/ – Stein Åsmul Oct 26 '20 at 02:43
  • @SteinÅsmul thanks for the comments. The idea is to not rely on systems like https://en.wikipedia.org/wiki/Microsoft_System_Center_Configuration_Manager. We want that once the service is installed in Windows, the service would be able to receive some sort of signal (this already works fine) and trigger the self-update.So, our question is: is there a way for the service itself to call the `msiexec.exe` or should we use a different solution? – Mateus Fernandes Oct 26 '20 at 13:51
  • I am unsure based on [the changes to services in Windows 10](https://www.coretechnologies.com/blog/windows-services/interactive-services-removed-windows-10/) (interactive services removed). What happens if you try to [impersonate a user](https://stackoverflow.com/a/38490877/129130)? [WindowsIdentity.Impersonate Method](https://learn.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.impersonate). – Stein Åsmul Oct 27 '20 at 12:18
  • 1
    Be sure to capture as much MSI logging information as you can. [On MSI logging](https://stackoverflow.com/a/54458890/129130) to determine what the exact problem is. – Stein Åsmul Oct 27 '20 at 12:53

0 Answers0