azure cli installed but az not recognized error path not updated fails

Not specified by the original author.

TL;DR

az is not recognized as an internal or external command means Windows cannot find the Azure CLI executable: the CLI installed but its folder is not on PATH, or the install did not finish. Reinstall from the official MSI with the add to PATH option checked, or add the install folder to PATH manually, then open a fresh terminal and verify with az version. A terminal opened before the fix will never see the new PATH.

'az' is not recognized as an internal or external command,
operable program or batch file.

Use this when

• cmd prints az is not recognized as an internal or external command, operable program or batch file
• PowerShell prints the term az is not recognized as the name of a cmdlet
• This happens right after installing the Azure CLI on Windows, or in a terminal that was open during the install

Not for this skill when

• az runs but az login fails. The CLI is found there; authentication is the problem, see the related application id skill below
• You are inside Azure Cloud Shell. Cloud Shell always has the CLI; a not recognized message there is a different issue

Steps

1. Check whether the CLI is actually installed. Look for Azure CLI in Add or remove programs, and for its folder under Program Files.

Expected: you know whether this is a missing install (go to step 3) or a PATH problem (go to step 2).

2. If it is installed, add its folder to PATH. Add the Azure CLI bin folder to the system PATH in Environment Variables, then close the terminal completely and open a new one.

Expected: az version prints version info in the fresh terminal.

3. If it is not installed, or the folder is missing, reinstall from the official MSI and keep the add to PATH option checked.

Expected: the installer completes, and a fresh terminal finds az.

4. In PowerShell, confirm the shell resolves it: Get-Command az.

Expected: it resolves to the CLI executable path instead of an error.

5. Verify the install end to end: az version.

Expected: JSON output with the Azure CLI version. Only now try az login or your original command.

Variant phrasings

az not recognized windows

The short version of the same report. It is the PATH problem in step 2 nine times out of ten; do the fresh-terminal check before reinstalling.

the term az is not recognized as the name of a cmdlet

The PowerShell wording of the identical failure. PowerShell and cmd read the same PATH, so the fix is the same: folder on PATH, fresh terminal, Get-Command az to confirm.

az login not recognized

az login never gets to run because the shell cannot find az at all. Fix PATH first (steps 1 to 5); login errors only become visible after az version works.

Root cause

The MSI installer optionally adds the CLI folder to PATH. Unchecking that option, an install that did not finish, or a terminal opened before the install leaves az unresolvable. The step everyone skips is opening a fresh terminal: already-open shells keep the old PATH forever.

Edge cases

• 32-bit and 64-bit installs land in different Program Files folders. Point PATH at the one that actually exists on disk.
• Corporate images sometimes block the MSI PATH change. Set PATH manually in System environment variables instead.
• Multiple Python-based CLI installs can shadow each other. Get-Command az shows which executable the shell actually resolved.

Tool compatibility

Azure CLI on Windows (MSI install), in cmd and PowerShell. The PATH principle is the same for winget installs; the folder location differs.

Related skills

• Please run az login to setup account - the next failure after az is found but not signed in: https://vectle.com/skills/skl_7aKi9fDg6cP5dqjxQPgTHA
• application id not found (AADSTS700016), which az login can hit once the CLI runs: https://vectle.com/skills/skl_A8TLFys-hrvLfD1hrxFnDg
• azure identity not found: https://vectle.com/skills/skl_O0wm7fdvw17HY02tjklDMw

Provenance

Built from the hatchjs.com Q and A on this exact error, linked in the evidence.

The hatchjs.com Q&A ("az is not recognized as an internal or external command") and the kthw-powershell execution troubleshooting notes document this exact failure: after installing the Azure CLI on Windows, the shell cannot find az because the install folder is not on PATH. The confirmed fix is reinstalling with PATH registration or adding the install folder to PATH manually, then opening a fresh terminal session so the new PATH takes effect.

Not specified by the original author.

TL;DR

Upgrade the CLI to 2.72.0+. The AttributeError: Can't get attribute 'NormalizedResponse' from msal's throttled HTTP client is fixed in Azure CLI 2.72.0, which is also what the current GitHub-hosted runner images ship.

AttributeError: Can't get attribute 'NormalizedResponse'

Steps

1. Upgrade the CLI to 2.72.0+.
2. The AttributeError: Can't get attribute 'NormalizedResponse' from msal's throttled HTTP client is fixed in Azure CLI 2.72.0, which is also what the current GitHub-hosted runner images ship.

When to use

You are seeing this: Here is the traceback: ERROR: Can't get attribute 'NormalizedResponse' on the module element ('msal.throttledhttpclient' from '/tmp/aml-ve/lib/python3.9/site-packages/msal/throttledhttpclient.py') ``` [lambda] @ /tmp/aml-ve/lib/p Use this skill when you run into "Azure CLI command fails: AttributeError: Can't get attribute 'NormalizedResponse' on <module 'msal.throttledhttpclient".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: CLI 2.72.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In gh:Azure/azure-cli#31419 (Microsoft Azure), the issue reported was: Issue Azure/azure-cli#31419 (closed, 36 comments): ### Describe the bug 2025-05-07 07:02:22.965 - DEBUG - az - Executing az acr import -n viennadroptest --source linuxgeneva-microsoft.azurecr.io/distroless/genevamdm:recommended -t distroless/genevamdm:recommended-individualci.vienna.171304749 --subscription f1d79e73-f8e3-4b10-bfdb-4207ca0723ed -g viennadroptest --output json ERROR: The command failed with an unexpected error. Here is the traceback: ERROR: Can't get attribute 'NormalizedResponse' on the module element ('msal.throttledhttpclient' from '/tmp/aml-ve/lib/python3.9/site-packages/msal/throttledhttpclient.py') `` [lambda] @ /tmp/aml-ve/lib/p The verified resolution from the thread: The AttributeError: Can't get attribute 'NormalizedResponse'` from msal's throttled HTTP client is fixed in Azure CLI 2.72.0, which is also what the current GitHub-hosted runner images ship. Upgrade the CLI to 2.72.0+. Source: mount the host path https at container path //github.com/Azure/azure-cli/issues/31419

Not specified by the original author.

TL;DR

The warning means the 32-bit Azure CLI is running on 64-bit Windows. Fix: migrate to the 64-bit Azure CLI (see the install docs section 'Migrate to 64-bit Azure CLI'). GitHub-hosted runner images now ship 64-bit by default, so updating the runner image also resolves it.

The error

UserWarning: You are using cryptography on a 32-bit Python on a 64-bit Windows Operating System. Cryptography will be significantly faster if you switch to using a 64-bit Python.

In Azure Pipelines this surfaces as a PowerShell RemoteException that fails the pipeline, typically when using the arcappliance extension.

Fix it

1. Confirm you are on the 32-bit CLI:

   az version

   Success check: the installed CLI is 2.51.0 (or nearby) and the warning mentions 32-bit Python.

2. Migrate to the 64-bit Azure CLI per the install docs ('Migrate to 64-bit Azure CLI'). Success check: reinstall completes; az version no longer triggers the warning.

3. If you run on GitHub-hosted agents, update to a current runner image, which ships 64-bit by default. Success check: the pipeline step passes with no RemoteException.

4. As a short-term workaround, pin Azure CLI to 2.50.0 where the warning does not appear. Success check: pipeline goes green, but treat this as temporary.

When this applies

• Azure CLI 2.51.0 on 64-bit Windows emitting the cryptography 32-bit UserWarning.
• Azure Pipelines failing with PowerShell RemoteException tied to the warning (arcappliance extension).

When it does not apply

• You are already on the 64-bit CLI and still see warnings; the cause is different.
• Non-Windows agents, or warnings from a different Python package.
• Cryptography is genuinely slow for workload reasons rather than the 32-bit build.

Compatibility

• Azure CLI 2.51.0 (August 2023) 32-bit Windows build. Fixed by migrating to 64-bit.
• GitHub-hosted runners: current images ship 64-bit.

Variant phrasings

• Azure CLI 2.51.0 cryptography UserWarning 32-bit Python
• arcappliance extension RemoteException Azure Pipelines
• "You are using cryptography on a 32-bit Python on a 64-bit Windows"

Why it happens

Azure CLI 2.51.0 shipped a 32-bit Python runtime on 64-bit Windows. The cryptography package detects the mismatch and warns; in PowerShell remoting contexts the warning becomes a RemoteException that fails the pipeline. The 64-bit CLI build removes the mismatch entirely.

Edge cases

• Self-hosted agents need the manual 64-bit migration; only GitHub-hosted images updated automatically.
• Extensions other than arcappliance can trigger the same warning; the fix is identical.
• Source: https://github.com/Azure/azure-cli/issues/27115

Issue gh:Azure/azure-cli#27115: the reporter asked: Issue Azure/azure-cli#27115 (closed, 34 comments): ### Describe the bug When Azure CLI 2.51.0 (August 01, 2023) is installed, arcappliance extension produces a Python UserWarning: > You are using cryptography on a 32-bit Python on a 64-bit Windows Operating System. Cryptography will be significantly faster if you switch to using a 64-bit Python. This leads to PowerShell RemoteException which fails Azure Pipelines. We have tried to uninstall 2.51.0 and install 2.50.0, and the error disappears. ### Related command ``` # az extension add --name arcappliance az arcappliance validate hci --config-file $configFilePath --only-show-errors # A no The verified answer was: The cryptography UserWarning on Azure CLI 2.51.0: the CLI was running 32-bit Python on 64-bit Windows on Microsoft-hosted agents. Migrate to the 64-bit Azure CLI (see the install docs section 'Migrate to 64-bit Azure CLI'); GitHub runner images now ship 64-bit by default. Evidence thread: https://github.com/Azure/azure-cli/issues/27115