Wazuh agent Windows package upgrade show `error code 2349`

[rauldpm]

Wazuh version	Install type	Action performed	Platform
4.3.0	Agent	Upgrade	Windows Server 2019 Vagrant box: StefanScherer/windows_2019

Testing https://github.com/wazuh/wazuh-packages/issues/1474, I have found that upgrading the 4.2.6 package to 4.3.0 using the MSI installer with the vagrant user, the installation fails with error code 2349.

This error appears using the GUI upgrade, the PowerShell (elevated) method does not show an error and the upgrade is successful.

- Install 4.2.6
- Open Wazuh agent UI and start the agent
- Wait for the Wazuh agent to be marked as active in the Wazuh server using the agent_control binary
- Keep the Wazuh agent running and with the UI opened
- Upgrade to 4.3.0. (Failed)
- Dialog box appeared about being unable to automatically close all requested applications. Choose OK
- Dialog box appeared with error code 2349
- Agent rollback to 4.2.6

The GUI install is supposed to ask and grant elevated permissions to perform the process.

More information at https://github.com/wazuh/wazuh-packages/issues/1474#issuecomment-1106555433

Regards, Raúl.

[rauldpm]

Update report

• Same behavior was detected upgrading from 4.2.5 to 4.2.6
  • If the UI is open, then the upgrade fails with error code 2349
  • If the UI is closed but the agent is running, the upgrade is successful
• Investigating how the Windows package permissions work

[rauldpm]

Update report

• Analyzing MSI install using the command: msiexec /i wazuh-agent-4.3.0-1.msi /l*v C:\Users\vagrant\Desktop\log.txt
• Generated report: msi_win_report.log
• The log shows that all applications have been closed successfully, but then, it indicates an unexpected error, after clicking on OK, it says that the user chose to restart the system after the install

MSI (s) (80:38) [07:27:45:065]: RESTART MANAGER: Successfully shut down all applications in the service's session that held files in use.
MSI (c) (E0:FC) [07:27:45:065]: RESTART MANAGER: Successfully shut down all applications that held files in use.
MSI (s) (80:38) [07:27:45:581]: Note: 1: 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.
MSI (s) (80:38) [07:28:00:144]: RESTART MANAGER: The user chose to go on with the installation, although a reboot will be required.
MSI (s) (80:38) [07:28:00:144]: Note: 1: 2727 2:  
Action ended 7:28:00: InstallValidate. Return value 1.

• Code 1611 refers to Component qualifier not present. | ERROR_INDEX_ABSENT

[verdx]

I haven't been able to replicate this error on Windows 10, neither upgrading from 4.2.5 to 4.2.6 or from 4.2.6 to 4.3.0 or 4.3.8.

[verdx]

I have been able to replicate the error on Windows Server 2019, although not on Windows 10. The problem seems to have something to do with the way Window's Restart Manager handles the graphical executable of the Wazuh Agent. When upgraded without it opened, the RestartManager is also called, but it works without problem. Adding explicit support for the RestartManager as seen here: https://www.advancedinstaller.com/user-guide/qa-vista-restart-manager.html may be a solution.

[verdx]

The solution I mentioned in the last commentary is not as easy to implement as it seemed at first. All tutorials and guides for adding Restart Manager support to windows applications are for those made using Microsoft's Visual C++ and I haven´t been able to adapt them myself to the C files in which it is programmed. I am currently investigating if there is any other solution looking for the differences in code the GUI application may have with the Wazuh Agent service.

[verdx]

As the last solution couldn't be implemented, we came up with an idea to try and avoid using the Restart Manager, forcing the gui to be closed for the upgrade to start. Looking for ways to do that, I found an MSI Property that allows control over the use of the Restart Manager, as seen in the documentation:

• https://learn.microsoft.com/en-us/windows/win32/msi/msirestartmanagercontrol?redirectedfrom=MSDN It also exists an element called MsiProperty to set MSI properties on fiels created with Wix, as seen here:
• https://documentation.help/WiX-Toolset/msiproperty.html
• https://wixtoolset.org/documentation/manual/v4/reference/wxs/msiproperty/

I have been reading all these tutorials and documentations:

• https://www.firegiant.com/wix/tutorial/
• https://documentation.help/WiX-Toolset/wix_learning.html
• https://stackoverflow.com/questions/39451721/how-do-i-use-msi-property-variable-in-msi-package
• https://helgeklein.com/blog/real-world-example-wix-msi-application-installer/ , but the capacities of MsiPackage and MsiProperty are hardly mentioned. With these or the last links, I don't have enough information to know where to put that element in the files needed to create the MSI.

I tried adding that to wazuh-installer.wxs in commit https://github.com/wazuh/wazuh/commit/89080e49babb13e784dbac07eb45df3dd1ae0d99 but, when creating the MSI file I got this error:

I then tried adding it in its own element path but it also failed:

Seeing the last error had to do with an incorrect value for the Id in element <PackageGroup>, I tried again changing it. This time, the package was created with no problem, as seen here: log-generation-msi.txt

When testing the package, it had the same error as before:

The next test is, knowing the package is correctly created, to try with the other values of the property MSIRESTARTMANAGERCONTROL to see if any of them does any changes in the installation, proving the way of setting the property is correct. After testing it, the result is exactly the same as with the value DisableShutdown. log-generation-msi2.txt

The way I have been using to set the property in the MSI has not worked, more research and testing is needed to find how to introduce it.

[verdx]

Here are more examples of applications found in github using element MsiProperty, all of them with different structure to the one used in Wazuh:

• https://github.com/atinb/importtest
• https://github.com/siqueiraf87/meteorApp

In this example the Property element is used to set MSI properties, not needing the special element MsiProperty:

• https://github.com/hadouken/hadouken/blob/bb89164f324bb6a2c4a17c0d39a28f7a7f40bea9/win32/installer/hadouken.wxs

When tested adding the line:

<Property Id="MSIRESTARTMANAGERCONTROL" Value="Disable"/>

where the rest of the properties are defined in wazuh-installer.wxs, the package is created correctly and the installation test is somewhat different, although it ends with the same error. This proves that the Property element can be used in .wxs to set MSI properties.

We can see in the first photo the message is different, its more clear you should manually close the files. The dialog that shows this time is https://learn.microsoft.com/en-us/windows/win32/msi/msirmfilesinuse-dialog?redirectedfrom=MSDN

The output of this command:

msiexec /i wazuh-agent-4.4.0-myrevision.msi /l*v C:\Users\vagrant\Desktop\msilog.txt

was different as well: msilog.txt

In this extracts we can see the Restart Manager has not been called, rather the FilesInUse dialog:

MSI (s) (B0:14) [08:46:33:994]: RESTART MANAGER: Disabled by MSIRESTARTMANAGERCONTROL property; Windows Installer will use the built-in FilesInUse fun
ctionality.

Info 1603.The file C:\Program Files (x86)\ossec-agent\win32ui.exe is being held in use by the following process: Name: win32ui, Id: 1172, Window Title
: '(not determined yet)'.  Close that application and retry.
MSI (s) (B0:14) [08:46:35:476]: 1 application(s) had been reported to have files in use.

As the documentation isn't completely clear on the difference of functionality between the possible values of property MSIRESTARTMANAGERCONTROL, the same test was conducted for value DisableShutdown, but the error was again the same one as if not setting the property:

More research led to this very useful post:

• https://stackoverflow.com/questions/50917062/windows-installer-avoid-fileinuse-dialog-box-when-installing-a-package , where two other RestartManager related Properties are mentioned:
• https://learn.microsoft.com/en-us/windows/win32/msi/msidisablermrestart?redirectedfrom=MSDN
• https://learn.microsoft.com/en-us/windows/win32/msi/msirmshutdown?redirectedfrom=MSDN

The 4 tests for the usage of both properties (MSIDISABLERMRESTART and MSIRMSHUTDOWN) and their possible values(again, it's not really clear how the would affect based on the scarce documentation) ended with the first error seen:

It`s probably very useful to compare more and research more on the logs for the error with and without using Restart Manager, as it could give new information on the error we are having, even if maybe the disabling of the Restart Manager for the installation doesn't seem to be helping.

[verdx]

As decided in the daily meeting of the team, and having deactivated the Restart Manager, leaving only the FilesInUse Dialog, a solution seemed to deactivate that too. These are two links referring to that:

• https://www.codeproject.com/questions/719519/disable-file-in-use-dialog-wix-installer
• https://community.flexera.com/t5/InstallShield-Knowledge-Base/Disabling-the-FilesInUse-Dialog/ta-p/3959

In the first of those it spoke of some attribute which could disable the Dialog, msidbDialogAttributesVisible. More on it is explained here:

• https://learn.microsoft.com/en-us/windows/win32/msi/dialog-table
• https://learn.microsoft.com/en-us/windows/win32/msi/dialog-style-bits Basically, all UI Dialogs appear in a table with different columns, one of them being the column for Attributes, which is a Double Integer in which each bit configures something. The first of them is referred to asVisible and sets the visibility of the Dialog. There is not much documentation on how could that be changed for an individual installation's FilesInUse Dialog.

Two tests have been done, trying to change the visibility of it as the other MSI property we changed to disable the RestartManager. Adding line:

<Property Id="msidbDialogAttributesVisible" Value="0"/>

or

<Property Id="MSIDBDIALOGATTRIBUTESVISIBLE" Value="0"/>

to file wazuh-installer.wxs has no effect, although the package is correctly created. The property is probably taken as a user defined one. The result of the test is: creationlog.txt msi_win_report2P.log

Searching in github for msidbDialogAttributesVisible only shows it used in files called candle.wsf , Windows Script Files that seem to have something to do with WiX, although it isn't clear how.

The following book seems like it may hold some interesting information, although the first reading hasn't given much:

• https://www.packtpub.com/product/wix-36-a-developers-guide-to-windows-installer-xml/9781782160427

This other link may also prove useful at some point:

• https://stackoverflow.com/questions/33248658/how-does-the-msi-installer-installvalidate-determine-files-in-use#33265914

Another interesting information is that the GUI application is technically only a DialogBox, which may have also something to do with the error trying to close it from the Restart Manager.

[verdx]

There seems to be no more information on msidbDialogAttributesVisible than the one already mentioned. A different approach to the Property element of Wix one is another element, the WixVariable, which personalizes some of the information in Dialogs along the installation, as it is seen here:

<Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT" Value="Run Agent configuration interface" />

The only information found on it is here:

• https://documentation.help/WiX-v3.0/wix_xsd_wixvariable.htm
• https://documentation.help/WiX-Toolset/wixvariable.html
• https://wixtoolset.org/documentation/manual/v3/xsd/wix/wixvariable.html , but in none of this can be found a list of possible variables to use. Using Github Copilot to try and find something that made sense, I got to trying to create a package with this line in its wazuh-installer.wxs file:

<WixVariable Id="WixUIDisableIgnoreButton" Value="1" />

On trying it, it had the same result as before, no problem creating the package and no change in the dialog.:

The other possible approach thought was this:

• Creating a Visual Studio IDE WiX project
• Find the configuration mentioned here and make the necessary changes to disable the FilesInUse Dialog.
• Look in the code to see what changes have been done
• Replicate the changes in our repositories. This approach was tried but too much problems arose from trying to install Visual Studio IDE in a Windows VM.

[verdx]

With the help of @DFolchA it was decided to force the closing of the GUI as part of the installation actions. This way, if the user sees the FilesInUse Dialog and decides to ignore it, no error will arise and the upgrade will finish correctly.

This was done by adding a CustomAction to the file wazuh-installer.wsx and calling it at the start of the installation:

• Definition:

<CustomAction Id="CloseUI" Directory="APPLICATIONFOLDER" ExeCommand="TASKKILL /F /IM win32ui.exe" Execute="deferred" Impersonate="no" Return="ignore" />

• Call:

<Custom Action="CloseUI" Before="InstallInitialize"></Custom>

Tests needed:

• Windows Server 2016
• [x] Fresh installation
• [x] Upgrade without open GUI
• [x] Upgrade with open GUI
• Windows Server 2019
• [x] Fresh installation
• [x] Upgrade without open GUI
• [x] Upgrade with open GUI
• Windows Server 2022
• [x] Fresh installation
• [x] Upgrade without open GUI
• [x] Upgrade with open GUI
• Windows 10
• [x] Fresh installation
• [x] Upgrade without open GUI
• [x] Upgrade with open GUI
• Windows 11
• [x] Fresh installation
• [x] Upgrade without open GUI
• [x] Upgrade with open GUI

[alberpilot]

Blocked: https://github.com/wazuh/wazuh-qa/issues/3512