[Util] Fix #33919: az upgrade: Warn about Device Guard / WDAC blocking after MSI install - #33920
[Util] Fix #33919: az upgrade: Warn about Device Guard / WDAC blocking after MSI install#33920Aditya Pujara (a0x1ab) with Copilot wants to merge 7 commits into
az upgrade: Warn about Device Guard / WDAC blocking after MSI install#33920Conversation
|
Hi Copilot, |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
microsoft-github-policy-service
Bot
added
Auto-Assign
There was a problem hiding this comment.
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: There may be pipelines that require an authorized user to comment /azp run to run. |
Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
az upgrade MSI install
Live test results —
|
azure-client-tools-agent
Bot
added
the
azure-client-tools-agent
![azure-client-tools-agent[bot]](https://avatars.githubusercontent.com/in/4205534?s=60&v=4){kind=small}
There was a problem hiding this comment.
CI Review — PR #33920
The live-test workflow passed successfully. However, one required CI check
is currently failing:
Azure.azure-cli(Build #20260818.18) — https://github.com/Azure/azure-cli/runs/95796544110
Looking at the Azure DevOps build logs (buildId 339177), the failure trace shows:
##[error]The Operation will be canceled. The next steps may not contain expected logs.
fatal: early EOF
##[error]The operation was canceled.
This occurred during the Checkout step (Checkout Azure/azure-cli@copilot/fix-azure-cli-289-issue)
while cloning the repository, which in turn caused the dependent Unit Test for Core Python312 job
to be canceled. This looks like a transient infrastructure hiccup (an interrupted/canceled git clone)
rather than an issue introduced by this PR's changes.
Copilot please take a look — if the change itself doesn't explain the checkout failure, this is
likely a flaky CI infrastructure issue and re-running the pipeline (e.g. via a new commit or asking
a maintainer to restart the failed job) should resolve it. If you do find something in the diff that
could plausibly affect checkout/build (e.g. very large added files, submodule changes), please fix it.
Posted by agent-assist (autonomous bug-fix pipeline).
|
Started a Copilot task using Posted by agent-assist (autonomous bug-fix pipeline). |
The CI failure was a transient infrastructure issue — the build was canceled due to an |
|
Copilot please see #33920 (comment) |
…or Windows MSI upgrade Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
Addressed in the latest commit.
Automatic rollback (downloading the previous version's MSI) isn't feasible without a reliable direct-download URL for an arbitrary previous version, so the implementation stops at detection + guidance. |
Live test results —
|
Live test results —
|
Live test results —
|
There was a problem hiding this comment.
CI Failure Summary
The live test passed, but Azure Pipelines CI reported a failure:
- Azure.azure-cli (Test Rpm Package Azure Linux 4.0 (Beta) ARM64) — failed (1 errors / 0 warnings)
Please investigate and fix the RPM package build/test failure for Azure Linux 4.0 (Beta) ARM64.
|
Started a Copilot task using |
Azure Linux 4.0 removed the /usr/lib64 -> /usr/lib symlink that AZL3 carried.
On Azure Linux, %{_libdir} expands to /usr/lib, so the CLI RPM is installed to
/usr/lib/az. The previous code hardcoded lib64 in three places, which worked on
AZL3 (via the symlink) but broke on AZL4.
- azure-cli.spec: generated /usr/bin/az entry script now probes lib64 first then
falls back to lib at runtime, supporting both Fedora/RHEL and Azure Linux 4+.
- test_azurelinux_in_docker.sh: detects the actual az install dir before
installing pytest and passes AZ_LIB_DIR to the test script.
- test_rpm_package.py: uses AZ_LIB_DIR env var or auto-detects via os.path.isdir
instead of hardcoding /usr/lib64/az.
Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
Root cause identified and fixed in the latest commit. Root cause: Azure Linux 4.0 (Beta) removed the Fix (3 files):
|
|
/azp run |
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
Live test results —
|
azure-client-tools-agent
Bot
changed the title
az upgrade MSI installaz upgrade: Warn about Device Guard / WDAC blocking after MSI install
There was a problem hiding this comment.
CI Failure Summary
Live test passed, but 2 required checks are failing on this PR (head commit 6c3a31b):
Azure.azure-cli(build) — failed: https://dev.azure.com/azclitools/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_build/results?buildId=340543Azure.azure-cli (Check the Format of Pull Request Title and Content)— failed: https://dev.azure.com/azclitools/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_build/results?buildId=340543
The PR title itself is already compliant ([Util] Fix #33919: \az upgrade`: Warn about Device Guard / WDAC blocking after MSI install), so the title/content check failure is likely due to missing required PR description content (e.g. #33919` link format, history entry, or other required section) — please review the Azure Pipelines build log linked above for the exact validation error and also inspect the build failure log for the root cause.
Please fix both failures.
|
Started a Copilot task using |
Azure Linux 4.0 removed the /usr/lib64 -> /usr/lib symlink that AZL3 carried.
On Azure Linux, %{_libdir} expands to /usr/lib, so the CLI RPM is installed to
/usr/lib/az. The previous code hardcoded lib64 in three places, which worked on
AZL3 (via the symlink) but broke on AZL4.
- azure-cli.spec: generated /usr/bin/az entry script now probes lib64 first then
falls back to lib at runtime, supporting both Fedora/RHEL and Azure Linux 4+.
- test_azurelinux_in_docker.sh: detects the actual az install dir before
installing pytest and passes AZ_LIB_DIR to the test script.
- test_rpm_package.py: uses AZ_LIB_DIR env var or auto-detects via os.path.isdir
instead of hardcoding /usr/lib64/az.
Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
Investigated both failures from buildId=340543:
|
Live test results —
|
|
Automated sensitive-information remediation ran on this pull request.
Agent Assist does not modify source files. The PR creator must remove or replace each suspected value at the linked line:
If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment. ✅ Confirm the finding · ❌ Dispute the finding GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices. |
🤖 PR Validation — ️✔️ All clear
Related command
az upgradeDescription
On machines enforcing Device Guard / Windows Defender Application Control (WDAC) code integrity policies (e.g. Azure Local cluster nodes),
az upgradecan install a newer MSI whose bundledpython.exeis blocked by the policy, leaving a previously working Azure CLI unusable. The CLI has no supported way to query the enforced WDAC policy or predict whether a specific binary will be allowed, so this can't be reliably auto-detected before the upgrade runs.custom.py:_upgrade_on_windows()now logs a warning during the MSI upgrade flow reminding users on locked-down machines to verifyaz versionworks after upgrading, and pointing to the rollback path if it's blocked.doc/install_troubleshooting.md: Added a troubleshooting section documenting the symptom (Code Integrity Event IDs 3033/3077, "blocked by your organization's Device Guard policy") with remediation steps — roll back to the previous MSI, stage-test upgrades before broad rollout across a cluster, or engage the policy administrator._upgrade_on_windows().Testing Guide
History Notes
[Core]
az upgrade: Warn about Device Guard / WDAC policies potentially blocking the CLI after a Windows MSI upgradeThis checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.