Azure CLI 2.89.1 installed by az upgrade is blocked by Azure Local WDAC policy

[Leonschnucki]

Describe the bug

On an Azure Local cluster node, az upgrade --yes offers and installs Azure CLI 2.89.1 using the official Microsoft MSI.

Before the upgrade, Azure CLI 2.85.0 works normally on the node.

After the MSI upgrade completes, Azure CLI can no longer be started because the bundled:

C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe

is blocked by the Azure Local node's enforced Device Guard / WDAC policy.

Windows Code Integrity logs Event IDs 3033 and 3077 stating that the new python.exe does not meet the Enterprise signing level requirements / violates the active code integrity policy.

Rolling Azure CLI back from 2.89.1 to the Microsoft-signed 2.85.0 MSI immediately restores Azure CLI functionality without making any WDAC policy changes.

Environment before upgrade:

• Azure Local cluster node
• Azure CLI: 2.85.0
• stack-hci-vm extension: 1.15.0
• Azure CLI installation: C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\
• Azure Local CLI extensions: C:\CloudContent\AzCliExtensions\

Reproduction:

1. Verify Azure CLI 2.85.0 works with az version.
2. Run az upgrade.
3. Azure CLI reports that 2.89.1 is the latest available version.
4. Run az upgrade --yes.
5. The official Microsoft Azure CLI 2.89.1 MSI is downloaded and installed.
6. After installation, run az version.
7. Device Guard / WDAC blocks the bundled python.exe and Azure CLI is unusable.

Expected behavior:

az upgrade should not offer and install an Azure CLI version that cannot execute under the enforced WDAC policy of an Azure Local node.

Either:

• Azure CLI 2.89.1 should meet the signing requirements of the Azure Local WDAC policy, or
• az upgrade should detect this environment and refuse/avoid an incompatible upgrade, or
• Azure Local tooling/documentation should clearly state that the node-local Azure CLI must only be updated through Azure Local servicing.

Actual behavior:

The Microsoft-provided self-upgrade successfully installs Azure CLI 2.89.1, but the resulting Azure CLI is unusable because its bundled python.exe is blocked by WDAC.

Rollback test:

Azure CLI 2.89.1 was uninstalled and the Microsoft-signed Azure CLI 2.85.0 MSI was reinstalled. az version worked again immediately with no WDAC policy changes.

Other Azure Local nodes were intentionally not upgraded after reproducing the problem on the first node.

Related command

az upgrade

az upgrade --yes

az version

Errors

After upgrading from Azure CLI 2.85.0 to 2.89.1:

'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe' was blocked by your organization's Device Guard policy.

Contact your support person for more info.

Windows Code Integrity Event ID 3077:

Code Integrity determined that a process
(\Device\HarddiskVolume4\Windows\System32\cmd.exe)
attempted to load
\Device\HarddiskVolume4\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe
that did not meet the Enterprise signing level requirements or violated code integrity policy.

Windows Code Integrity Event ID 3033:

Code Integrity determined that a process
(\Device\HarddiskVolume4\Windows\System32\cmd.exe)
attempted to load
\Device\HarddiskVolume4\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe
that did not meet the Enterprise signing level requirements.

The same node works again immediately after rolling Azure CLI back to 2.85.0.

Issue script & Debug output

Reproduction script:

# Azure CLI 2.85.0 is working at this point
az version

# Check whether an upgrade is available
az upgrade

# Perform the upgrade offered by Azure CLI itself
az upgrade --yes

# After the MSI installation has completed
az version

### Expected behavior

`az upgrade` should not offer and install an Azure CLI version that cannot execute under the enforced WDAC / Device Guard policy of an Azure Local node.

Either Azure CLI 2.89.1 and its bundled `python.exe` should meet the signing requirements of the Azure Local WDAC policy, or `az upgrade` should detect this environment and avoid installing an incompatible version.

The upgrade must not leave a previously working Azure CLI installation unusable.

### Environment Summary

Azure Local cluster node

Before upgrade:
azure-cli: 2.85.0
azure-cli-core: 2.85.0
azure-cli-telemetry: 1.1.0

Extensions:
arcappliance: 1.7.2
customlocation: 0.1.4
k8s-extension: 1.7.0
resource-graph: 2.1.1
stack-hci-vm: 1.15.0

Azure CLI installation path:
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\

Azure Local extensions path:
C:\CloudContent\AzCliExtensions\

Target version offered by `az upgrade`:
Azure CLI 2.89.1

After upgrade:
`az version` fails because
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe
is blocked by the enforced Device Guard / WDAC policy.

Rollback to Azure CLI 2.85.0 restores functionality immediately without any WDAC policy changes.

### Additional context

The issue was reproduced on one Azure Local node only. The remaining cluster nodes were intentionally not upgraded after the failure was observed.

Windows Code Integrity logged Event IDs 3033 and 3077 for the upgraded Azure CLI 2.89.1 bundled python.exe.

No WDAC / Device Guard policy changes were made.

After uninstalling Azure CLI 2.89.1 and reinstalling the Microsoft-signed Azure CLI 2.85.0 MSI, `az version` worked again immediately under the unchanged policy.

This makes the issue especially risky on Azure Local because `az upgrade` explicitly offers 2.89.1 as the latest version and completes the MSI installation before the resulting CLI becomes unusable.

[azure-client-tools-bot-prd]

Hi Leon & Jack (@Leonschnucki),

2.85.0 is not the latest Azure CLI(2.89.1).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[azure-client-tools-agent]

Bug Analysis

Reported issue: On an Azure Local (Azure Stack HCI) cluster node with an enforced Device Guard / WDAC policy, az upgrade --yes downloads and installs the official Microsoft-signed Azure CLI 2.89.1 MSI. After installation, the bundled python.exe under
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe
is blocked by the node's enforced WDAC policy (Windows Code Integrity Event IDs 3033/3077 — "did not meet the Enterprise signing level requirements / violated code integrity policy"). This renders the CLI completely unusable until the node is rolled back to 2.85.0.

Expected behavior: az upgrade should not silently complete an MSI installation that leaves the CLI non-functional. At minimum, az upgrade (implemented in azure-cli-core's self-update / upgrade command flow) should be hardened so that:

• The upgrade path fails loudly / rolls back automatically if the newly installed CLI cannot be invoked afterward (e.g. verify az version succeeds post-install before declaring success), and/or
• On Windows, if the MSI install or the post-install verification step raises an OS-level "blocked by your organization's policy" style error (e.g. WinError 225 / ERROR_VIRUS_INFECTED, or WDAC/Device Guard-specific failures), az upgrade should surface a clear, actionable error message rather than leaving a broken installation in place.

Where to look: the self-update / MSI-invocation logic in src/azure-cli-core/azure/cli/core/_session.py, src/azure-cli-core/azure/cli/core/util.py, and the az upgrade command implementation (likely src/azure-cli-core/azure/cli/core/commands/upgrade.py or similar — search for where the MSI is downloaded/executed and where post-install verification, if any, happens).

Suggested fix approach:

1. After the MSI install step completes, run a lightweight post-install check (e.g. invoke the newly installed python.exe/CLI with a trivial command) and detect failure.
2. If the post-install check fails, keep/restore the previous working installation if feasible, and print a clear error explaining that the new build could not be verified (mentioning WDAC/Device Guard/AppLocker-style policy blocks as a possible cause), directing the user to https://learn.microsoft.com/cli/azure/update-azure-cli for manual recovery.
3. Add regression coverage (unit test) around the upgrade success/failure detection path.

Use this EXACT PR title: [Core] Fix #33919: az upgrade: Skip self-upgrading to a build whose bundled python.exe fails WDAC/Device Guard validation

PR title & description format (required)

This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.

Use this EXACT PR title (copy verbatim, do not reword):

[Core] Fix #33919: `az upgrade`: Skip self-upgrading to a build whose bundled python.exe fails WDAC/Device Guard validation

Keep the backticks around the command and the Fix #33919: prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the [Core] prefix, issue link, and backticked command must stay.

Description — follow the PR template and fill in:

• Link the issue — start the Description with a closing keyword so the PR auto-links and closes it: Fixes #33919.
• Related command — the az ... command this affects.
• Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
• Testing Guide — example command(s) showing the fix works.
• History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g. [Core] `az <command>`: <note>.
• Keep the template checklist and tick the items you've satisfied.

---

Posted by agent-assist (autonomous bug-fix pipeline).