WIX MSI Installed from Windows Service - wix

I am working on self installing software. There is a windows service that is running and can be notified that there is a software update. At that time, it will download my burn exe and do a process.start to silently install it. The installer works as expected except for one issue - the services it installs won't start due to a logon failure. If I change the service password in services, the service will start, so I am confident the issue resolves around the service account password. Here's the rub - if I run the exact same installer on the exact same machine from the interactive desktop (logged on user), it works!
Here is one of the services I install:
<ServiceInstall
Id="DataAcquisitionInstaller"
Type="ownProcess"
Name="DataAcquisitionService"
DisplayName="Data Acquisition Service"
Description="Handles all data acquisitions"
Start="demand"
Account="[SERVICEACCOUNTUSERID]"
Password="[SERVICEACCOUNTPASSWORD]"
ErrorControl="normal"
>
<util:PermissionEx
User="[SERVICEACCOUNTUSERID]"
GenericAll="yes"
ServiceChangeConfig="yes"
ServiceEnumerateDependents="yes"
ChangePermission="yes"
ServiceInterrogate="yes"
ServicePauseContinue="yes"
ServiceQueryConfig="yes"
ServiceQueryStatus="yes"
ServiceStart="yes"
ServiceStop="yes" />
<ServiceConfig DelayedAutoStart="yes" OnInstall="yes" OnReinstall="yes"/>
</ServiceInstall>
I have verified in the log that SERVICEACCOUNTUSERID and SERVICEACCOUNTPASSWORD are correct. The only difference I can see in the log is this:
When installing from service:
MSI (s) (30:80) [10:05:28:905]: Executing op:
ServiceInstall(Name=DataAcquisitionService,DisplayName=Data
Acquisition Service,ImagePath="C:\Program Files
(x86)\xxx\xxx\Services\DataAcquisitionService.exe",ServiceType=16,StartType=3,ErrorControl=1,,Dependencies=[~][~],TagId=0,StartName=.\test,Password=**********,Description=Handles
all data acquisitions,SecurityDescriptor=BinaryData,)
When installing from the interactive desktop as the logged in user
MSI (s) (44:E8) [09:45:57:518]: Executing op:
ServiceInstall(Name=DataAcquisitionService,DisplayName=Data
Acquisition Service,ImagePath="C:\Program Files
(x86)\xxx\xxx\Services\DataAcquisitionService.exe",ServiceType=16,StartType=3,ErrorControl=1,,Dependencies=[~],,StartName=.\test,Password=**********,Description=Handles
all data acquisitions,,)
What does this mean --> "SecurityDescriptor=BinaryData"? Is that what is causing my issue and if so, how can I fix it?
Thanks.

Related

Wix installer - Issues installing to a mapped network drive

I have an issue while trying to install to a mapped network drive. I have permissions to create, edit, delete files/folders at this location. It is always for this particular file abc.xslt
This is the what the wix log tell me:
MSI (s) (48:9C) [14:48:11:524]: Source for file 'NSf100' is compressed
InstallFiles: File: abc.xslt, Directory: M:\abc\def\, Size: 17819
MSI (s) (48:9C) [14:48:11:525]: Re-applying security from existing file.
Error 1315. Unable to write to the specified folder: M:\abc\def\.
MSI (s) (48:9C) [14:50:33:621]: Product: ABC -- Error 1315. Unable to write to the specified folder: M:\abc\def\.
Then, I tried to do a RemoveFile before installing the new one as follows:
<RemoveFile Id="NSfr100" Name="abc.xslt" On="install"/>
Again, I see this error:
RemoveFiles: File: abc.xslt, Directory: M:\abc\def\
Error 1315. Unable to write to the specified folder: M:\abc\def\.
MSI (s) (9C:3C) [16:54:29:389]: Product: ABC -- Error 1315. Unable to write to the specified folder: M:\abc\def\.
Action ended 16:54:29: InstallFinalize. Return value 3
So, I tried setting permissions on that file as follows but that did not help either,
<util:PermissionEx User="Everyone" Domain="domain name" GenericRead="yes" Delete="yes" Read="yes" GenericAll="yes" GenericWrite="yes" GenericExecute="yes" WriteAttributes="yes" WriteExtendedAttributes="yes" ReadAttributes="yes" ReadExtendedAttributes="yes" ReadPermission="yes" Synchronize="no" />
The same installer works without issues when installing locally. Could someone please help me understand why this fails while installing to a mapped network drive?
Thanks much
This isn't a supported scenario for Windows Installer. The mapped drive only exists in the users logged in context. The windows installer service running as SYSTEM cannot see it.

wix Restart Manager successfully shuts down application but says it couldn't

In my wix project, I have a file "connect.exe" that will usually be running during uninstall or update. During uninstallation and major update Wix will prompt before closing with the usual "The following applications should be closed before continuing the install."
This dialogue will successfully shut down the program:
Action 17:19:59: ShutdownApplications. Shutting down applications
MSI (s) (5C:44) [17:20:02:880]: RESTART MANAGER: Successfully shut down all applications in the service's session that held files in use.
MSI (c) (A4:08) [17:20:02:880]: RESTART MANAGER: Successfully shut down all applications that held files in use.
But then right after, it'll throw an error saying that it could not shut down the application:
MSI (s) (5C:44) [17:20:33:300]: Note: 1: 1611
MSI (s) (5C:44) [17:20:33:300]: Note: 1: 2205 2: 3: Error
MSI (s) (5C:44) [17:20:33:300]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1611
The setup was unable to automatically close all requested applications. Please ensure that the applications holding files in use are closed before continuing with the installation.
Even though the application is clearly shut down on the system. Also, it won't restart it when doing a major update after the installer is finished updating.
Everything else seems to work just fine.
Notably, the program connect.exe runs a window that is hidden most of the time. It's mainly used as an on screen display for service.exe which runs via Windows System Service.
How can I fix this to work? Am I not handling something on the connect.exe application end?
connect.exe component entry:
<Component Id="ConnectExe" Guid="..." DiskId="1">
<File Id="connect.exe" Name="connect.exe" Source="..\data\connect.exe" KeyPath="yes">
<Shortcut Advertise="yes" Description="Connect front end application." Directory="ApplicationProgramsFolder" Icon="connect.exe" Id="ConnectStartMenuShortcut" Name="Connect" IconIndex="0" WorkingDirectory="INSTALLDIR">
<Icon Id="connect.exe" SourceFile="..\data\connect.exe" />
</Shortcut>
<Shortcut Advertise="yes" Description="Connect front end application." Directory="StartupFolder" Icon="connect.exe" IconIndex="0" Id="ConnectStartupShortcut" Name="Connect" WorkingDirectory="INSTALLDIR"></Shortcut>
</File>
<RemoveFolder Id="ApplicationProgramsFolder" Directory="ApplicationProgramsFolder" On="uninstall" />
</Component>
Improved?: Different ways to create and interpret MSI logs.
Log File: What does the rest of the log file say? Any mention of other files that are locked? Some logging and log-file interpretation hints can be found here.
I wouldn't be surprised if you have found a bug in the restart manager. Though a relatively simple concept, it involves some seriously complicated stuff. Hidden windows are exactly a source of such complexity.
Quick Questions:
Do you shut down the service executable you refer to as well? Maybe it is installed by a different setup? You can set it to shut down and restart on installation.
I assume you have implemented the proper restart manager support in your application?
The Advanced Installer guys have a very nice, technical article about this: How do I add support for Windows Restart Manager to my application?
PhilDW explains the gist of implementing restart manager support here.
And my own attempt to explain restart manager can be found here (scroll down for middle colored section).
Given that you have implemented restart manager support, you do register a tested command line to restart the application after the installation completes?
Some Links:
In-use files not updated by MSI-installer (Visual Studio Installer project)
Windows Installer-Avoid FileinUse dialog box when Installing a package
Restart Manager behavior with windows installer

How does the MSI Installer InstallValidate determine files in use?

I'm trying to work out how to prevent the Restart Manager from detecting that a restart is required when I uninstall my application.
My application has a Windows Service which uses a native DLL (Tanuki Wrapper) and creates another process (Java) which writes to some log files. I'm using WiX Toolset but I'm more interested in the MSI Installer itself. I've been trying some changes manually using Orca. For reference the relevant WiX configuration is (there are some other components for JARs etc that I have omitted):
<DirectoryRef Id="logs3327407xx">
<Component Guid="344ec345-bdd7-4c1d-801f-55ddf9e07735" Id="logs_wrapper_log88580873x">
<File DiskId="1" Id="fl_logs_wrapper_log88580873x" Name="wrapper.log" Source="logs\wrapper.log"/>
</Component>
</DirectoryRef>
<DirectoryRef Id="bin97543xxxx">
<Component Guid="67c93dd8-36ad-427f-9d79-64a07c719eea" Id="bin_wrapper_windows_x86_64_exe189026768">
<File DiskId="1" Id="fl_bin_wrapper_windows_x86_64_exe189026768" KeyPath="yes" Name="wrapper-windows-x86-64.exe" Source="bin\wrapper-windows-x86-64.exe"/>
<ServiceInstall Account="LocalSystem" Arguments="-s "..\conf\wrapper.conf" wrapper.console.flush=true" Description="My Example Service." DisplayName="My Service" ErrorControl="ignore" Id="srvc_i_bin_wrapper_windows_x86_64_exe189026768" Interactive="no" Name="MyService" Start="auto" Type="ownProcess" Vital="yes"/>
<ServiceControl Id="srvc_c_bin_wrapper_windows_x86_64_exe189026768" Name="MyService" Remove="uninstall" Start="install" Stop="both" Wait="yes"/>
</Component>
</DirectoryRef>
<DirectoryRef Id="bin_wrapper_native490235675">
<Component Guid="d7e4295a-1ce5-4dd2-aa92-230caac34247" Id="bin_wrapper_native_wrapper_windows_x86_64_dll156404367">
<File DiskId="1" Id="fl_bin_wrapper_native_wrapper_windows_x86_64_dll156404367" Name="wrapper-windows-x86-64.dll" Source="bin\wrapper\native\wrapper-windows-x86-64.dll"/>
</Component>
</DirectoryRef>
I understand that there is logic in the InstallValidate action that determines whether files are in use. It will either use the Restart Manager or the FilesInUse based on the MSIRESTARTMANAGERCONTROL property.
If I use the Restart Manager then it opens the dialog saying a restart is required. The logs say:
MSI (s) (1C:7C) [12:27:14:679]: Doing action: InstallValidate
Action ended 12:27:14: MigrateFeatureStates. Return value 0.
MSI (s) (1C:7C) [12:27:14:679]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property. Its current value is 'f2947dee632d694f8b4f1795ff254092'.
...
MSI (s) (1C:7C) [12:27:14:679]: Component: bin_wrapper_windows_x86_64_exe189026768; Installed: Local; Request: Absent; Action: Absent; Client State: Local
MSI (s) (1C:7C) [12:27:14:679]: Component: bin_wrapper_native_wrapper_windows_x86_64_dll156404367; Installed: Local; Request: Absent; Action: Absent; Client State: Local
MSI (s) (1C:7C) [12:27:14:679]: Component: logs_wrapper_log88580873x; Installed: Local; Request: Absent; Action: Absent; Client State: Local
...
MSI (s) (1C:7C) [12:27:14:741]: RESTART MANAGER: Detected that application with id 11368, friendly name 'java.exe', of type RmCritical and status 1 holds file[s] in use.
MSI (s) (1C:7C) [12:27:14:741]: RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary.
MSI (s) (1C:7C) [12:27:14:741]: Note: 1: 1610
It doesn't actually say the files but if I disable the Restart Manager and use the FilesInUse instead then no dialog appears. This time the logs say:
Info 1603. The file C:\...\wrapper-windows-x86-64.exe is being held in use by the following process: Name: wrapper-windows-x86-64, Id: 11004, Window Title: '(not determined yet)'. Close that application and retry.
MSI (s) (1C:8C) [12:33:23:458]: 2 application(s) had been reported to have files in use.
Info 1603. The file C:\...\wrapper-windows-x86-64.dll is being held in use by the following process: Name: java, Id: 8284, Window Title: '(not determined yet)'. Close that application and retry.
MSI (s) (1C:8C) [12:33:23:458]: Note: 1: 2727 2:
MSI (c) (AC:28) [12:33:23:458]: File In Use: -wrapper-windows-x86-64- Window could not be found. Process ID: 11004
MSI (c) (AC:28) [12:33:23:458]: File In Use: -java- Window could not be found. Process ID: 8284
MSI (c) (AC:28) [12:33:23:458]: No window with title could be found for FilesInUse
Can someone please explain how the InstallValidate determines which files are in use?
Additionally how can I prevent the Restart Manager from saying that files are in use which will be released once the service is stopped?
As a side question, why is the Restart Manager not showing the MsiRMFilesInUse dialog? I have checked all the requirements on MsiRMFilesInUse Dialog and as far as I can tell they are all true.
I remember reading somewhere that using a ServiceControl rather than a custom action helps the Restart Manager know that those Files within that Component are used by the service. I have tried adding the files to that Component but it doesn't seem to make any difference.
The behavior of InstallValidate and in-use files related to ServiceControl isn't complicated. If there are files in use by a service and that service is in the ServiceControl table and marked to be stopped on uninstall then it will ignore those files as far as in-use behavior. Putting files in the same component makes no difference, and obviously Windows can't know that the service code is going to shut down processes that are causing files-in-use situations. To my knowledge there is no way of telling InstallValidate that some files really won't be in-use when they are due to be uninstalled.
You won't get an old-style FilesInUse dialog when Restart Manager isn't used because it requires an active window that the user can be prompted to close to shut down the app. This is the reason tray apps without an active window don't cause a FilesInUse dialog. I can't be sure, but it appears to me that the first log extract referring to Restart Manager actually IS RMFilesInUse, and I think that's the dialog you're seeing.
If the only files-in-use issues you're seeing are related to the java process that the service will shut down then a possible solution is:
Suppress all files-in-use dialogs during uninstall.
Use ServiceControl to shut down your service.
Ensure that your ServiceControl was Wait=1 and that it does not respond to the "stop service" request until the java process has been terminated, assuming you can explicitly shut it down.
Windows isn't so dumb that it will force a reboot just because files were in use at InstallValidate time but that isn't true at actual removal time. So the reboot won't be necessary if you can make sure that the files are no longer in use at the actual time they need removing/replacing/whatever. It's not unusual to see the dialog and then find that a reboot is not in fact necessary. So if you suppress the dialog and get everything shut down you won't see a reboot request.

Wix stop service on uninstall/upgrade: prevent "restart popup" (file-in-use situation)

I've got the issue, that when uninstalling (or upgrading) the Restart Manager is complaining about a file in use situation, and so is forcing a reboot:
RESTART MANAGER: Detected that application with id 7000, friendly name 'javaw.exe', of type RmCritical and status 1 holds file[s] in use.
RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary.
The service that RESTART MANAGER is complainig about, is a java-based service. The service (here called myservice.exe) is recursively starting java child processes:
myservice.exe --run
↳ javaw.exe --someArguments
↳ someother.exe --someArguments
↳ javaw.exe --someMoreArguments
The wix snippet for the service definition:
<DirectoryRef Id="BINDIR">
<Component Id="myservice.exe" Guid="PUT-GUID-HERE">
<File Id="myservice.exe" KeyPath="yes" Vital="yes"
Source="SourceDir\bin\myservice.exe"/>
<ServiceInstall Id="MyService" Type="ownProcess"
Vital="yes" Name="MyService" DisplayName="My Service"
Description="My Service" Start="auto" Account=".\LocalSystem"
ErrorControl="normal" Interactive="no" Arguments="--run"/>
<ServiceControl Id="MyService" Name="MyService" Wait="yes" Remove="uninstall" Stop="uninstall" Start="install"/>
</Component>
</DirectoryRef>
Now, the interesting part:
The service could be started when installing
on uninstall:
if not running, it will be removed
if running, and just agreeing to make a restart
it is indeed stopped within about 2-3 seconds (i guess by the StopServices action)
and successfully removed (by RemoveServices action)
The entries in the Service* Tables seems good for me so far.
ServiceControl-Table:
ServiceControl Name Event Arguments Wait Component_
MyService MyService 161 1 myservice.exe
ServiceInstall-Table:
ServiceInstall Name DisplayName ServiceType StartType ErrorControl LoadOrderGroup Dependencies StartName Password Arguments Component_ Description
MyService MyService My Service 16 2 32769 .\LocalSystem --run myservice.exe My Service
So, to break down everything:
It seems that the Restart Manager is not recognizing, that the java processes are child processes and will be stopped by the StopServices action.
I found some kind of similar problems here:
https://www.mail-archive.com/wix-users#lists.sourceforge.net/msg57924.html
Wix Installer Problem: Why does RestartManager mark Service as RMCritical and not RMService
Thanks in advance for any help to solve this issue!
You have a couple of options to resolve this issue:
-Disable "Restart Manager" by making use of MSIRESTARTMANAGERCONTROL= "Disable" in the property table. This would kick in the legacy "FilesInUse" dialog box.
In your case, The FilesinUse dialog might also not be displayed (since services do not have a window associated with them)
The "FilesinUse" dialog box does not list processes which do not have a window associated with them. So, in your case, disabling the Restart Manager, might not display any dialogs(neither FilesInUse nor RestartManager).
However, this would also mean that a reboot might be required, not necessarily because of your services but due to some other process which might be holding your files in use. If you think that there could be no other process other than your own services holding files, then go ahead and follow this approach . If you think that there could be other processes, other than your services holding files, then having "Restart Manager" enabled is ideal. Not having "Restart Manager" will either result in one of the things:
-Display the Legacy FilesInUse dialog asking you to shut down the processes listed in the dialog. This might result in you having to shut down these processes via a custom action.
Both the "RestartManager" and "FilesInUse" dialogs are displayed by the "InstallValidate" standard action. If you want to suppress both of these dialogs, then ensure that your custom action is scheduled before "InstallValidate" standard action. There is a catch here. Scheduling such a custom action before InstallValidate would have to be an immediate mode custom action(You cannot have deferred mode custom actions before "IntsallFinalize"). So , in cases where you are not running as an administrator(such as in UAC enabled scenarios), you might not have the necessary privileges to shut down applications. So , a restart might be required.
-You can also shut down applications using the using the WiX util extensions CloseApplication() function.
Evaluate your scenario and do what is right for you.
I think I might be late to the party, but here's the solution. The Installer team blog post explains how the Restart Manager decides whether to pop up the files in use dialog. Specifically (Windows Installer-Restart Manager Interaction in Detail section, item 3.b.):
If the package is authored such that the services detected by RM would be shutdown because of the authoring of the Service* tables then those services will not be displayed in the files-in-use dialogs.
(italics are mine). Helpful but not immediately helpful, because such that is not really elaborated. But since my service caused the same problem as described by the OP with
<ServiceControl Stop="uninstall" ... />
I just changed the value to both
<ServiceControl Stop="both" ... />
which was probably the only remaining thing that could make it “such that,” and boom, fireworks, magic:
MSI (s) (50:A0) [21:50:30:352]: RESTART MANAGER: Detected that application with id 6408, friendly name 'XXXX', service short name 'xxxx', of type RmService and status 1 holds file[s] in use.
MSI (s) (50:A0) [21:50:30:352]: RESTART MANAGER: Detected that the service xxxx will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager
It appears that both flags msidbServiceControlEventStop (0x002) and msidbServiceControlEventUninstallStop (0x020) need to be set in the ServiceControl table to make the RM happily conclude that the service is going to stop before files are updated.
In retrospect this makes sense. Since the uninstallation part during the upgrade is carried out using the old cached MSI database, RM does not look into it to see what is going to happen when the related product is uninstalled. Strictly speaking, there may be multiple products to uninstall, and the Installer does not require anywhere that these related products (those found by the FindRelatedProducts action, including the old version of the same upgrade code) be in fact related to the service that one is controlling in the current package. So it does not care about the service action on uninstall as scripted in the current package (it does not apply to the install action anyway!). For the sake of consistency, it requires a simple and straightforward evidence that the service is going to be stopped before the files in use are overwritten, gathering such evidence from the current package alone.
So it is quite likely that the RM cares about the msidbServiceControlEventStop (0x002) flag only during the installation.

Wix MSI fails when setting permissions on network path (util:PermissionEx)

I have an MSI that works perfectly when installing locally. If the data path is set to a network location, it fails.
Relevant LOG:
MSI (s) (BC:4C) [17:01:57:322]: Executing op: ActionStart(Name=ExecSecureObjects_64,,)
MSI (s) (BC:4C) [17:01:57:322]: Executing op: CustomActionSchedule(Action=ExecSecureObjects_64,ActionType=3073,Source=BinaryData,Target=ExecSecureObjects,CustomActionData=\\ravel\TeamData\lrieger\Tim2015Pre_Data\CreateFolderEveryone-1073741824C:\ProgramData\Nemetschek Engineering\TIM 2015.0.0.477590057-pre\CreateFolderEveryone-1073741824)
MSI (s) (BC:78) [17:01:57:324]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIAEDE.tmp, Entrypoint: ExecSecureObjects
MSI (s) (BC:A8) [17:01:57:324]: Generating random cookie.
MSI (s) (BC:A8) [17:01:57:325]: Created Custom Action Server with PID 4488 (0x1188).
MSI (s) (BC:60) [17:01:57:335]: Running as a service.
MSI (s) (BC:60) [17:01:57:337]: Hello, I'm your 64bit Elevated custom action server.
ExecSecureObjects: Error 0x80070005: failed to get security info for object: \\ravel\TeamData\lrieger\Tim2015Pre_Data\
CustomAction ExecSecureObjects_64 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (BC:4C) [17:01:57:393]: Note: 1: 2265 2: 3: -2147287035
MSI (s) (BC:4C) [17:01:57:393]: User policy value 'DisableRollback' is 0
MSI (s) (BC:4C) [17:01:57:393]: Machine policy value 'DisableRollback' is 0
Action ended 17:01:57: InstallExecute. Return value 3.
WIX Code:
<Component Directory="DATA_DIRECTORY">
<RegistryValue Root="HKLM" Key="$(var.RegRoot)\Setup" Name="TIM_DATA_DIRECTORY" Value="0xff" Type="string" />
<CreateFolder>
<util:PermissionEx User="Everyone" GenericRead="yes" GenericWrite="yes" Domain="[LOGONDOMAIN]" />
</CreateFolder>
</Component>
Without the util:PermissionEx it works on the network share, but setting these permissions is a requirement, at least if the target directory is local.
Q: Is it possible to set permissions on a network location with wix/msi?
If Not, how can I detect that it is a network directory?
Or is there, in MSI, any way to mark a component as allowed to fail?
If it is not possible to do any of the above, I will probably need to write a custom action that tries to set the permissions but suppresses any failures...
Briefly, I don't think it's possible. The issue is that elevated custom actions run with the system account, and that account doesn't have any network privileges. That WiX utils code is already a custom action that's supplied as a helper for a common task, so writing your own custom action isn't going to help. If you run the CA not impersonated it won't run elevated (unless you elevate the entire MSI install at launch time) so that's not likely to help either. You need an elevated user app to do this for the network share, maybe run at first use of the app itself. This might help:
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html
I would assume it's a network share if it starts with \. A drive letter won't work with the CA anyway because drive letters are a user profile mapping (not a system mapping), so the system account won't know of them. In .Net, FileSystem.GetDriveInfo would help.