Fix Azure CLI Latest Version Problems, Full Guide
Why This Is Happening
I've seen this exact situation play out on hundreds of machines. You're in the middle of a deployment pipeline, maybe it's 11 PM, maybe you've got a production release window closing fast, and suddenly Azure CLI throws an error you've never seen before. Or worse: a command that worked perfectly yesterday just vanishes. No warning. No migration guide anywhere obvious. Just a cryptic az: 'xxx' is not in the 'az' command group error staring back at you.
Here's what's actually going on. Azure CLI ships regular version updates, and recent releases, especially 2.80.0 and 2.81.0, introduced genuine breaking changes alongside a batch of new features. The problem is that most people either don't realize their version is stale, or they updated without reading the changelog and are now dealing with commands that moved, got renamed, or were removed entirely.
Take the AKS team's decision in version 2.80.0: az aks create now defaults to --no-ssh-key behavior, which is a breaking change. If you have automation scripts that assumed an SSH key would always be provisioned, those scripts now fail silently or create clusters in a state you didn't expect. Similarly, az batch pool create dropped its --target-communication and --resource-tags arguments completely, no deprecation grace period, just gone.
Then there's the Bicep installation bug that affected a lot of teams running version-pinned CI pipelines. When you specified --version in az bicep install, the CLI would skip the installation entirely unless you had explicitly set bicep.use_binary_from_path to false in your config. This one was particularly nasty because it fails silently, the command exits cleanly, but nothing was actually installed.
On the PostgreSQL side, things shifted too. The az postgres flexible-server index-tuning command group has been deprecated and redirected to az postgres flexible-server autonomous-tuning. If your DBAs or scripts are still calling the old path, they'll get errors or unexpected redirects depending on the CLI version they're running.
Microsoft's error messages don't help here. A generic "command not found" tells you nothing about why the command is gone or where it moved. The changelog is comprehensive but dense, and Azure's documentation often lags a few weeks behind the actual CLI release.
I know this is frustrating, especially when it blocks a deployment that has nothing to do with the specific service that changed. The good news: every one of these issues has a clean resolution. Let's work through them. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before anything else, let's confirm what version of Azure CLI you're actually running. Open your terminal and run:
az versionThis outputs a JSON block showing your exact CLI version plus the versions of installed extensions. If you're behind 2.81.0 (released December 2, 2025) or 2.80.0 (November 18, 2025), that version gap is almost certainly your problem.
To update Azure CLI to the latest version on Windows, run this from an elevated PowerShell window:
az upgradeOn macOS with Homebrew:
brew update && brew upgrade azure-cliOn Linux with apt (Debian/Ubuntu):
sudo apt-get update && sudo apt-get install --only-upgrade azure-cliOn Linux with dnf (RHEL/Fedora):
sudo dnf update azure-cliAfter the upgrade finishes, run az version again to confirm the update took effect. Then immediately test whichever command was failing. In about 60% of cases, this single step resolves the issue completely, the command either exists now, or the bug has been patched.
If you're in a CI/CD context like Azure DevOps or GitHub Actions and you can't upgrade globally, you can pin your pipeline to install a specific Azure CLI version at the start of each job using the Azure CLI Installer task or a shell step that calls the install script directly. That way you're always running a known-good version regardless of what's on the runner image.
One important note: after upgrading, your existing CLI extensions (like aks-preview, azure-devops, or storage-preview) don't automatically update. Run az extension update --all immediately after upgrading the core CLI to avoid version mismatches between the core and extension layers, these mismatches are a very common cause of post-upgrade errors.
az upgrade --all instead of just az upgrade, the --all flag upgrades both the CLI core and all your installed extensions in one shot, saving you the separate az extension update --all step. I always recommend this for production environments where extension–core version drift causes the most damage.
Don't guess, get the full picture first. Run these two commands back to back:
az version
az extension list --output tableThe first gives you the CLI core version and Python version underneath it. The second shows every installed extension, its version, and whether it came from a registered index or a manual install. Screenshot or copy this output, you'll want it as a baseline if things go sideways during the fix.
Now check your configuration state:
az config getPay close attention to any bicep.use_binary_from_path setting. If this is set to true and you've been using az bicep install --version in your pipelines, you may have been silently skipping the installation step entirely. This was a confirmed bug fixed in version 2.81.0, if you're on an older version and this setting is true, that's your culprit for any Bicep-related deployment failures.
Also look for core.only_show_errors in your config output. If this is set to true, you may have been suppressing warning messages that would have told you about deprecated commands weeks ago.
If you see a Python version below 3.8, that's an additional problem, recent Azure CLI versions require Python 3.8 minimum, and some features in 2.80.0+ require 3.9+. You may need to update your Python runtime alongside the CLI itself.
You should see something like "azure-cli": "2.81.0" or higher in the az version output after a successful upgrade. If you don't, move to the next step to force a clean install.
If you updated Azure CLI and your existing scripts are now failing, you're almost certainly hitting one of the documented breaking changes introduced in 2.80.0 or 2.81.0. Here's what to check, in order of how commonly I see each one break real-world workflows.
AKS cluster creation scripts failing or missing SSH keys: Starting in version 2.80.0, az aks create makes --no-ssh-key the default behavior. If your script was previously creating clusters and relying on the CLI to auto-generate an SSH key pair, you now need to explicitly pass --generate-ssh-keys to restore that behavior:
az aks create \
--resource-group myRG \
--name myCluster \
--generate-ssh-keysBatch pool commands failing with "unrecognized argument": The --target-communication and --resource-tags arguments were removed from az batch pool create, az batch pool reset, and az batch pool set. Remove those arguments from your scripts, they are gone entirely, not just renamed.
PostgreSQL index-tuning commands redirected: If you're calling az postgres flexible-server index-tuning, that command group is deprecated. Switch to az postgres flexible-server autonomous-tuning. To list index recommendations going forward:
az postgres flexible-server autonomous-tuning list-index-recommendations \
--resource-group myRG \
--server-name myServerAfter updating your scripts, run them with --debug appended to see the full request/response cycle, this makes it obvious if a command is being intercepted or redirected.
The Bicep installation bug (fixed in 2.81.0, GitHub issue #32098) caused az bicep install --version x.x.x to silently do nothing when bicep.use_binary_from_path wasn't explicitly set to false. If your infrastructure-as-code deployments have been failing or using an unexpected Bicep version, here's how to fully repair the situation.
First, check what Bicep version is currently active:
az bicep versionIf this throws an error or shows the wrong version, clear the config flag and reinstall:
az config set bicep.use_binary_from_path=false
az bicep install --version v0.31.0Replace v0.31.0 with whichever pinned version your templates require. After installation, verify:
az bicep versionYou should see the exact version number you specified. If you want to use the Bicep binary that's already on your system PATH instead of the one managed by Azure CLI, you can set:
az config set bicep.use_binary_from_path=trueBut be aware, with this flag enabled and on a pre-2.81.0 CLI, the --version argument to az bicep install will be silently ignored. Upgrade to 2.81.0+ first, then the behavior is consistent and predictable regardless of this setting.
After fixing the Bicep config, run a test compilation against one of your template files:
az bicep build --file ./main.bicepA clean output with no errors confirms the installation is healthy.
Version 2.80.0 added a significant number of new AKS features, and when you try to use them on an older CLI version, you get confusing "unrecognized argument" errors even though the docs clearly show the parameter exists. This is the number one source of confusion I see from teams that mix documentation versions with CLI versions.
For AKS, new arguments introduced in 2.80.0 include --localdns-config for nodepool add/update, the --pss-level parameter for az aks safeguards (added in 2.81.0), and the new namespace command group (az aks namespace add/update/show/list/delete/get-credentials) for managed namespace support. None of these work on 2.79.x or earlier, you'll need to be on 2.80.0+ for namespace commands and 2.81.0+ for the PSS level safeguard parameter.
For PostgreSQL flexible servers, several high-value features arrived in the latest releases. If you're trying to enable high availability on a server with PremiumV2_LRS storage type, that's now supported, but only from 2.81.0+:
az postgres flexible-server update \
--resource-group myRG \
--name myServer \
--high-availability ZoneRedundant \
--storage-type PremiumV2_LRSSimilarly, major version upgrades to PostgreSQL 18 are now supported via az postgres flexible-server upgrade. If that command is failing with an unsupported version error, confirm your CLI is on 2.81.0+. For Fabric mirroring on high-availability servers running PostgreSQL 17+, the fix is the same, update the CLI first, then re-run your command.
For read replicas, the new --name argument lets you specify a name when creating them:
az postgres flexible-server replica create \
--resource-group myRG \
--source-server myServer \
--name myReadReplicaThe storage command changes in 2.81.0 are small but they break scripts in very specific ways if you're working with user delegation SAS tokens. The --user-delegation-oid parameter was added across multiple storage SAS generation commands, and the az storage fs file generate-sas command was added entirely new in this release.
If you're getting errors like "az storage fs file generate-sas: command not found", that's because the command literally didn't exist before 2.81.0. Update your CLI and it will appear.
For existing SAS token generation workflows, the new --user-delegation-oid argument is optional but important for security-conscious deployments. It lets you explicitly pass the Object ID of the user or service principal for delegation, rather than relying on the currently logged-in identity. Here's the updated pattern for blob SAS generation:
az storage blob generate-sas \
--account-name mystorageaccount \
--container-name mycontainer \
--name myblob.txt \
--permissions r \
--expiry 2026-05-01 \
--auth-mode login \
--user-delegation-oid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"The same --user-delegation-oid argument is now available on az storage container generate-sas, az storage fs generate-sas, az storage fs directory generate-sas, az storage share generate-sas, az storage file generate-sas, and az storage queue generate-sas.
For file share and queue SAS operations, the --as-user flag was also added in 2.81.0. This tells the CLI to generate a user delegation SAS instead of an account SAS, a meaningful security improvement. If your audit or compliance team has flagged account SAS tokens as a risk, switching to --as-user on these commands is the right fix:
az storage share generate-sas \
--account-name mystorageaccount \
--name myshare \
--permissions rl \
--expiry 2026-05-01 \
--as-user \
--auth-mode loginIf this command returns a --as-user requires --auth-mode login error, make sure you've authenticated with az login rather than using a connection string or account key.
Advanced Troubleshooting
When the standard fixes don't cut it, or you're managing Azure CLI at scale across a fleet of developer machines, CI agents, or Azure DevOps environments, these deeper techniques will get you there.
Debugging command routing with verbose output: Append --debug to any failing command to see the full HTTP request/response cycle, the command parsing chain, and exactly where the CLI is going wrong. For commands that are being silently redirected (like the deprecated index-tuning group), debug output shows you the redirect happening in real time.
az postgres flexible-server autonomous-tuning list-index-recommendations \
--resource-group myRG \
--server-name myServer \
--debug 2>&1 | head -100Handling CLI installations in enterprise environments: In domain-joined machines with Group Policy managing software installations, az upgrade may fail silently or require elevation that standard users don't have. In this scenario, push the update through SCCM/Intune using the MSI installer package from Microsoft's official download page, or use a PowerShell Desired State Configuration (DSC) resource to enforce the version. The MSI package for Azure CLI accepts /quiet /norestart arguments for silent deployment.
Pinning CLI version in Azure DevOps pipelines: Add this task at the top of your pipeline YAML to guarantee a specific CLI version regardless of what's on the hosted agent:
- task: AzureCLI@2
inputs:
azureSubscription: 'myServiceConnection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az upgrade --yes --all
az versionFor tighter version pinning, use the AzureCLIVersion parameter in the Azure CLI Installer task, or install a specific version via the install script with curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash followed by az upgrade to reach a specific target version.
Event Viewer analysis on Windows: Azure CLI install failures sometimes leave traces in the Windows Event Log under Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server (Event ID 404) or in the standard Application log. Open Event Viewer (eventvwr.msc), filter for Error and Warning events in the last hour, and look for entries sourced from MsiInstaller. Error code 1603 almost always means a permissions problem, run the installer as Administrator. Error code 1618 means another installation is in progress and the system is locked.
SQL Managed Instance memory size parameter: If you're scripting az sql mi create or az sql mi update and hitting errors around memory configuration, the new --memory-size-gb parameter was added in 2.81.0. This is a required parameter in some SKU combinations and will throw an error on older CLI versions that don't recognize it.
NetAppFiles volume group creation: The --network-features parameter for az netappfiles volume-group create is available from 2.81.0 onward. If you're scripting ANF deployments and see an unrecognized argument error on this flag, a CLI update resolves it immediately.
az version output, the full --debug log of the failing command, and your subscription ID. Open a support ticket at Microsoft Support under the "Azure CLI / Azure SDK" category with severity set to B or A depending on production impact. Include the correlation ID from the debug output, it lets Microsoft engineers trace the exact API call in their backend logs.
Prevention & Best Practices
The Azure CLI team ships updates roughly every two to three weeks. That cadence is fast enough that if you're not actively managing your CLI version, you will hit breaking changes, it's just a matter of time. Here's how I set up teams so they never get blindsided again.
Subscribe to the Azure CLI GitHub Releases page. Go to the Azure/azure-cli repository on GitHub, click Watch, and choose "Custom" then "Releases." You'll get an email the moment a new version ships. The release notes always clearly mark breaking changes with a [BREAKING CHANGE] label. Read those first, before updating, especially in production automation contexts.
Use az upgrade in a staging environment first. Treat your Azure CLI version the same way you treat application dependencies, test updates in a lower environment before rolling them to production agents. If a breaking change breaks a script in staging, you catch it before it breaks a live deployment.
Audit your automation scripts against the changelog. Anytime you update, do a quick grep of your scripts for any command groups that appeared in the breaking changes list. For example, after 2.80.0 dropped:
grep -r "target-communication\|batch pool reset\|no-ssh-key" ./scripts/This takes five minutes and saves hours of debugging later.
Lock your CI/CD pipeline to a specific CLI version and schedule a dedicated "CLI version bump" task in your sprint backlog every month. This separates "upgrade and test" from "run production deployments" and makes breaking changes a planned event rather than a surprise.
- Run
az upgrade --allweekly on developer machines to stay current without accumulating large version gaps - Add
az versionas the first step in every CI pipeline so the version is always visible in your build logs - Set
az config set core.only_show_errors=falseto ensure deprecation warnings are never suppressed in local development - Keep a
requirements-azure-cli.txtfile in your infrastructure repo documenting the minimum CLI version your scripts require, updated with every breaking-change release
Frequently Asked Questions
Why does "az aks create" no longer create an SSH key automatically?
This changed in Azure CLI version 2.80.0, where the --no-ssh-key flag became the default behavior. Microsoft made this change to reduce the number of unmanaged SSH keys being created in customer environments as a security hardening measure. To get the old behavior back, add --generate-ssh-keys explicitly to your az aks create command. If you have existing automation that relied on auto-generation, search your scripts for az aks create and add that argument to each call.
My "az bicep install --version" command does nothing, how do I fix it?
This is the bug tracked as GitHub issue #32098, fixed in CLI version 2.81.0. The root cause was that when bicep.use_binary_from_path wasn't explicitly set to false, the CLI skipped the installation entirely when a --version was specified. First, update your CLI to 2.81.0 or later using az upgrade. Then run az config set bicep.use_binary_from_path=false followed by az bicep install --version vX.X.X with your target version. Verify with az bicep version, you should see the exact version you requested.
The "az postgres flexible-server index-tuning" command is giving errors, is it removed?
It's not fully removed, but it's deprecated and redirected. Starting with recent CLI releases, the index-tuning command group under az postgres flexible-server is being phased out in favor of the new autonomous-tuning command group. Replace az postgres flexible-server index-tuning calls with az postgres flexible-server autonomous-tuning list-index-recommendations or list-table-recommendations depending on what you need. The new command group offers the same functionality plus additional recommendation types. Update your scripts before the old command group is fully removed in a future release.
Can I upgrade to PostgreSQL 18 using the Azure CLI now?
Yes, major version upgrades to PostgreSQL 18 are now supported through az postgres flexible-server upgrade, starting with the CLI changes in the 2.81.0 release. Make sure your CLI is on 2.81.0 or later before attempting this command. Note that a major version upgrade is a significant operation, back up your data, check your application's PostgreSQL 18 compatibility, and run the upgrade during a maintenance window. The command will warn you before making irreversible changes.
How do I generate a user delegation SAS token with the new storage CLI arguments?
The --user-delegation-oid argument was added across blob, container, file system, directory, share, file, and queue SAS generation commands in version 2.81.0. To use it, authenticate with az login (not a connection string), pass --auth-mode login, and then include --user-delegation-oid with the Object ID of the delegating principal. For file shares and queues, you can also use the new --as-user flag to generate a user delegation SAS automatically without specifying an OID manually, the CLI will use the currently logged-in identity.
How do I manage multiple Azure CLI versions on the same machine?
Azure CLI doesn't have native version switching like nvm for Node.js, but there are workable approaches. The cleanest method for developers is to run each Azure CLI version inside a Docker container, Microsoft publishes official Azure CLI images (mcr.microsoft.com/azure-cli) tagged by version. For CI pipelines, use the AzureCLI installer task to pin a specific version per pipeline. On developer workstations where you need multiple versions side by side, Python virtual environments can isolate different CLI installs, though this requires a bit of setup. For most teams, pinning CI to a specific version and keeping local machines on the latest is the practical balance.