Description

Since 4.13, some remote upgrades on Windows no longer honor a custom installation directory (e.g., C:\Program Files (x86)\WazuhAgent).
During the upgrade, the MSI for the new version switches to the default folder (C:\Program Files (x86)\ossec-agent\), which leads to:

• Missing configuration/data under the new path
• Service pointing to the wrong directory
• Agent not starting after upgrade

This correlates with a registry location mismatch introduced in 4.13: the upgrade script looks up WazuhInstallDir under HKLM\SOFTWARE\WOW6432Node\Wazuh, Inc.\Wazuh Agent, while legacy/custom installs stored it under HKLM\SOFTWARE\WOW6432Node\Wazuh\Wazuh Agent. When the key is not found, the MSI phase falls back and resolves to the default directory unless INSTALLDIR is explicitly set.

Evidence from installer.log

Remote upgrade executed

Old product (4.13.1) phase – custom path is detected:

• Property(N): APPLICATIONFOLDER = C:\Program Files (x86)\WazuhAgent\
• Property(N): SourceDir = C:\Program Files (x86)\WazuhAgent\
• Property(N): CURRENTDIRECTORY = C:\Program Files (x86)\WazuhAgent

New product (4.14.0) phase – target flips to default:

• Property(S): APPLICATIONFOLDER = C:\Program Files (x86)\ossec-agent\
• Property(S): WixPerMachineFolder = C:\Program Files (x86)\ossec-agent
• Property(S): ApplicationFolderName = ossec-agent
• Security action confirms default-path target:
  • ExecSecureObjects: Securing Object: C:\Program Files (x86)\ossec-agent\ossec.conf

User example log:

• installer.log

Outcome

• MSI concludes with success, but files end up under …\ossec-agent\ instead of the original …\WazuhAgent\.

Interpretation

• The upgrade starts from the custom install dir, yet the new MSI does not retain/resolve that path and defaults to ossec-agent. This matches the registry lookup mismatch and absence of an explicit INSTALLDIR override.

Objectives

1) Analyze & Reproduce

• Reproduce with:
  • 4.12 installed at C:\Program Files (x86)\WazuhAgent\
  • Remote upgrades to 4.13 / 4.14 / 5.0 via WPK
• Verify registry entries before/after
• Confirm script fallback behavior and MSI property propagation (APPLICATIONFOLDER / INSTALLDIR)

2) Implement Fix

• Script (do_upgrade.ps1)
  • Add dual registry lookup for WazuhInstallDir:
    • HKLM\SOFTWARE\WOW6432Node\Wazuh, Inc\Wazuh Agent
    • HKLM\SOFTWARE\WOW6432Node\Wazuh\Wazuh Agent
  • Force working dir to the script location:
    • Set-Location -Path (Split-Path -Parent $MyInvocation.MyCommand.Path)
  • Pass resolved path explicitly to MSI:
    • msiexec /i "<msi>" INSTALLDIR="<ResolvedPath>" WIXUI_INSTALLDIR=APPLICATIONFOLDER REBOOT=ReallySuppress /qn /l*v installer.log
  • Log which registry key/value was used and the final INSTALLDIR passed

3) Validate

• Upgrade matrix:
  • 4.12 → 4.13 / 4.14 (custom path)
  • 4.13 → 4.14 (custom path)
• Check:
  • APPLICATIONFOLDER/INSTALLDIR remains the custom path in both (N) and (S) property blocks
  • Service, config, and permissions remain under the custom directory
  • No unintended files appear in …\ossec-agent\ when a custom path exists

Deliverables

• Updated do_upgrade.ps1 with dual registry lookup, Set-Location, and explicit INSTALLDIR
• (Optional) WiX changes for dual RegLocator/AppSearch
• WPK rebuilt with the corrected script
• Integration tests covering remote upgrades from custom paths
• Documentation updated (registry paths, INSTALLDIR behavior, remote upgrade expectations)

Work Plan

• Analyze do_upgrade.ps1 lookup and identify key mismatch
• Collect installer.log evidence showing default-folder flip
• Implement dual-registry lookup in do_upgrade.ps1
• Force script Set-Location safety net
• Pass INSTALLDIR explicitly to MSI invocation
• Rebuild WPK and run validation matrix
• Add QA regression covering custom-path upgrades
• Update docs (Windows upgrade with custom install paths)

Acceptance Criteria

• Remote upgrade reuses existing custom install directory across all tested paths (4.12→4.13+, 4.13+→4.14+)
• installer.log for the new MSI shows INSTALLDIR=<custom-path>
• Agent starts successfully post-upgrade with the original configuration
• No artifacts under C:\Program Files (x86)\ossec-agent\ when custom path exists

Mitigation (for affected environments)

Create the expected registry key/value so the remote upgrade keeps the custom path:

New-Item -Path 'HKLM:\SOFTWARE\WOW6432Node\Wazuh, Inc\Wazuh Agent' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Wazuh, Inc\Wazuh Agent' `
  -Name 'WazuhInstallDir' -PropertyType String `
  -Value 'C:\Program Files (x86)\WazuhAgent' -Force | Out-Null