Don't fail if the package is already installed on Windows

[soar]

by default, Ansible allows following msiexec.exe exit codes:

• 0 for success
• 3010 for "reboot required" state

but there is another code - 1603, for cases, when the package is installed already. This change allows Ansible to proceed in these cases.

[clarkb7]

The error code 1603 is described as

Error 1603: A fatal error occurred during installation.

Why should be considered a success case?

[soar]

Because, as I mentioned, it can be returned if a previous version was installed:

[clarkb7]

Ansible should not be running the MSI if the same version of the Agent is already installed. What version the Datadog Agent installer and what version of Ansible are you using?

[soar]

@clarkb7 I'm using Ansible 2.14.3 and the latest role version from Galaxy

Ansible should not be running the MSI if the same version of the Agent is already installed

I looked through the code, and the logic that are you talking about works only if datadog_agent_version is set. In my case, I don't use version pinning, so it always tries to install the MSI.

[clarkb7]

I'm sorry I should have linked the source in my previous message. The ansible win_package module should not run the MSI if the matching version is already installed. It extracts the version from the MSI file (which is always downloaded by our plugin) and compares it to what is currently installed.

https://github.com/ansible-collections/ansible.windows/blob/a9a7e0820a55014fe3a1ecee47da3f8880bf9541/plugins/modules/win_package.ps1#L729-L750

Are you able to share a small ansible playbook that reproduces the behavior you are experiencing? I have not been able to reproduce it myself.

it looks like there was a bugfix related to this code in ansible.windows 1.4. You can check which version you are using by running this command:

ansible-galaxy collection list ansible.windows

[soar]

I tried today, and it still fails on one Windows host:

MSG:

unexpected rc from 'C:\Windows\System32\msiexec.exe /i C:\Users\admin\AppData\Local\Temp\ddagent.msi /L*V C:\Users\admin\AppData\Local\Temp\ansible-moduletmp-133415799335931354-948335172\msiexec.log /qn /norestart   ADDLOCAL=MainApplication,NPM': see rc, stdout, and stderr for more details

The full log contains a lot of unreadable data, I won't copy it here.

➜ ansible-galaxy collection list ansible.windows

# ./lib/python3.9/site-packages/ansible_collections
Collection      Version
--------------- -------
ansible.windows 1.13.0 

# ~/.ansible/collections/ansible_collections
Collection      Version
--------------- -------
ansible.windows 2.1.0  

The playbook is simple:

- hosts: all
  tasks:
    - name: install datadog
      include_role:
        name: datadog.datadog

[soar]

Debug log file is human-unreadable because of its size, but here are the last lines:

... Files\\Datadog\\Datadog Agent\\embedded3\\Scripts\\\r\nProperty(S): _PROJECTLOCATION_3798 = C:\\Program Files\\Datadog\\Datadog Agent\\embedded3\\ssl\\certs\\\r\nProperty(S): _PROJECTLOCATION_3799 = C:\\Program Files\\Datadog\\Datadog Agent\\embedded3\\ssl\\\r\nProperty(S): _PROJECTLOCATION_3800 = C:\\Program Files\\Datadog\\Datadog Agent\\embedded3\\\r\nProperty(S): _PROJECTLOCATION_3801 = C:\\Program Files\\Datadog\\Datadog Agent\\LICENSES\\\r\nProperty(S): _PROJECTLOCATION_3802 = C:\\Program Files\\Datadog\\Datadog Agent\\\r\nProperty(S): ROOTDRIVE = D:\\\r\nProperty(S): CostingComplete = 1\r\nProperty(S): OutOfDiskSpace = 0\r\nProperty(S): OutOfNoRbDiskSpace = 0\r\nProperty(S): PrimaryVolumeSpaceAvailable = 0\r\nProperty(S): PrimaryVolumeSpaceRequired = 0\r\nProperty(S): PrimaryVolumeSpaceRemaining = 0\r\nProperty(S): INSTALLLEVEL = 1\r\nProperty(S): SourcedirProduct = {DE9F4386-E634-4EF5-85E4-38AAD892F322}\r\nProperty(S): SOURCEDIR = C:\\Users\\admin\\AppData\\Local\\Temp\\\r\nProperty(S): ProductToBeRegistered = 1\r\nMSI (s) (6C:98) [04:53:11:552]: Note: 1: 1708 \r\nMSI (s) (6C:98) [04:53:11:552]: Product: Datadog Agent -- Installation failed.\r\n\r\nMSI (s) (6C:98) [04:53:11:553]: Windows Installer installed the product. Product Name: Datadog Agent. Product Version: 7.44.1.1. Product Language: 1033. Manufacturer: Datadog, Inc.. Installation success or error status: 1603.\r\n\r\nMSI (s) (6C:98) [04:53:11:588]: Deferring clean up of packages/files, if any exist\r\nMSI (s) (6C:98) [04:53:11:588]: MainEngineThread is returning 1603\r\nMSI (s) (6C:10) [04:53:11:588]: No System Restore sequence number for this installation.\r\n=== Logging stopped: 10/13/2023  4:53:11 ===\r\nMSI (s) (6C:10) [04:53:11:599]: User policy value 'DisableRollback' is 0\r\nMSI (s) (6C:10) [04:53:11:599]: Machine policy value 'DisableRollback' is 0\r\nMSI (s) (6C:10) [04:53:11:599]: Incrementing counter to disable shutdown. Counter after increment: 0\r\nMSI (s) (6C:10) [04:53:11:600]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Installer\\Rollback\\Scripts 3: 2 \r\nMSI (s) (6C:10) [04:53:11:600]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Installer\\Rollback\\Scripts 3: 2 \r\nMSI (s) (6C:10) [04:53:11:601]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1\r\nMSI (s) (6C:10) [04:53:11:602]: Destroying RemoteAPI object.\r\nMSI (s) (6C:CC) [04:53:11:602]: Custom Action Manager thread ending.\r\nMSI (c) (B8:30) [04:53:11:605]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1\r\nMSI (c) (B8:30) [04:53:11:605]: MainEngineThread is returning 1603\r\n=== Verbose logging stopped: 10/13/2023  4:53:11 ===\r\n\r\n",
    "rc": 1603,
    "reboot_required": false
}

MSG:

unexpected rc from 'C:\Windows\System32\msiexec.exe /i C:\Users\admin\AppData\Local\Temp\ddagent.msi /L*V C:\Users\admin\AppData\Local\Temp\ansible-moduletmp-133416677686658595-1216451611\msiexec.log /qn /norestart   ADDLOCAL=MainApplication,NPM': see rc, stdout, and stderr for more details

You can see there: MainEngineThread is returning 1603 - that's what I'm trying to add.

[soar]

@clarkb7 I still have this issue, what can I do to push this forward somehow?

[clarkb7]

@soar Can you run the MSI with more verbose logging options /l*vx log.txt and look for log entries like

SECREPAIR: Error determining package source type
SECUREREPAIR: SecureRepair Failed