MSI installer does not refresh registry InstallDate on version upgrade

[Copilot]

🤖 PR Validation — ️✔️ All clear

Tests
️✔️ 2/2

After upgrading the Az PowerShell MSI (e.g. via Intune), Programs and Features shows the new DisplayVersion but a stale "Installed On" date. The reporter's ARP key confirms it:

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{49E06217-...}]
"DisplayName"="Microsoft Azure PowerShell - August 2026"
"DisplayVersion"="16.2.0.41027"
"InstallDate"="20260807"     <-- date of the previously installed release

The MSI relies solely on the standard RegisterProduct action to publish ARP data. When the engine registers over an existing product registration (reinstall / same-product-code upgrade paths, which is what Intune's mandatory-app deployment ends up doing), it refreshes DisplayVersion but leaves the recorded InstallDate untouched.

Changes (setup/azurecmd.wxs)

• RefreshInstallDate custom action — rewrites HKLM\...\Uninstall\[ProductCode]\InstallDate with the current date in the yyyyMMdd form the shell expects, so the value always reflects the actual install/upgrade regardless of which upgrade path Windows Installer takes.
• Sequencing — After='RegisterProduct' (inside the InstallInitialize/InstallFinalize window) so it overwrites whatever the engine published; conditioned NOT REMOVE so uninstall is unaffected.
• Safety — Execute='deferred' Impersonate='no' for the elevated HKLM write, and Return='ignore' so this can never fail an installation.
• Reuses the existing pattern — same POWERSHELLEXE type-50 custom action style as the neighbouring ExecutionPolicy action. Invoking system32\powershell.exe also keeps WOW64 redirection consistent per package: the x86 package's 32-bit custom action lands on the Wow6432Node ARP key, which is where its entry lives.

<Custom Action='RefreshInstallDate' After='RegisterProduct'>NOT REMOVE</Custom>

<CustomAction Id='RefreshInstallDate' Execute='deferred' Property="POWERSHELLEXE"
              ExeCommand="... -command &quot;Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode]' -Name 'InstallDate' -Value (Get-Date -Format 'yyyyMMdd') -Type String -Force&quot;"
              Impersonate="no" Return='ignore'/>

Note for reviewers

[ProductCode] in ExeCommand is fine for a deferred action: the "only CustomActionData is available" rule applies to properties read from the session by DLL/script custom actions. For type-50 EXE actions the Target field is a Formatted field resolved when the action is written to the execution script during the immediate phase — the same mechanism the pre-existing deferred ExecutionPolicy action already relies on for POWERSHELLEXE. ProductCode is additionally one of the few properties available even at deferred execution time.

The MSI can't be built or installed in this environment (needs WiX + Windows); verification here was limited to the .wxs authoring and the embedded PowerShell command. Worth a manual upgrade check against a machine with a prior release installed.

• Fixes Latest MSI Az PS MSI installed date is incorrect while version is accurate #30092

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[x-engineering-agent]

Live test skipped

⏭️ Skipping the live test for this revision because no changed test file was found under a <Service>.Test project (src/<Service>/<Service>.Test/**/*.cs|*.ps1).

The live-test pipeline runs only the scenario/xUnit test files a PR changes, so there is nothing to execute for this commit. This is informational — a regression test is encouraged where it makes sense, but not required. If a test file is added in a later commit, the live test will run automatically.