Azure Tools Blog articles

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Alex-wdy — Wed, 04 Feb 2026 07:41:52 GMT

Azure CLI on Windows MSI Upgrade Issue

Summary

About six months ago, some Windows users experienced an Azure CLI crash after upgrading via the MSI installer from Azure CLI 2.76.0 (or earlier) to 2.77.0 (or later). The failure occurred immediately on startup with: “ImportError: DLL load failed while importing win32file: The specified module could not be found.” This post explains what happened, why upgrades were affected (while clean installs typically worked), and what you can do to recover.

Who is affected?

You are likely affected if:

You installed Azure CLI using the Windows MSI installer.
You upgraded from Azure CLI 2.76.0 (or earlier) to 2.77.0 (or later) without fully uninstalling first.
After the upgrade, any az command fails with the win32file ImportError on startup.

Symptoms

Typical error output (Azure CLI/Azure PowerShell):

ImportError: DLL load failed while importing win32file: The specified module could not be found.

Immediate recovery

Upgrade to the latest version 2.83.0
If you want to install other versions of Azure CLI, perform a clean reinstall by uninstalling Microsoft Azure CLI from Windows Settings → Apps, deleting any remaining install folder (such as the CLI2 directory), reinstalling the latest Azure CLI using MSI or winget, and then verifying the installation with az --version.

Root cause analysis

During an affected MSI upgrade, the Azure CLI installation directory ended up missing a set of native Python extension files (.pyd files) required by the Windows integration layer. MSI logging showed components being blocked with messages indicating MSI believed the existing (older) key file was “newer” than the incoming one.

The root cause was an interaction between Windows Installer file versioning rules and a third‑party dependency packaging change. Azure CLI 2.76.0/2.77.0 consumed pywin32 311, whose .pyd binaries were missing Windows version resource metadata. When upgrading from a previous Azure CLI build that contained version-stamped pywin32 binaries (e.g., pywin32 306), MSI could treat the older versioned files as higher priority than the incoming non-versioned files. As a result, MSI could remove the old files during upgrade but skip installing the new ones, leaving the install incomplete.

Version mapping observed

Azure CLI version	Python	pywin32	pywin32 .pyd version resource
≤ 2.75.0	3.12	306	Present (e.g., 3.12.306.0)
2.76.0	3.12	311	Missing / empty
2.77.0+	3.13	311	Missing / empty

If you need to collect MSI logs （for support）

Run the installer with verbose logging （example）:

msiexec /i "azure-cli-2.77.0.msi" /l*vx "C:\temp\azure-cli-install.log"

References

https://github.com/Azure/azure-cli/issues/32045#issuecomment-3669161120

Windows MSI Upgrade Performance Optimization

The MSI upgrade process for Azure CLI on Windows has been significantly improved.

Previously, Windows Installer performed per‑file version comparisons—particularly expensive for Python runtime files—which made upgrades slow and sometimes inconsistent.

With the new logic, which skips the comparison and performs an overwrite installation. Upgrades now use a streamlined clean‑install process, resulting in faster and more reliable MSI upgrades.

Performance Improvements

Scenario	Before	After	Improvement
Fresh Install	Baseline	~5% faster	5% faster
Upgrade	Long due to file-by-file version comparison	~23% faster	23% faster

This update makes upgrades noticeably faster and more reliable by removing old files first and skipping slow per‑file version checks.

For more details, please refer to: [Packaging] Optimize MSI upgrade performance by simplifying file replacement logic by wangzelin007 · Pull Request #32678 · Azure/azure-cli

We encourage you to upgrade to the latest version of the Azure CLI. This will not only resolve the issue but also improve installation performance. Here is our release note.
If you encounter any problems, please feel free to report them on Azure CLI GitHub.

Release of Bicep Azure Verified Modules for Platform Landing Zone

ztrocinski — Mon, 02 Feb 2026 09:29:21 GMT

After months of collaboration and invaluable community feedback, we're thrilled to announce that Azure Verified Modules for Platform Landing Zone using Bicep is now generally available!

This release represents a significant milestone in the evolution of Azure Landing Zones. Bicep customers can now leverage the same modular, flexible, and battle-tested approach that our Terraform community has been using, all built on the foundation of Azure Verified Modules.

Why Azure Verified Modules?

Azure Verified Modules (AVM) represent Microsoft's unified approach to Infrastructure as Code. Born from the need to eliminate fragmentation across Microsoft's infrastructure-as-code (IaC) ecosystem, AVM provides consistent module standards, rigorous testing frameworks, and clear contribution guidelines.

The ALZ Bicep implementation now leverages AVM exclusively. Every resource you deploy uses verified resource or pattern modules from the AVM registry. This means you're building on modules that follow consistent engineering practices and are backed by official Microsoft support.

Based on your feedback, we've completely refactored the framework into a truly modular architecture, giving you the flexibility to compose your Platform Landing Zone exactly the way you need it.

New to Azure Verified Modules?

Azure Verified Modules is Microsoft's "One Microsoft" approach to IaC modules. It consolidates previously fragmented efforts across the organization into a single, unified library with consistent standards, testing, and support.

Explore the full catalog at azure.github.io/Azure-Verified-Modules.

What's New with this Framework?

Complete Customization

You asked for full control over every aspect of your deployment. We listened.

Every component is now customizable, from management group hierarchies to individual resource names and configurations.

Module Architecture: 19 Modules Working Together

The Bicep AVM starter module composed of 19 separate Azure Verified Modules: 16 resource modules and 3 pattern modules. Each module is independently versioned, tested, and maintained.

Here's how they work together:

Core - Governance (Management Groups)

Component	Path	AVM Module	Type
Int-Root MG	`core/governance/mgmt-groups/int-root/`	avm/ptn/alz/empty	Pattern
Platform MG	`core/governance/mgmt-groups/platform/`	avm/ptn/alz/empty	Pattern
├─ Connectivity	`platform/platform-connectivity/`	avm/ptn/alz/empty	Pattern
├─ Identity	`platform/platform-identity/`	avm/ptn/alz/empty	Pattern
├─ Management	`platform/platform-management/`	avm/ptn/alz/empty	Pattern
└─ Security	`platform/platform-security/`	avm/ptn/alz/empty	Pattern
Landing Zones MG	`core/governance/mgmt-groups/landingzones/`	avm/ptn/alz/empty	Pattern
├─ Corp	`landingzones/landingzones-corp/`	avm/ptn/alz/empty	Pattern
└─ Online	`landingzones/landingzones-online/`	avm/ptn/alz/empty	Pattern
Sandbox MG	`core/governance/mgmt-groups/sandbox/`	avm/ptn/alz/empty	Pattern
Decommissioned MG	`core/governance/mgmt-groups/decommissioned/`	avm/ptn/alz/empty	Pattern

Core - Logging

Component	Path	AVM Module	Type
Resource Group	`core/logging/`	avm/res/resources/resource-group	Resource
Log Analytics Workspace	`core/logging/`	avm/res/operational-insights/workspace	Resource
Azure Monitoring Agent	`core/logging/`	avm/ptn/alz/ama	Pattern

Networking - Hub and Spoke

Component	Path	AVM Module	Type
Resource Groups	`networking/hubnetworking/`	avm/res/resources/resource-group	Resource
Virtual Networks	`networking/hubnetworking/`	avm/res/network/virtual-network	Resource
Azure Firewall	`networking/hubnetworking/`	avm/res/network/azure-firewall, avm/res/network/firewall-policy	Resource
Azure Bastion	`networking/hubnetworking/`	avm/res/network/bastion-host, avm/res/network/network-security-group	Resource
VPN Gateway	`networking/hubnetworking/`	avm/res/network/virtual-network-gateway	Resource
ExpressRoute Gateway	`networking/hubnetworking/`	avm/res/network/virtual-network-gateway	Resource
Route Tables	`networking/hubnetworking/`	avm/res/network/route-table	Resource
DDoS Protection	`networking/hubnetworking/`	avm/res/network/ddos-protection-plan	Resource
Private DNS	`networking/hubnetworking/`	avm/ptn/network/private-link-private-dns-zones	Pattern
DNS Private Resolver	`networking/hubnetworking/`	avm/res/network/dns-resolver	Resource

Networking - Virtual WAN

Component	Path	AVM Module	Type
Resource Groups	`networking/virtualwan/`	avm/res/resources/resource-group	Resource
Virtual WAN	`networking/virtualwan/`	avm/res/network/virtual-wan	Resource
Virtual Hubs	`networking/virtualwan/`	avm/res/network/virtual-hub	Resource
ExpressRoute Gateway	`networking/virtualwan/`	avm/res/network/express-route-gateway	Resource
VPN Gateway (S2S)	`networking/virtualwan/`	avm/res/network/vpn-gateway	Resource
VPN Gateway (P2S)	`networking/virtualwan/`	avm/res/network/p2s-vpn-gateway	Resource
Sidecar VNet	`networking/virtualwan/`	avm/res/network/virtual-network	Resource
Azure Firewall	`networking/virtualwan/`	avm/res/network/azure-firewall, avm/res/network/firewall-policy	Resource
Azure Bastion	`networking/virtualwan/`	avm/res/network/bastion-host, avm/res/network/public-ip-address	Resource
DDoS Protection	`networking/virtualwan/`	avm/res/network/ddos-protection-plan	Resource
Private DNS	`networking/virtualwan/`	avm/ptn/network/private-link-private-dns-zones	Pattern
DNS Private Resolver	`networking/virtualwan/`	avm/res/network/dns-resolver	Resource

What This Means for You

The move to AVM delivers tangible benefits:

End-to-end customization: Configure every aspect of your Platform Landing Zone without limitations
Name everything your way: Apply your naming conventions to all resources and management groups
Flexible hierarchy: Restructure management groups with minimal effort as your organization evolves
Minimal hardcoded values: Just about every property is now configurable
Faster innovation: Multiple module owners means features and fixes arrive faster than ever

Azure Deployment Stacks

We've integrated Azure Deployment Stacks and it's a game changer for lifecycle management for Bicep.

What are Deployment Stacks?

Deployment Stacks track the resources that should exist based on your templates and automatically clean up anything that's no longer defined. It's somewhat similar to Terraform's state management, but native to Azure and built into the platform so you don't have to manage a state file.

Key Benefits

Feature	Benefit
No Manual Cleanup	No more manual cleanup required
Consistent State	Ensures consistency between your templates and deployed resources
Safe Deletion	Only removes resources managed by the deployment stack
Deployment History	Each deployment stack maintains its own history, separate from subscription/management group deployment history

NOTE: Drift detection currently relies on the what-if operator with a non-deployment stack approach. We will transition to deployment stack-based drift detection once it becomes generally available.

Modern Parameter Files

We've upgraded from JSON to .bicepparam files, a breath of fresh air for developer experience:

IntelliSense support: Real-time autocomplete and validation in VS Code
Function support: Use Bicep functions directly (no more workarounds!)
Variables: Define once, reuse everywhere
Comments: Document your configuration inline for better team collaboration

Deployment with the ALZ Accelerator

The Azure Landing Zones IaC Accelerator remains your fastest path to a production-ready Platform Landing Zone.

Bicep AVM is now the default starter module and the focus of all future development. It implements enterprise best practices out of the box for both Azure Pipelines and GitHub Actions.

Configuration Made Simple

Previously, customization was limited to a handful of parameters like location and network_type. Those days are over.

The new platform-landing-zone.yaml configuration file gives you quite a bit more control (and more is planned in the near term):

Management group structure: Customize the entire hierarchy with your naming and organization
Resource naming: Apply consistent naming patterns across all resource groups
Network architecture: Choose between Hub & Spoke (hubNetworking), Virtual WAN (vwanConnectivity), or no networking (none)
Azure regions: Deploy to any combination of regions for your requirements

Example Configuration

## Platform Landing Zone Azure Regions
starter_locations: ["eastus", "westus2"]

# Management Groups - Full customization of naming
management_group_id_prefix: "contoso"
management_group_int_root_id: "alz"
management_group_int_root_name: "Contoso Landing Zones"

# Resource Groups - Consistent naming patterns
resource_group_logging_name_prefix: "rg-alz-logging"
resource_group_hub_networking_name_prefix: "rg-alz-conn"
resource_group_dns_name_prefix: "rg-alz-dns"

# Networking - Choose your architecture
network_type: "hubNetworking"  # Options: hubNetworking, vwanConnectivity, none

We plan to add more specific options that can be overridden prior to bootstrapping as well. Comment below if you think anything in particular should be provided – maybe whether or not DDoS should be enabled... 😁

Independent Policy Management with the ALZ Library

Like the Terraform implementation, Bicep AVM now leverages the Azure Landing Zones Library.

The key innovation? Decoupled update cycles. The Library separates policy data from deployment logic, which means:

Update the module to get bug fixes without touching policies
Refresh policies to the latest ALZ Library version without updating other components
No more forced coupling between infrastructure changes and policy updates

The ALZ Bicep specific Library documentation provides full details. Our vision is to make this the single source of truth for policies across all ALZ implementations: Portal, Terraform, and Bicep.

Custom Policies Without the Upgrade Pain

We've heard your frustrations about "upgrade hell" when customizing policies in classic ALZ-Bicep. The new approach aims to solve or at least improve considerably:

Direct library integration: Leverage the ALZ library directly in your deployments
Clean separation: Your custom policies stay separate from ALZ defaults
Built-in customization: Each management group module includes dedicated properties for your custom policies

Update ALZ defaults independently from your custom policies without merge conflicts or upgrade headaches.

The Future of ALZ-Bicep Classic

With Bicep AVM now generally available and set as the default in the ALZ Accelerator for Bicep, we're beginning the deprecation process for classic ALZ-Bicep.

Timeline

Date	Action
Now	Bicep - Azure Verified Modules for Platform Landing Zone (ALZ) is the default starter module
February 16th, 2026	Bicep (Classic) starter module removed from Accelerator
February 16th, 2027	ALZ-Bicep repository archived

Currently, ALZ-Bicep is still supported in the Accelerator as "Bicep Classic - Complete" (documentation), but this will be removed in entirety on February 16th, 2026.

Although it will be removed from the Accelerator, the ALZ-Bicep repository will still be supported in terms of:

Bug fixes
Security patches
Policy refreshes

...for a period of 12 months after that date. After February 16th, 2027, the ALZ-Bicep repository will be archived and no longer supported.

Migration Support

A comprehensive migration guide is coming soon to help you transition from classic ALZ-Bicep to Bicep AVM. We'll provide step-by-step instructions and tooling to make the process as smooth as possible. Stay tuned!

Gaining Confidence with Az CLI and Az PowerShell: Introducing What if & Export Bicep

stevenbucher — Fri, 21 Nov 2025 18:39:06 GMT

Ever hesitated before hitting Enter on a command, wondering what changes it might make? You’re not alone. Whether you’re deploying resources or updating configurations, the fear of unintended consequences can slow you down. That’s why we’re introducing new powerful features in Azure CLI and Azure PowerShell to preview the changes the commands may make: the What if and Export Bicep features.

These capabilities allow you to preview the impact of your commands and allow you to export them as Bicep templates, all before making any changes to your Azure environment. Think of them as your safety net: you can validate actions, confirm resource changes, and even generate reusable infrastructure-as-code templates with confidence.

Currently, these features are in private preview, and we’re excited to share how you can get early access.

Why This Matters

Reduce risk: Avoid accidental resource deletions or costly misconfigurations.
Build confidence: Understand exactly what your command will do before execution.
Accelerate adoption of IaC: Convert CLI commands into Bicep templates automatically.
Improve productivity: Validate scripts quickly without trial-and-error deployments.

How It Works

What if preview of commands

All you have to do is add the `--what-if` parameter to Azure CLI commands and then the `-DryRun` command to Azure PowerShell commands like below.

Azure CLI:

az storage account create --name "mystorageaccount" --resource-group "myResourceGroup" --location "eastus" --what-if

Azure PowerShell:

New-AzVirtualNetwork -name MyVNET -ResourceGroupName MyResourceGroup -Location eastus -AddressPrefix "10.0.0.0/16" -DryRun

Exporting commands to Bicep

To generate bicep from the command you will have to add the `--export-bicep` command with the --what-if parameter to generate a bicep file. The bicep code will be saved under the `~/.azure/whatif` directory on your machine. The command will specific exactly where the file is saved on your machine.

Behind the scenes, AI translates your CLI command into Bicep code, creating a reusable template for future deployments. After generating the Bicep file, the CLI automatically runs a What-If analysis on the Bicep template to show you the expected changes before applying them.

Here is a video of it in action!

Here is another example where there is delete, modify and create actions happening all together.

Private Preview Access

These features are available in private preview. To sign up:

Visit the aka.ms/PreviewSignupPSCLI
Submit your request for access.
Once approved, you’ll receive instructions to download the preview package.

Supported Commands (Private Preview)

Given these features are in a preview we have only added support for a small set of commands for the time being. Here’s a list of commands that will support these features during the private preview:

Azure CLI

Az vm create
Az vm update
az storage account create
az storage container create
az storage share create
az network vnet create
az network vnet update
az storage account network-rule add
az vm disk attach
az vm disk detach
az vm nic remove

Azure PowerShell

New-AzVM
Update-AzVM
New-AzStorageAccount
New-AzRmStorageShare
New-AzRmStorageContainer
New-AzVirtualNetwork
Set-AzVirtualNetwork
Add-AzStorageAccountNetworkRule

Next Steps

Sign up for the private preview.
Install the packages using the upcoming script.
Start using --what-if, -DryRun, and --export-bicep to make safer, smarter decisions and accelerate your IaC journey.
Give us feedback on what you think of the feature! At https://aka.ms/PreviewFeedbackWhatIf

Thanks so much!

Steven Bucher

PM for Azure Client Tools

Azure CLI and Azure PowerShell Ignite 2025 Announcement

Alex-wdy — Wed, 19 Nov 2025 19:13:15 GMT

In 2025, the key investment areas for Azure CLI and Azure PowerShell are quality and security. We have also made significant efforts to improve the overall user experience. Meanwhile, AI remains a central theme.

At Microsoft Ignite 2025, we are pleased to announce several new features related to these priorities:

In terms of security: MFA enforcement
Azure CLI Upgrade and Python 3.13 Compatibility explanation
New feature: Azure CLI and Azure PowerShell -What-If and -export bicep parameter

Extending our coverage

We’ve rolled out significant updates across Azure CLI and Azure PowerShell to enhance functionality:

Azure CLI and Azure PowerShell Upgrades

Services updated: ACR, ACS, AKS, App Config, App Service, ARM, ARO, Backup, Batch, Cloud, Compute, Consumption, Container, Container app, Core, Cosmos DB, Cognitive Services, DMS, Eventhub, HDInsight, Identity, IoT, Key Vault, MySQL, NetAppFiles, Network, Packaging, Profile, RDBMS, Service Fabric, SQL, Storage.

New Extensions for Azure CLI and Azure PowerShell

Extensions added: arize-ai,connectedmachine,containerapp,lambda-test,migrate,neon,pscloud,sftp,site,storage-blob-preview.

New GA Modules for Azure CLI and Azure PowerShell

Modules are now generally available: DeviceRegistry, DataMigration, FirmwareAnalysis,LoadTesting,StorageDiscovery , DataTransfer, ArizeAI, Fabric, StorageAction, Oracle

For detailed release notes:  

Azure CLI: https://learn.microsoft.com/cli/azure/release-notes-azure-cli 
Azure PowerShell:  https://learn.microsoft.com/powershell/azure/release-notes-azureps

Azure CLI Upgrade and Python 3.13 Compatibility Notes

Azure CLI has been upgraded from version 2.76 to 2.77 primarily to address several security vulnerabilities (CVE), including issues related to remote code execution risks and certificate validation flaws in underlying dependencies, ensuring compliance with the latest security standards.

This upgrade requires Python to move from 3.12 to 3.13, which introduces a significant change:
Python 3.13 enforces stricter SSL verification rules, causing failures for users running behind proxies that intercept HTTPS traffic.
Solution: Update your proxy certificate to comply with strict mode. For instance, Mitmproxy fixed this in version v10.1.2 (reference: https://github.com/Azure/azure-cli/issues/32083#issuecomment-3274196488).

For more Python3.13 details, see What’s New In Python 3.13 .

Handling Claims Challenges for MFA in Azure CLI and Azure PowerShell

Claims challenges appear when ARM begins enforcing MFA requirements. If a user performs create, update, or delete operations without the necessary MFA claims, ARM rejects the request and returns a claims challenge, indicating that higher-level authentication is required before the API call can proceed. This mechanism is designed to ensure sensitive operations are performed only by users who have completed MFA.

The challenge arises because Azure CLI and Azure PowerShell can only acquire MFA claims during the login phase, and only if the user’s account is configured to require MFA. Changing this setting affects all services associated with the account, and many customers are reluctant to enable MFA at the account level. As a result, when a claims challenge occurs, Azure CLI and Azure PowerShell cannot automatically trigger MFA in the same way Azure Portal does.

Azure CLI example:

az login --tenant "aaaabbbb-0000-cccc-1111-dddd2222eeee" --scope "https://management.core.windows.net//.default" --claims-challenge "<claims-challenge-token>"

For more details, see:

Azure CLI: Troubleshooting Azure CLI | Microsoft Learn

Azure PowerShell example:

Connect-AzAccount -Tenant yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyy -Subscription zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzz -ClaimsChallenge <claims-challenge-token>

For more details, see:

Azure PowerShell: Troubleshooting the Az PowerShell module | Microsoft Learn

Advanced cloud analysis capabilities, involving capacity insights or forecasting in Azure CLI

With this update, Azure CLI now uses the latest ARM API version (2022-09-01) for endpoint discovery during cloud registration and updates, replacing the older API versions previously used. This ensures more accurate and up-to-date service endpoints, simplifies the configuration of custom Azure clouds, and improves reliability when retrieving required endpoints. By adopting the new API, Azure CLI stays aligned with the latest Azure platform capabilities, increasing both compatibility and forward-compatibility. As a result, users benefit from more accurate endpoint discovery and improved support for new Azure features and service endpoints as they become available.

For more details about managing cloud environments in Azure CLI, please refer to the official documentation: Azure cloud management with the Azure CLI | Microsoft Learn

Azure PowerShell - Add Pagination Support for 'Invoke-AzRestMethod' via '-Paginate' parameter

Invoke-AzRestMethod is a flexible fallback for calling Azure Management APIs, returning raw HTTP responses from underlying endpoints, but it currently lacks built-in pagination, forcing users to implement custom logic when working with large datasets. Since pagination was not part of the original design, changing the default behavior could break existing scripts that depend on the current response format and nextLink handling. To address this without disruption, we plan to introduce pagination as an optional opt-in feature, enabling users to retrieve complete datasets through server-driven pagination without writing custom code while preserving the current behavior by default for full backward compatibility.

For more details, see the official documentation for Invoke-AzRestMethod: Invoke-AzRestMethod (Az.Accounts) | Microsoft Learn

Introducing Azure CLI and Azure PowerShell -What-If and -export bicep parameter

We’re introducing two new features in both Azure CLI and Azure PowerShell: the What-If and Export Bicep parameters. The What-If parameter gives you an intelligent preview of which resources will be created, updated, or deleted before a command runs, helping you catch issues early and avoid unexpected changes. The Export Bicep parameter generates the corresponding Bicep templates to streamline your infrastructure-as-code workflows. Both features leverage AI to assist with command interpretation and template generation. If you’d like to try these capabilities in Azure CLI and Azure PowerShell, you can sign up through our form.

Please stay tuned for more updates.

Breaking Changes 

The latest breaking change guidance documents can be found at the links below. To read more about the breaking changes migration guide, ensure your environment is ready to install the newest version of Azure CLI and Azure PowerShell.

Azure CLI: Release notes & updates – Azure CLI | Microsoft Learn

Azure PowerShell: Migration guide for Az 15.0.0 | Microsoft Learn

Milestone timelines:

Azure CLI Milestones

Azure PowerShell Milestones

Thank you for using the Azure command-line tools. We look forward to continuing to improve your experience. We hope you enjoy Ignite and all the great work released this week. We'd love to hear your feedback, so feel free to reach out anytime.  

GitHub:

o https://github.com/Azure/azure-cli

o https://github.com/Azure/azure-powershell

Let's be in touch on X (Twitter) : @azureposh   @AzureCli

Accelerating Infrastructure as Code: Introducing Game-Changing Terraform Features for Azure

stevenjma — Fri, 26 Sep 2025 15:53:50 GMT

We're thrilled to announce a suite of powerful new features from the Terraform on Azure Team that will revolutionize how you build, manage, and deploy infrastructure. These enhancements deliver an unprecedented end-to-end experience that makes Terraform on Azure more accessible, intelligent, and comprehensive than ever before.

Seamless Code Generation to Deployment Experience

Public Preview: October 2025

Say goodbye to starting from scratch. Our new integrated workflow transforms how you create and deploy Terraform configurations through a streamlined journey that begins right in the Azure portal.

With Copilot in Azure, you can now describe your infrastructure requirements in natural language and watch as production-ready Terraform code materializes before your eyes. This AI-powered assistant understands your intent and generates optimized HCL code that follows best practices—no more hunting through documentation or wrestling with syntax.

The experience seamlessly transitions to VS Code for the web, where you can view, refine, and iterate on your generated code in a familiar development environment. Make adjustments, test configurations, and collaborate with your team—all without leaving your browser. When you're satisfied with your infrastructure definition, deploy with confidence using either HCP Terraform or Azure for state management, ensuring your infrastructure remains consistent and trackable.

Unified VS Code Extension: Your Complete Terraform Toolkit

Public Preview: Available Now

We've consolidated the Terraform development experience into a single, powerful VS Code extension from Microsoft that serves as your command center for all things Terraform from Microsoft.

IntelliSense support for all Microsoft providers brings intelligent code completion, parameter hints, and inline documentation directly to your fingertips, dramatically reducing errors and accelerating development. No more context switching to check resource schemas or argument names—everything you need appears as you type.

Jump-start your projects with Code Samples that provide fully functional, production-ready templates for common Azure architectures. Whether you're building a microservices platform, data pipeline, or enterprise network, these samples give you a solid foundation to build upon.

The game-changing Export Terraform feature allows you to reverse-engineer your existing Azure infrastructure into clean HCL code directly from VS Code. This bridges the gap between manually created resources and Infrastructure as Code, making it easier than ever to adopt Terraform for existing environments.

Perhaps most importantly, the Policy/Preflight validation capability goes beyond traditional terraform plan by leveraging Azure's preflight system. This advanced validation catches configuration issues, policy violations, and potential deployment problems before they impact your environment. Validate against organizational policies, compliance requirements, and Azure best practices—all before a single resource is created.

MS Graph Provider: Extending Terraform Beyond Infrastructure

Public Preview: Available Now

Infrastructure doesn't exist in isolation, and neither should your Terraform configurations. The new MS Graph provider brings the same declarative power you love about the Azure provider to the entire Microsoft ecosystem.

Built with an AzAPI-like architecture for day-zero support of new features, this provider enables you to manage resources across the Microsoft platform including Microsoft 365 configurations, Windows settings, Enterprise Mobility + Security policies, and Dynamics 365 customizations. Manage users, groups, applications, and security policies alongside your Azure infrastructure—all in the same Terraform configuration.

This unified approach means you can now define your entire organizational IT landscape as code, from the Azure resources powering your applications to the Microsoft 365 settings governing user productivity and security policies protecting your data.

Ready to Transform Your Infrastructure Journey?

These features represent our commitment to making Terraform a first class tool for managing Azure and Microsoft resources. Whether you're new to Infrastructure as Code or a seasoned practitioner, these enhancements will accelerate your workflow and expand what's possible with Terraform.

Get started today by updating your VS Code extension and exploring the new Copilot experience in the Azure portal. The future of infrastructure automation on Azure is here—and it's more powerful than ever.

Visit our documentation to learn more and join our community to share feedback and connect with other Terraform on Azure users. Together, we're building the future of cloud infrastructure.

Terraform on Azure Product Group

Announcing MSGraph Provider Public Preview and the Microsoft Terraform VSCode Extension

stevenjma — Thu, 14 Aug 2025 17:56:30 GMT

We are thrilled to announce two exciting developments in the Microsoft ecosystem for Terraform infrastructure-as-code (IaC) practitioners: the public preview of the Terraform Microsoft Graph (MSGraph) provider and the release of the Microsoft Terraform Visual Studio Code (VSCode) extension. These innovations are designed to streamline your workflow, empower your automation, and make managing Microsoft cloud resources easier than ever.

Public Preview: Terraform Microsoft Graph (MSGraph) Provider

The Terraform MSGraph provider empowers you to manage Entra APIs like privileged identity management as well as M365 Graph APIs like SharePoint sites from day 0 by leveraging the power and flexibility of HashiCorp Configuration Language (HCL) in Terraform.

resource "msgraph_resource" "application" { url = "applications" body = { displayName = "My Application" } response_export_values = { all = "@" app_id = "appId" } } output "app_id" { value = msgraph_resource.application.output.app_id } output "all" { // it will output the whole response value = msgraph_resource.application.output.all }

Historically, Terraform users could utilize the `azuread` provider to manage Entra features like users, groups, service principals, and applications. The new `msgraph` provider also supports these features and extends functionality to all beta and v1 Microsoft Graph endpoints.

Querying role assignments for a service principal

The below example shows how to use the `msgraph` provider to grant app permissions to a service principal:

locals { MicrosoftGraphAppId = "00000003-0000-0000-c000-000000000000" # AppRoleAssignment userReadAllAppRoleId = one([for role in data.msgraph_resource.servicePrincipal_msgraph.output.all.value[0].appRoles : role.id if role.value == "User.Read.All"]) userReadWriteRoleId = one([for role in data.msgraph_resource.servicePrincipal_msgraph.output.all.value[0].oauth2PermissionScopes : role.id if role.value == "User.ReadWrite"]) # ServicePrincipal MSGraphServicePrincipalId = data.msgraph_resource.servicePrincipal_msgraph.output.all.value[0].id TestApplicationServicePrincipalId = msgraph_resource.servicePrincipal_application.output.all.id } data "msgraph_resource" "servicePrincipal_msgraph" { url = "servicePrincipals" query_parameters = { "$filter" = ["appId eq '${local.MicrosoftGraphAppId}'"] } response_export_values = { all = "@" } } resource "msgraph_resource" "application" { url = "applications" body = { displayName = "My Application" requiredResourceAccess = [ { resourceAppId = local.MicrosoftGraphAppId resourceAccess = [ { id = local.userReadAllAppRoleId type = "Scope" }, { id = local.userReadWriteRoleId type = "Scope" } ] } ] } response_export_values = { appId = "appId" } } resource "msgraph_resource" "servicePrincipal_application" { url = "servicePrincipals" body = { appId = msgraph_resource.application.output.appId } response_export_values = { all = "@" } } resource "msgraph_resource" "appRoleAssignment" { url = "servicePrincipals/${local.MSGraphServicePrincipalId}/appRoleAssignments" body = { appRoleId = local.userReadAllAppRoleId principalId = local.TestApplicationServicePrincipalId resourceId = local.MSGraphServicePrincipalId } }

SharePoint & Outlook Notifications

With your service principals properly configured, you can set up M365 endpoint workflows such an outlook notification template list as shown below. The actual service principal setup has been omitted from this code sample for the sake of brevity, but you will need Sites.Manage.All, Sites.ReadWrite.All, User.Read, and User.Read.All permissions for this example to work:

data "msgraph_resource" "sharepoint_site_by_path" { url = "sites/microsoft.sharepoint.com:/sites/msgraphtest:" response_export_values = { full_response = "@" site_id = "id || ''" } } resource "msgraph_resource" "notification_templates_list" { url = "sites/${msgraph_resource.sharepoint_site_by_path.output.site_id}/lists" body = { displayName = "DevOps Notification Templates" description = "Centrally managed email templates for DevOps automation" template = "genericList" columns = [ { name = "TemplateName" text = { allowMultipleLines = false appendChangesToExistingText = false linesForEditing = 1 maxLength = 255 } }, { name = "Subject" text = { allowMultipleLines = false appendChangesToExistingText = false linesForEditing = 1 maxLength = 500 } }, { name = "HtmlBody" text = { allowMultipleLines = true appendChangesToExistingText = false linesForEditing = 10 maxLength = 10000 } }, { name = "Recipients" text = { allowMultipleLines = true appendChangesToExistingText = false linesForEditing = 3 maxLength = 1000 } }, { name = "TriggerConditions" text = { allowMultipleLines = true appendChangesToExistingText = false linesForEditing = 5 maxLength = 2000 } } ] } response_export_values = { list_id = "id" list_name = "displayName" web_url = "webUrl" } }

The MSGraph provider is to AzureAD as the AzAPI provider is to AzureRM. Since support for resource types is automatic, you can access the latest features and functionality as soon as they're released via the provider. AzureAD will continue to serve as the convenience layer implementation of a subset of Entra APIs.

We invite you to try the new provider today:

- Deploy your first msgraph resources

- Check out the registry page

- Visit the provider GitHub

Introducing the Microsoft Terraform VSCode Extension

The new official Microsoft Terraform extension for Visual Studio Code consolidates AzureRM, AzAPI, and MSGraph VSCode support into a single powerful extension. The extension supports exporting Azure resources as Terraform code, as well as IntelliSense, syntax highlighting, and code sample generation. It replaces the Azure Terraform and AzAPI VSCode extensions and adds some new features.

Installation & Migration

New users can install the extension by searching “Microsoft Terraform” within Visual Studio Marketplace or their “Extensions” tab. Users can also click this link to the Visual Studio marketplace.

Users of the “Azure Terraform” extension can navigate to “Extensions” tab and selecting the old extension. Select the “Migrate” button to move to the new extension.

Users of the “Terraform AzAPI Provider” extension will be directed to the new extension:

New Features

Export Azure Resources As Terraform

This feature allows you to export existing Azure resources as Terraform configuration blocks using Azure Export for Terraform. This helps you migrate existing Azure resources to Terraform-managed infrastructure.

Open the Command Palette (Command+Shift+P on macOS and Ctrl+Shift+P on Windows/Linux).
Search for and select the command Microsoft Terraform: Export Azure Resource as Terraform.
Follow the prompts to select the Azure subscription and resource group containing the resources you want to export.

Select the azurerm provider or the azapi provider to export the resources.
The extension will generate the Terraform configuration blocks for the selected resources and display them in a new editor tab.

Support for MSGraph

The new extension comes fully equipped with intellisense, code completion, and code samples just like the AzAPI provider. See the next section for recorded examples of these features within the AzureRM & AzAPI providers.

Preexisting Features

Intelligent Code Completion:

Benefit from context-aware suggestions, like property names or resource types.

Code Samples:

Quickly insert code samples for your resources:

Paste as AzAPI:

Copy your existing resource JSON or ARM Templates into VSCode with the Microsoft Terraform extension, and it will automatically convert your code into AzAPI. The below example takes a resource JSON from the Azure Portal and pastes it into VSCode as AzAPI:

Migrate AzureRM to AzAPI:

Move existing AzureRM code to the AzAPI provider whenever you wish to. Read more in the Guide to migrate AzureRM resources to AzAPI

Feedback

We value your feedback! You can share your experience with the Microsoft Terraform extension by running the command Microsoft Terraform: Show Survey from the Command Palette. Your input helps us improve the extension and better serve your needs.

Conclusion

Whether you are managing traditional Azure resources, modern Microsoft Graph environments, or a combination of both, the new MSGraph provider and Microsoft Terraform VS Code extension are designed to help you deliver robust, reliable infrastructure—faster and with greater confidence.

Stay tuned for further updates, workshops, and community events as we continue to evolve these offerings. Your feedback and participation are invaluable as we build the next generation of infrastructure automation together.

Terraform Azure Verified Modules for Platform Landing Zone (ALZ) Migration Guidance and Tooling

jaredfholgate — Thu, 10 Jul 2025 16:29:00 GMT

We are very pleased to announce that migration guidance and tooling to aid Terraform import is now moving from public preview to being generally available.

Where to find it

Head over to aka.ms/alz/tf/migrate to read our guidance and find our tooling.

What does it do

The migration guidance talks you through the procedure to migrate Terraform state from the classic CAF Enterprise Scale module to the Terraform Azure Verified Modules for Platform Landing Zone (ALZ) modules. The guidance and tooling helps you generate a set of Terraform import blocks to import the state of your existing platform landing zones into the Azure Verified Modules (AVM).

Once those blocks have been generated, you can raise a pull request, test and merge then apply with your continuous delivery tool to import the state. From there forwards, you will be managing the platform landing zone with the AVM.

How does it work

The migration tool aids in mapping your deployed Microsoft Azure resources against the Azure Verified Modules. It maps on name or other available attributes.

The tool follows a 3 stage process:

Setup
Resource Mapping
Resource Attribute Mapping

Setup

This stage involves you configuring the target Terraform module by using the ALZ IaC Accelerator or composing your own module for advanced use cases. You will also need to identify your existing management group hierarchy and platform subscriptions in this stage.

Resource Mapping

During this stage you will run the migration tool. The tool will attempt to match all resources in the target subscriptions and / or management groups against the Azure Verified Module planned resources. For anything it can't match on, it will provide details in a file called issues.csv.

You'll review issues.csv and correct any resource names in the target module to ensure they match your existing resource names. You'll then run the tool again and repeat until you have matched everything you can. We provide example tfvars files and lib folder to make this easier, they are commented with things you'll likely need to change.

Once you have updated all the names you can, if you still have any issues left in issues.csv, you'll need to specify what you want to do with them. You can either:

Ignore them
Destroy and Recreate them
Destroy them

You'll add the action against each row in the CSV and then save the CSV file as resolved-issues.csv ready for the next stage.

Resource Attribute Mapping

Now you've mapped the resources themselves, you'll need to check that the attributes of the resources also match your existing configuration where they need to. To help with this you'll run the tool again, this time supplying your resolved-issues.csv as an input. This will prompt the tool to generate the Terraform import blocks and run a Terraform plan. The tool outputs a simplified plan file that only includes the changes you need to care about, namely update and destroy and recreate.

You'll review the simplified plan file and determine if anything in there requires an update to your target module. If it does, you can update it and re-run the tool. You can repeat this until all unwanted changes are handled.

You'll run the tool one last time to generate the final set of imports and now you are ready to apply the Terraform via your standard CI / CD process.

Limitations

At this time our guidance only supports resources that can be deployed by the classic CAF Enterprise Scale module. The tooling can technically support importing any resources, but we don't provide support or guidance for that scenario.

The documentation of the tool for advanced scenarios is currently limited and we assume usage for this use case only at this time.

Tooling

This migration guidance uses a generic tool called Terraform State Importer . This tool can be used to migrate state for any Azure Resource Manager Terraform resources to a new Terraform module. We provide specific configuration files and settings for this use case, but you could modify them for more advanced scenarios.

The tool does not look at any existing module or Terraform state file, it directly queries Azure using KQL queries to identify your deployed resources, as such it could also be used to import resources deployed via ClickOps, ARM or Bicep too.

Thanks

Thanks to the following people for making this happen:

Matt White and Jack Tracey for technical guidance and validation
Paul Grimley and Charlie Grabiaud for keeping it on track
Haflidi Fridthjofsson (Microsoft) and Aidan Hughes (Servent) for the comprehensive and very valuable testing and feedback

Azure Verified Modules: Support Statement & Target Response Times Update

jtracey93msft — Mon, 09 Jun 2025 16:18:14 GMT

We are announcing an update to the Azure Verified Modules (AVM) support statement. This change reflects our commitment to providing clarity alongside timely and effective support for our community and AVM module consumers.

These changes are in preparation to allow us to enable AVM modules to be published as V1.X.X modules (future announcement on this soon 🥳 sign up to the next AVM Community Call on July 1st 2025 to learn more).

What is the new support statement?

You can find the support statement on the AVM website here: https://azure.github.io/Azure-Verified-Modules/help-support/module-support/#support-statements

For bugs/security issues

5 business days for a triage, meaningful response, and ETA to be provided for fix/resolution by module owner (which could be past the 5 days)
- For issues that breach the 5 business days, the AVM core team will be notified and will attempt to respond to the issue within an additional 5 business days to assist in triage.
- For security issues, the Bicep or Terraform Product Groups may step in to resolve security issues, if unresolved, after a further additional 5 business days.

For feature requests

15 business days for a meaningful response and initial triage to understand the feature request. An ETA may be provided by the module owner if possible.

Key changes from the previous support statement

In short its two items:

Increasing response time targets from:
- 3 to 5 business days for issues
  - And from 3 to 5 business days for AVM core team escalation
Handling bugs/security issues separately from feature requests
- Feature requests now have a 15 business day target response time

The previous support statement outlined a more rigid structure for issue triage and resolution. It required module owners/contributors to respond within 3 business days, with the AVM core team stepping in if there was no response within a further 24 hours. In the event of a security issue being unaddressed after 5 business days, escalation to the product group (Bicep/Terraform) would occur to assist the AVM core team. There was also no differentiation between bugs/security issues and feature requests, which there now is.

You can view the git diff of the support statement here

Why the changes?

Being honest, we weren't meeting the previous support statement 100% of the time, which we are striving for, across all the AVM modules. And we heard from you that, that wasn't ideal and we agree whole heartedly.

Therefore, we took a step back, reflected, looked at the data available and huddled together to redefine what the new AVM support statement and targets should be.

"Yeah, but why can't you just meet the previous support statement and targets?"

This is a very valid question that you may have or be wondering. And we want to be honest with you so here are the reasons why this isn't possible today:

Module owners are not 100% dedicated to only supporting their AVM modules; they also have other daily roles and responsibilities in their jobs at Microsoft.
- Sometimes this also means conflicting priorities for module owners and they have to make a priority call.
We underestimated the impact of holidays, annual leave, public holidays etc.
The AVM core teams responsibility is not to resolve all module issues/requests as they are smaller team driving the AVM framework, specs, tooling and tests.
- They will of course step in when needed, as they have done so far today 👍
We don't get as many contributions from the open-source community as we expected and would still love to see 😉
- For clarity we always love to see a Pull Request to help us add new features or resolve bugs and issues, even for simple things like typos. It really does help us go faster 🏃‍➡️

"How are you going to try and avoid changing (increasing) the support statement and targets in the future?"

Again another very valid ask! And we reflected upon this when making these changes to the support statement we are announcing here.

To avoid this potential risk we are also taking the following actions today:

Building new internal tooling and dashboards for module owners to discover, track and monitor their issues and pull requests across various modules they may own, across multiple languages. (already complete and published 👍)
- This tooling will also help the AVM core team track issues and report on them more easily to help module owners avoid non-compliance with the targets.
Continue to push for, promote, and encourage open-source community contributions
Prevent AVM modules being published as V1.X.X if they are unable to prove compliance with the new support statement and targets (sneak peek into V1.X.X requirements)

Looking further into the future we are also investigating the following:

Building a dedicated AVM team, separate from the AVM core team, that will triage, work on, and fix/resolve issues that are nearing or breaching the support statement and targets.
- Also they will look into feature requests as and where time allows or are popular/upvoted heavily where module owners are unable to prioritize in the near future due to other priorities.
Seeing where AI and other automation tooling can assist with issue triage and resolution to reduce module owner workload.

Summary

We hope that this provides you with a clear understanding of the changes to the AVM support statement and targets and why we are making these. We also hope you appreciate our honesty on the situation and can see we are taking action to make things better while also reflecting and amending our support statements to be more realistic based on the past 2 years of launching and running AVM to date.

Finally we just want to reassure everyone that we remain committed to AVM and have big plans for the rest of the calendar year and beyond! 😎

And with this in mind we want to remind you to sign up to the next AVM Community Call on July 1st 2025 to learn more and ask any questions on this topic or anything else AVM related with the rest of the community 👍

Thanks

The AVM Core Team

Announcement of migrating to Azure Linux 3.0 for Azure CLI

JeremyLi — Wed, 04 Jun 2025 05:47:54 GMT

Azure CLI 2.74.0 is the final version available on Azure Linux (Mariner) 2.0 and will not receive further updates. We recommend migrating to Azure Linux 3.0 to access newer versions of Azure CLI and continue receiving updates.

A warning message will appear when using Azure CLI on Azure Linux 2.0. To suppress this message, set the AZURE_CLI_DISABLE_AZURELINUX2_WARNING environment variable to any value.

We value the experiences of our Azure CLI users, especially when lifecycle changes might cause disruptions. Our goal is to provide clear communication and as much advance notice as possible.

Quoting our internal partner, the Azure Linux team, as follows:

Azure Linux 2.0 will reach its End of Life (EOL) on July 2025. After this date, it will no longer receive updates, security patches, or support, which may put your systems at risk. From today, we will not be entertaining package upgrade requests for Azure Linux 2.0.

To ensure continued support, security, and performance, we strongly recommend upgrading to Azure Linux 3.0 by June 2025. Azure Linux 3.0 comes with enhanced features, better performance, and longer support, making it better choice for your infrastructure moving forward. Learn more about 3.0 here.

We understand that migrations can take time, so we encourage you to begin planning your upgrade as soon as possible. Our Azure Linux team is available to assist with the transition, address any concerns, and help make the process as seamless as possible.

Is this the same as Mariner?
Yes, Mariner was rebranded to Azure Linux. We will slowly update our documentation and VM/container image tags to reflect this name change

When did Azure Linux 3.0 GA?
Azure Linux 3.0 became generally available in August 2024.

When will Azure Linux 3.0 reach End of Life (EOL)?
We currently support each major version for 3 years after it becomes generally available. Azure Linux 3.0 will reach EOL in Summer 2027.

Azure CLI 2.74.0 (scheduled for release on 2025-06-03) is the final version to support Azure Linux 2.0. We strongly recommend reviewing your scenarios and using this transition period to ensure a smooth migration.

For AKS customers,

Noting that Azure Linux team are still supporting Azure Linux 2.0 until November 2025 to align with AKS v1.31 support. This means Azure Linux 2.0 is getting regular patches until November 2025.

If you encounter any issues related to Azure CLI on Azure Linux 3.0, please open an issue in our GitHub repo.

Azure CLI and Azure PowerShell Build 2025 Announcement

Alex-wdy — Thu, 22 May 2025 12:22:22 GMT

The key investment areas for Azure CLI and Azure PowerShell in 2025 are quality and security. We’ve also made meaningful efforts to improve the overall user experience. In parallel, we've enhanced the quality and performance of Azure CLI and Azure PowerShell responses in Copilot, ensuring a more reliable user experience. We encourage you to try out the improved Azure CLI and Azure PowerShell in the Copilot experience and see how it can help streamline your Azure workflows.

At Microsoft Build 2025, we're excited to announce several new capabilities aligned with these priorities:

Improvements in quality and security.
Enhancements to user experience.
Ongoing improvements to Copilot's response quality and performance.

Improvements in quality and security

Azure CLI and Azure PowerShell Long Term Support (LTS) releases support

In November 2024, Azure PowerShell became the first to introduce both Standard Term Support (STS) and Long-Term Support (LTS) versions, providing users with more flexibility in managing their tools. At Microsoft Build 2025, we are excited to announce that Azure CLI now also supports both STS and LTS release models. This allows users to choose the version that best fits their project needs, whether they prefer the stability of LTS releases or want to stay up to date with the latest features in STS releases. Users can continue using an LTS version until the next LTS becomes available or choose to upgrade more frequently with STS versions.

To learn more about the definitions and support timelines for Azure CLI and Azure PowerShell STS and LTS versions, please refer to the following documentation:

Users can choose between the Long-Term Support (LTS) and Short-Term Support (STS) versions of Azure CLI based on their specific needs. It is important to understand the trade-offs:

LTS versions provide a stable and predictable environment with a support cycle of up to 12 months, making them ideal for scenarios where stability and minimal maintenance are priorities.
STS versions, on the other hand, offer access to the latest features and more frequent bug fixes. However, this comes with the potential need for more frequent script updates as changes are introduced with each release.

It is also worth noting that platforms such as Azure DevOps and GitHub Actions typically default to using newer CLI versions. That said, users still have the option to pin to a specific version if greater consistency is required in their CI/CD pipelines.

When using Azure CLI to deploy services like Azure Functions within CI/CD workflows, the actual CLI version in use will depend on the version selected by the pipeline environment (e.g., GitHub Actions or Azure DevOps), and it is recommended to verify or explicitly set the version to align with your deployment requirements.

SecureString update for Azure PowerShell

Our team is gradually transitioning to using SecureString for tokens, account keys, and secrets, replacing the traditional string types. In November 2024, we offered an opt-in method for the Get-AzAccessToken cmdlet. At the 2025 Build event, we’ve made this option mandatory, which is a breaking change:

Get-AzAccessToken

Get-AzAccessToken Token : System.Security.SecureString ExpiresOn : 5/13/2025 1:09:15 AM +00:00 TenantId : 00000000-0000-0000-0000-000000000000 UserId : user@mail.com Type : Bearer

In 2026, we plan to implement this secure method in more commands, converting all keys, tokens, and similar data from string types to SecureString. Please continue to pay attention to our upcoming breaking changes documentation.

Install Azure PowerShell from Microsoft Artifact Registry (MAR)

Installing Azure PowerShell from Microsoft Artifact Registry (MAR) brings several key advantages for enterprise users, particularly in terms of security, performance, and simplified artifact management.

Stronger Security and Supply Chain Integrity
Microsoft Artifact Registry (MAR) enhances security by ensuring only Microsoft can publish official packages, eliminating risks like name squatting. It also improves software supply chain integrity by offering greater transparency and control over artifact provenance.

Faster and More Reliable Delivery
By caching Az modules in your own ACR instances with MAR as an upstream source, customers benefit from faster downloads and higher reliability, especially within the Azure network.

You can try installing Azure PowerShell from MAR using the following PowerShell command:

$acrUrl = 'https://mcr.microsoft.com' Register-PSResourceRepository -Name MAR -Uri $acrUrl -ApiVersion ContainerRegistry Install-PSResource -Name Az -Repository MAR

For detailed installation instructions and prerequisites, refer to the official documentation:

Optimize the installation of Azure PowerShell | Microsoft Learn

Enhancements to user experience

Azure PowerShell Enhancements at Microsoft Build 2025

As part of the Microsoft Build 2025 announcements, Azure PowerShell has introduced several significant improvements to enhance usability, automation flexibility, and overall user experience.

Real-Time Progress Bar for Long-Running Operations
Cmdlets that perform long-running operations now display a real-time progress bar, offering users clear visual feedback during execution.

Smarter Output Formatting Based on Result Count
Output formatting is now dynamically adjusted based on the number of results returned:

A detailed list view is shown when a single result is returned, helping users quickly understand the full details.
A table view is presented when multiple results are returned, providing a concise summary that's easier to scan.

JSON-Based Resource Creation for Improved Automation
Azure PowerShell now supports creating resources using raw JSON input, making it easier to integrate with infrastructure-as-code (IaC) pipelines. When this feature is enabled (by default in Azure environments), applicable cmdlets accept:

JSON strings directly via *ViaJsonString
External JSON files via *ViaJsonFilePath

This capability streamlines scripting and automation, especially for users managing complex configurations.

We're always looking for feedback, so try the new features and let us know what you think.

Improved for custom and disconnected clouds: Azure CLI now reads extended ARM metadata

In disconnected environments like national clouds, air-gapped setups, or Azure Stack, customers often define their own cloud configurations, including custom dataplane endpoints. However, older versions of Azure CLI and its extensions relied heavily on hardcoded endpoint values based only on the cloud name, limiting functionality in these isolated environments.

To address this, Azure CLI now supports reading richer cloud metadata from Azure Resource Manager (ARM) using API version 2022-09-01. This metadata includes extended data plane endpoints, such as those for Arc-enabled services and private registries previously unavailable in older API versions.

When running az cloud register with the --endpoint-resource-manager flag, Azure CLI automatically parses and loads these custom endpoints into its runtime context. All extensions, like connectedk8s, k8s-configuration, and others, can now dynamically use accurate, environment-specific endpoints without needing hardcoded logic.

Key Benefits:

Improved Support for Custom Clouds: Enables more reliable automation and compatibility with Azure Local.
Increased Security and Maintainability: Removes the need for manually hardcoding endpoints.
Unified Extension Behavior: Ensures consistent behavior across CLI and its extensions using centrally managed metadata.

Try it out:

az cloud register -n myCloud --endpoint-resource-manager https://management.azure.com/

Check cloud

az cloud show -n myCloud

For the original implementation, please refer to https://github.com/Azure/azure-cli/pull/30682.

Azure PowerShell WAM authentication update

Since Azure PowerShell 12.0.0, Azure PowerShell supports Web Authentication Manager (WAM) as the default authentication mechanism. Using Web Account Manager (WAM) for authentication in Azure enhances security through its built-in identity broker and default system browser integration. It also delivers a faster and more seamless sign-in experience. All major blockers have been resolved, and we are actively working on the pending issues.

For detailed announcements on specific issues, please refer to the WAM issues and Workarounds issue.

We encourage users to enable WAM functionality using the command:

Update-AzConfig -EnableLoginByWam $true.

under Windows operating systems to ensure security. If you encounter issues, please report them in Issues · Azure/azure-powershell.

Improve Copilot's response quality and performance

Azure CLI/PS enhancement with Copilot in Azure

In the first half of 2025, we improved the knowledge of Azure CLI and Azure PowerShell commands for Azure Copilot end-to-end scenarios based on best practices to answer questions related to commands and scripts.

In the past six months, we have optimized the following scenarios:

Introduced Azure concept documents to RAG to provide more accurate and comprehensive answers.
Improved the accuracy and relevance of knowledge retrieval query and chunking strategies
Support more accurate rejection of the out-of-scope questions.

AI Shell brings AI to the command line, enabling natural conversations with language models and customizable workflows. AI Shell is in public preview and allows you to access Copilot in Azure. All the optimizations apply to AI Shell. For more information about AI Shell releases, see: AI Shell

To learn more about Microsoft Copilot for Azure and how it can help you, visit: Microsoft Copilot for Azure

Breaking Changes 

You can find the latest breaking change guidance documents at the links below. To learn more about the breaking changes, ensure your environment is ready to install the newest version of Azure CLI and Azure PowerShell, see the release notes and migration guides.

Azure CLI: Release notes & updates – Azure CLI | Microsoft Learn

Azure PowerShell: Migration guide for Az 14.0.0 | Microsoft Learn

Milestone timelines:

Azure CLI Milestones

Azure PowerShell Milestones

Thank you for using the Azure command-line tools. We look forward to continuing to improve your experience. We hope you enjoy Microsoft Build and all the great work released this week. We'd love to hear your feedback, so feel free to reach out anytime.  

GitHub:

o https://github.com/Azure/azure-cli

o https://github.com/Azure/azure-powershell

Let's stay in touch on X (Twitter) : @azureposh   @AzureCli

Announcing Public Preview of Terraform Export from the Azure Portal

stevenjma — Thu, 01 May 2025 16:30:08 GMT

Scenario

Imagine you have an existing networking configuration you would like to bring to Terraform. Whether you’re interested in learning Terraform or an expert, understanding how Azure resources are reflected in the azurerm and azapi providers is critical to your team. With Terraform export, you can quickly see how your resources are represented in either provider, whether it’s one resource from the configuration or the entire resource group.

Benefits

Azure Export for Terraform is a tool designed to provide a seamless and efficient way to generate Terraform configuration files that accurately represent your Azure resources. With the new Portal experience, you can easily understand your infrastructure’s representation in either the AzureRM or AzAPI providers within Terraform.

Usage

Prerequisite

Subscriptions will need to register the Microsoft.AzureTerraform resource provider.

Portal Usage

Find the experience in the Automation tab under the “Export template” blade. This experience is supported for individual resources as well as resource groups.

Next Steps

We invite you to try out the Azure Portal Export for Terraform feature and share your feedback with us via the Feedback button. Your input is valuable as we continue to improve and expand our offerings to better meet your needs.

For scripting or exporting many resource groups or resource types, we encourage you to check out the Azure Export for Terraform tool, which comes with customization features.

If you wish to utilize the underlying APIs directly or via CLI/PS, visit the new Azure Terraform resource provider documentation.

As always, thank you for being a part of our Azure Terraform community and for your continued support.

An Update on Bicep Azure Verified Modules for Platform Landing Zone (ALZ)

jtracey93msft — Thu, 24 Apr 2025 22:40:39 GMT

But first some history and context

As you may of heard in one of our Azure Landing Zone (ALZ) community calls over the past year, across ALZ we have been working hard to refactor both our Terraform and Bicep implementation options to be built upon Azure Verified Modules (AVM).

Earlier this year we announced that the work for Terraform, which we started on first, was complete; and you can read more about that in the announcement blog post we posted here.

But whilst this work was going on the ALZ Bicep team where already busy planning how they would go about doing the same and rebuilding ALZ Bicep from AVM modules. You can see the original plans and where we also asked for feedback in the GitHub issue (#791) .

Enough history, what's the latest?

Now to answer the question everyone has and rightly so 😁 Well, it's good news!

We have been busy working away on getting a number of the AVM Bicep Resource Modules updated with missing bits and pieces that we need from an ALZ perspective. All fairly minor in most cases but some required some bigger updates than others, and some modules didn't exist at all so we have had to propose, create, and publish those of which we are pretty much done with 👍

We are still working towards an end of Q4 (June/July) target for a preview release of all the modules, accelerator and guidance on how to use the new version of ALZ Bicep, which will be called "Bicep Azure Verified Modules for Platform Landing Zone (ALZ)"; this is to align with Terraform and also to provide clear distinction between ALZ Bicep and the new AVM based version.

Please note that the timeline shared above is an ETA and may move

Announcing the preview release of `avm/ptn/alz/empty` AVM Pattern Module

Before we get to a more complete release of all the required resources and modules to build the entire ALZ architecture with the new Bicep Azure Verified Modules for Platform Landing Zone (ALZ), we wanted to share an early look at the module that will be at the heart of all of your ALZ deployments.

That module is called `avm/ptn/alz/empty` and is available in the Public Bicep Registry for you to try out today (currently version `0.1.0`)!

Tip: Checkout the "max" test in the tests directory for advanced usage examples!

module testMg 'br/public:avm/ptn/alz/empty:0.1.0' = { params: { managementGroupName: 'test-mg' // Other parameters here... } }

This module is 1 of 11 modules that will all be based off the same code. The module optionally creates all of the below:

The Management Group itself
- Can also target an existing Management Group
Management Group Subscription Associations
RBAC Custom Role Definitions
RBAC Role Assignments
Policy Assignments
Custom Policy Definitions
Custom Policy Set Definitions (Initiatives)

There will also be 1 x Bicep Azure Verified Modules for Platform Landing Zone (ALZ) pattern module for each of the ALZ Architectures Management Groups, plus this empty one for custom and advanced scenarios. A reminder of those Management Groups and the associated modules that will be created for each of them:

`avm/ptn/alz/int-root`
`avm/ptn/alz/platform`
`avm/ptn/alz/platform-management`
`avm/ptn/alz/platform-identity`
`avm/ptn/alz/platform-connectivity`
`avm/ptn/alz/landing-zones`
`avm/ptn/alz/landing-zones-corp`
`avm/ptn/alz/landing-zones-online`
`avm/ptn/alz/decommissioned`
`avm/ptn/alz/sandbox`

These Management Group aligned pattern modules will create the same resources as above, but will have the latest release of the ALZ Library baked in to each of the modules. Meaning that for the `avm/ptn/alz/int-root` pattern module, you won't have to declare all of the ALZ RBAC Custom Role Definitions, Custom Policy Definitions, Policy Assignments etc. via the input parameters as they'll be hardcoded in the module based off the latest release from the ALZ Library at the point the version of the module was released.

This means that to build the ALZ Management Group hierarchy and make all of the default ALZ policy assignments, as documented here, you'd need a bicep file that would look something like this as a starting point:

Important: None of these modules exist below today!

module intRootMg 'br/public:avm/ptn/alz/int-root:0.1.0' = { params: { managementGroupName: 'int-root-mg' } } module platformMg 'br/public:avm/ptn/alz/platform:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: intRootMg.outputs.managementGroupId } } module platformConnectivityMg 'br/public:avm/ptn/alz/platform-connectivity:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: platformMg.outputs.managementGroupId } }

This will make getting the ALZ Architecture out of the box really fast, and also really easy to upgrade and get the latest updates, by just bumping the version number as you desire when you are ready.

Coupled with the `avm/ptn/alz/empty` module to add your own additional Policy Definitions and assignments, etc. at the same Management Groups scopes also helps you decouple the constant updates to the ALZ architecture and policies etc. from your own additional requirements.

Helping you keep your code cleaner and our modules simple to maintain as we won't have to cater for handling additional custom definitions and assignments alongside the defaults from ALZ that are baked into the modules.

Note: We are looking at suggesting that all of these are deployed via Deployment Stacks to help with lifecycle management of resources. e.g. help clean-up resources as well as deploy new ones; think policy assignments and definitions etc.

We need to complete a lot more testing on this, but would love your feedback on experiences if you have any using Deployment Stacks to manage these kind of resources today. Open an issue/discussion on the ALZ Bicep GitHub repo 👍

Our asks to you 🫵

Please go try out and test the new `avm/ptn/alz/empty` module and test it out for all the scenarios you can think of relating to Management Groups, RBAC, Policies etc. we want to make sure it's "match fit/ready" before we then build the Management Group aligned modules and bake in the ALZ defaults to them.

So please go and put the module through its paces and test it out.

Tip: Checkout the "max" test in the tests directory for advanced usage examples!

If you find any issues, bugs, feature requests or just have a question on how to use it, please just raise them as GitHub issues here (make sure to select the `avm/ptn/alz/empty` module from the drop down 👍)

Thanks in advance for all your efforts and assistance and we look forward to hearing and getting your feedback on the module 👏

Azure CLI Breaking Change Pre-Announcement

ychenu — Tue, 15 Apr 2025 05:55:33 GMT

Background

In our continuous effort to improve the quality and timeliness of our documentation, we have embarked on an initiative to automate the production of Upcoming Breaking Change Documentation. This initiative aims to alleviate the workload and pressure typically experienced before major events such as Microsoft Build and Microsoft Ignite. By leveraging automated methods, we can ensure that our documentation is both comprehensive and promptly available to our users.

Streamlining the Process

To further streamline this process, we are introducing a new workflow designed to encourage Service Teams to notify us of any future breaking changes several sprints ahead. The new workflow includes a new framework to pre-announce breaking changes, which will enable us to publish detailed and accurate Upcoming Breaking Change Documentation well ahead of time, providing our users with the information they need to prepare for these changes.

Breaking Change Rule

Core CLI

A breaking change in Azure CLI refers to a modification that disrupts backward compatibility with previous versions, potentially causing scripts or automation written in earlier versions to fail. Common examples include modifying parameter names, input logic, result output format, behavior models, and adding additional verifications.

To mitigate the impact, Azure CLI coordinates half-yearly Breaking Change Releases, bundling multiple breaking changes together. This approach helps users plan ahead and adapt effectively.

Breaking Change Window

The breaking change window is a designated sprint for merging service command breaking changes, aligning with Microsoft Build in May and Microsoft Ignite in November. Outside this window, breaking changes are typically prohibited to ensure consistency and stability. Exceptions require high-grade justifications and are assessed based on overall impact.

30-Day Pre-announcement Policy

All breaking changes must be pre-announced 30 days (usually 2 sprints) before the release. This provides users with buffer time to adapt. Notifications are made through:

Warning Log: Mandatory pre-announcement while executing.
Upcoming Breaking Change Document: Automatic collection and listing of changes.

Extensions

All breaking changes in GA (General Available) extensions must be pre-announced at least 30 days prior to their release. While extensions do not need to follow the breaking change window, it is strongly recommended to align their releases with the Core Azure CLI breaking change window.

GA (General Available) Release with Breaking Change Pre-Announcement

Must include complete breaking change information.
Must fulfill the 30-day announcement requirement.

During the 30-day announcement period, releases are allowed for unrelated GA (General Available) versions and multiple preview releases (Beta versions).

By adhering to these guidelines, users can ensure a smoother transition and maintain compatibility with their existing scripts and automation.

How to Announce a Breaking Change

It is simple to announce a Breaking Change using the new framework.

Find the entry:

Find or add an entry to the _breaking_change.py file in the top-level directory of the relevant module.

Register Breaking Changes:

You can then pre-announce breaking changes for different command groups or commands. Multiple breaking changes on the same command are accepted.

from azure.cli.core.breaking_change import register_required_flag_breaking_change, register_default_value_breaking_change, register_other_breaking_change register_required_flag_breaking_change('bar foo', '--name') register_default_value_breaking_change('bar foo baz', '--foobar', 'A', 'B', target_version='May 2025') register_other_breaking_change('bar foo baz', 'During May 2024, another Breaking Change would happen in Build Event.')

Try the Warning

All related breaking changes will be displayed when executing the command. For instance, with the above declarations, the following warnings will be output when executing the command:

# The azure command az bar foo baz # =====Warning output===== # The argument '--name' will become required in next breaking change release (2.61.0). # The default value of '--foobar' will be changed to 'B' from 'A' in May 2025. # During May 2024, another Breaking Change would happen in Build Event.

Types of Breaking Changes

There are several types of breaking changes defined in `_breaking_change.py`. You should use any of them to declare breaking changes:

Remove
Rename
Output Change
Change
Default Change
Be Required
Other Changes
Conditional Breaking Change

Work with Breaking Change Detect

To normalize the release of breaking changes, Azure CLI has integrated a Breaking Change Detection tool into the Pull Request Pipeline. This tool will reject any breaking changes that are submitted outside of the designated breaking change window and will provide guidelines for following the breaking change policies.

Technical Implementation

The Breaking Change Pre-Announcement uses a hook in the Azure CLI. This hook is used to collect announcements registered in _breaking_change.py files and transform them into tags that can be consumed by the Knack framework, which is the foundational framework used by the Azure CLI. When multiple tags are registered under the same identifier, they are consolidated into a single MergedTag. This MergedTag is then used to manage complex scenarios effectively.

Conditional breaking changes are not transformed into tags. Instead, they are stored in the breaking changes registry. These changes can be accessed manually by calling the print_conditional_breaking_change function.

Future Plan

Detect out of date announcement
Detect related announcements in PR of breaking changes

Resilience Testing with Azure Chaos Studio: Compute Failures

prasha01 — Wed, 19 Mar 2025 23:12:21 GMT

Introduction

Chaos Studio is an Azure service that helps you measure, understand, and build application and service resilience to real-world incidents, such as an unexpected infrastructure disruption or an application failure causing 100% CPU usage on a VM. In this new series of blog posts, we’ll share best practices on performing resilience tests for common failure scenarios, provide step-by-step tutorials, and discuss how to leverage test results to improve the resilience of your cloud applications. Today, we’ll focus on using Chaos Studio to simulate a compute failure.

Resilience Testing Best Practices

We recommend using a hypothesis-driven approach for resilience testing to ensure actionable results:

Define a hypothesis: outline a specific failure scenario and predict how your infrastructure will perform if it occurs.
Design a fault injection experiment that reflects the failure scenario you wish to test and set up proper telemetry to monitor performance over the course of the experiment.
Run your experiment and analyze results to determine if your hypothesis was validated or invalidated.
Make necessary improvements to your configurations based on your findings.

As your cloud infrastructure changes and evolves, new dependency and configuration issues may arise – repeat this process over time to ensure continued reliability.

Simulate a Compute Failure Scenario

Today, we’ll be performing an Availability Zone shutdown on a Virtual Machine Scale Set configured with instances across multiple Availability Zones. Remember to define a hypothesis before conducting your resilience test, for example: “If one Availability Zone is shut down, the Virtual Machine Scale Set’s autoscale configuration will detect the drop in instance count and automatically provision additional instances in the remaining zones, maintaining overall capacity and performance.” Next, we’ll create and run a fault injection experiment to test our scenario using Chaos Studio.

Prerequisites

A valid Azure subscription. If you don’t have one, you can create a free account.

A Virtual Machine Scale Set configured with instances across multiple availability zones. Ensure that it is located in a region supported by Azure Chaos Studio (Resource Targeting). If you don’t have one, you can follow the instructions to create one.

If this is your first time using Chaos Studio, follow the instructions below to register the resource provider for your subscription

Open the Azure portal.
Search for and select Subscriptions. Select the subscription you’d like to use.
Select Settings > Resource providers from the left-side menu.
Search for and select Microsoft.Chaos. Select Register.

Create an Experiment and Set Up Monitoring

To create an Availability Zone shutdown experiment on your Virtual Machine Scale set, do the following:

Open the Azure portal. Search for and select Chaos Studio.
Select Targets from the left-side menu.
Select the Virtual Machine Scale Set you’d like to test and select Enable targets > Enable service-direct targets (All resources) > Review + Enable > Enable.
Navigate back to Chaos Studio and select Experiments from the left-side menu.
Select Create > New experiment.
On the Basics tab, select a subscription and resource group for your experiment. Give your experiment a name and select the region you’d like to store it in.
On the Permissions tab, select whether you’d like to use a System or User-assigned managed identity to manage your experiment permissions. If you’re unsure of which to choose, select the system-assigned identity option. Check the Enable custom role creation and assignment checkbox – this will allow Chaos Studio to automatically assign the necessary permissions to your managed identity based on your experiment configuration.
On the Experiment designer tab, select Add action > Add fault. Choose the VMSS Shutdown (version 2.0) fault from the dropdown. Select Next: Target resources and select your Virtual Machine Scale Set. Select Next: Scope, choose the zone you’d like to shut down, and select Add.
Select the Review + create button, review the experiment configuration, and select Create.

The metrics you should monitor for your experiment run depend on the hypothesis you came up with for your scenario. Since our sample hypothesis predicted that our Virtual Machine Scale Set would provision additional instances in the event of a disruption based on its autoscale setting, we’ll show you how to track the availability of your Virtual Machine Scale Set’s virtual machine instances:

Search for your Virtual Machine Scale Set by name using the Azure portal search bar and select it to go to its overview page.
Select Monitoring > Metrics from the left-side menu.
Configure a metric with the following values:
- Scope: your Virtual Machine Scale Set
- Metric Namespace: Virtual Machine Host
- Metric: VM Availability Metric (Preview)
- Aggregation: Avg
Select Add metric.
You may select Save to dashboard and choose the Pin to dashboard, Pin to Grafana, or Send to workbook options to save your metric where you’d like.

The VM Availability Metric will now display an average of the availability of your virtual machine instances within your Virtual Machine Scale Set over the course of your experiment run.

Run the Experiment and Analyze Results

To run your experiment, do the following:

Within the Azure portal, navigate back to Chaos Studio and select Experiments from the left-side menu.
Select your experiment and select Start experiment(s) > Yes from the bar at the top of the page.
Select your experiment’s name to navigate to its overview page. Select the Details button under History to monitor its progress while running.

While your experiment is running, navigate to your Virtual Machine Scale Set > Monitoring > Metrics, or the location where you saved your VM Availability Metric, and view the impact of the Availability Zone shutdown on your Virtual Machine Scale Set’s average instance availability:

Recommendations to Improve Resiliency

Did your Virtual Machine Scale Set perform as you expected it to during the Availability Zone shutdown? If not, here are some steps you can take to improve your resiliency for future tests and protect against real-world incidents:

Configure or review the autoscale settings on your Virtual Machine Scale Set to ensure rapid provisioning of additional instances in unaffected zones during a failure.

Maintain a balanced instance count across Availability Zones to minimize the impact of losing an entire zone.

Set up load balancing or adjust configurations to seamlessly redistribute traffic when a zone becomes unavailable.

After making improvements to your Virtual Machine Scale Set configuration, be sure to test and iterate on them by continuing to perform resilience testing regularly.

Conclusion

In this blog post, we have shown you how to use Chaos Studio to test your Virtual Machine Scale Sets against Availability Zone shutdowns. With the best practices laid out in this guide, you can conduct resilience tests on services across your cloud infrastructure using faults in Chaos Studio’s fault library. Be sure to look out for more blog posts covering other scenarios in the “Resilience Testing with Azure Chaos Studio” series soon. Feel free to add a comment below on which scenarios you’d like to see next. Happy resilience testing!

Additional resources

Chaos Studio Overview: http://aka.ms/AzureChaosStudio

Documentation: Azure Chaos Studio documentation - tutorials, API reference

MS Build Session Recording: https://www.youtube.com/watch?v=lk1yxLMj-7A

Advancing Microsoft Azure resilience with Chaos Studio | Microsoft Azure Blog

Regional availability of Azure Chaos Studio | Microsoft Learn

Upcoming Breaking Change in Az SSH for Arc Connections Extension

stevenbucher — Thu, 27 Feb 2025 21:49:16 GMT

The Az SSH extension is a vital tool for developers and IT professionals who use Azure DevOps. It allows users to securely connect to Azure virtual machines (VMs) using SSH (Secure Shell) and Entra ID, making remote management and deployment tasks more streamlined and efficient. The extension is widely used for its ease of integration with various Azure services and its ability to simplify the process of establishing secure connections.

The Upcoming Breaking Change

This breaking change affects all customers who use Az SSH extension for connecting to Azure Arc Machines. By May 21^st, all versions of the Az SSH extension prior to 2.0.4 will become unusable upon installation for connecting to Arc resources. This breaking change is due to deprecation of a storage blob used during installation.

Versions of the Az SSH extension prior to 2.0.4 will still be functional, but if there is corruption of the extension files, you will not be able to reinstall the extension. To check what version of the extension you have installed, run this command

az extension list --output table

This change does not impact versions beginning with 2.0.4.

Action Items

To minimize the potential breaking of the Az SSH extension for connecting to Arc machines, we encourage you to take the following steps:

Update the Az SSH Extension: Ensure that you update the Az SSH extension to the latest version (2.0.6). This can be done using the Azure CLI extension update command:

az extension update --name ssh

Review and Update Scripts: If you have scripts or automated processes that install a pinned version of Az SSH extension prior to 2.0.4, make necessary adjustments to install a later version.
Stay Informed: Keep an eye on official documentation and blogs for additional updates or guidance related to the Az SSH extension. Staying informed will help you stay ahead of any future changes.

The breaking change in the Az SSH extension is a critical security update. Follow the steps above for a smooth transition and secure management of Azure Arc Machines. Stay proactive, informed, and keep your tools updated to maintain security and efficiency.

Thanks!

Steven Bucher

Product Manager for SSH CLI Extension

Announcing General Availability of Terraform Azure Verified Modules for Platform Landing Zone (ALZ)

jaredfholgate — Wed, 22 Jan 2025 09:10:30 GMT

Azure Verified Modules

ALZ ❤️ AVM. We are moving to a more modular approach to deploying your platform landing zones. In line with consistent feedback from you, we have now released a set of modules that together will deploy your platform landing zone architecture (ALZ).

Azure Verified Modules for Platform Landing Zones (ALZ) is collection of Azure Verified Modules that are composed together to create your Platform Landing Zone. This replaces the existing CAF Enterprise Scale module that you may already be familiar with.

The core Azure Verified Modules that are composed together are:

Management Groups and Policy Pattern Module: avm-ptn-alz
Management Resources Pattern Module: avm-ptn-management-alz
Hub Virtual Networking Pattern Module: avm-ptn-hubnetworking
Virtual Network Gateway Pattern Module: avm-ptn-vnetgateway
Virtual WAN Networking Pattern Module: avm-ptn-virtualwan
Private DNS Zone for Private Link Pattern Module: avm-ptn-network-private-link-private-dns-zones

This means that you can now choose your own adventure by selecting only the modules that you need. It also means we can add new features faster and allows us the opportunity to do more rigorous testing of each module.

To improve deployment reliability, we now use our own Terraform provider. The provider generates data for use by the module and does not directly deploy any resources. The move to a provider allows us to add many more features and checks to improve your deployment reliability.

ALZ IaC Accelerator updates for Terraform

The Azure Landing Zones IaC Accelerator is our recommended approach for deploying the Terraform Azure Verified Modules for Platform Landing Zone (ALZ).

The Azure Verified Modules for Platform Landing Zone is now our default selection for the Terraform ALZ IaC Accelerator. This module will be the focus of our development and improvement efforts moving forward.

The module implements best practices by default, including multi-region and availability zones for resiliency. The ALZ IaC Accelerator bootstrap continues to implement best practices, such as version control and Workload identity federation security.

Along with supporting the Azure Verified Modules for Platform Landing Zone (ALZ) approach, we have also made many enhancements to the ALZ IaC Accelerator process. A summary of the improvements include:

We now support HCL (HashiCorp Configuration language) tfvars file as the platform landing zone configuration file format
We have introduced a Phase 0 to help you plan for your ALZ IaC Accelerator deployment
We have introduced the concepts of Scenarios and Options to simplify the decisions you need to make

Platform landing zone configuration file

Before the introduction of the Azure Verified Modules for Platform Landing Zone (ALZ) starter module the platform landing zone configuration file was supplied in YAML format. Due to the lack of support for YAML in Terraform, we had to then convert this to JSON. Once converted to JSON the configuration file lost all it's ordering, formatting and comments. This made day 2 updates to the configuration very cumbersome.

With the support for the tfvars file (in HashiCorp Configuration Language format), we are now able to pass the configuration file in its original format to the version control system repository. This makes for a much easier day 2 update process as the file retains it's ordering, comments and formatting as defined by you.

Phase 0

Phase 0 is a new planning phase we have added to the documentation. This phase takes you through 3 sets of decisions you need to make about the ALZ IaC Accelerator deployment:

In order to assist with this, we also provide a downloadable Excel checklist , which lists all the decisions so you can consider them up front prior to completing any configuration file updates.

Phase 0 guides you through this process and provides explanations of the decisions.

The Bootstrap decisions relate to the resources deployed to Azure and the configuration of your Version Control System required for the Continuous Delivery pipeline. These decisions are not new to the ALZ IaC Accelerator, but we now provide more structured guidance.

Platform Landing Zone Scenarios

The Scenarios are a new concept introduced for the Azure Verified Modules for Platform Landing Zone (ALZ) starter module. We aim to cover the most common Platform landing zone use cases we hear requested from partners and customers with the ALZ IaC Accelerator. These include:

Multi-Region Hub and Spoke Virtual Network with Azure Firewall
Multi-Region Virtual WAN with Azure Firewall
Multi-Region Hub and Spoke Virtual Network with Network Virtual Appliance (NVA)
Multi-Region Virtual WAN with Network Virtual Appliance (NVA)
Management Groups, Policy and Management Resources Only
Single-Region Hub and Spoke Virtual Network with Azure Firewall
Single-Region Virtual WAN with Azure Firewall

For each scenario we provide an example Platform landing zone configuration file that is ready to deploy immediately. We know that customers will want to modify some of the settings and that is where Options come in.

NOTE: At the time this blog post was published, we support the 7 Scenarios listed above. We may update or add to these Scenarios based on feedback we hear from you, so keep an eye on our documentation.

Platform Landing Zone Options

The Options build on the Scenarios. For each Scenario, you can choose to customise it with one or more Options. Each Options includes detailed instructions of how to update the Platform landing zone configuration file or introduce library files to implement to the option.

The Options are:

Customise Resource Names
Customize Management Group Names and IDs
Turn off DDOS protection plan
Turn off Bastion host
Turn off Private DNS zones and Private DNS resolver
Turn off Virtual Network Gateways
Additional Regions
IP Address Ranges
Change a policy assignment enforcement mode
Remove a policy assignment
Turn off Azure Monitoring Agent
Deploy Azure Monitoring Baseline Alerts (AMBA)
Turn off Defender Plans
Implement Zero Trust Networking

NOTE: At the time this blog post was published, we support the 14 Options listed above. We may update or add to these Options based on feedback we hear from you, so keep an eye on our documentation.

Azure Landing Zones Library

Another new offering is the Azure Landing Zones Library. This is an evolution of the library concept in the caf-enterprise-scale module.

Principally, the Library allows us to decouple the update cycle of the ALZ architecture, from the module and provider. We are separating the data from the deployment logic. This allows you to update the module to take advantage of a bug fix, without having to change the policies that are deployed. Something that wasn't easily possible before. Conversely, you are able to update to the latest policy refresh of Azure Landing Zones without updating the module itself.

The Library has its own documentation site, which introduces the concepts. We plan to make the library the single source of truth for all Azure Landing Zones implementation options (e.g. Portal, Terraform and Bicep) in the future.

Azure Landing Zones Documentation Site

Furthermore, we have a new place to go for all technical documentation for Azure Verified Modules for Platform Landing Zones (ALZ). With the move to multiple modules, and the new accelerator all having multiple GitHub repositories, we felt the need to centralize the documentation to make it the one place to go to get technical details.

We currently have documentation for the Accelerator and Terraform, with Bicep coming soon.

The new vanity URL is: https://aka.ms/alz/tech-docs. Please let us know what you think!

What about ALZ-Bicep?

Finally, some of you may be wondering what the future for our Bicep implementation option (ALZ Bicep) for Azure Verified Modules for Platform Landing Zones (ALZ) may be with this evolution on the Terraform side. And we have good news to share!

Work is underway to also build the next version of ALZ in Bicep, which will be known as “Bicep Azure Verified Modules for Platform Landing Zone (ALZ)”. This will also use the new Azure Landing Zones Library and be built from Azure Verified Modules (where appropriate).

We are currently looking to complete this work before August 2025, if not a lot sooner than this; as we are making good progress as we speak!

But for now, for Bicep you do not do anything and continue to use ALZ Bicep via the ALZ IaC Accelerator and we will provide more updates on the next version of Bicep ALZ in the coming months!

Staying up-to-date

We highly recommend joining, or watching back, our quarterly Azure Landing Zones Community Calls, to get all the latest and greatest from the ALZ team.

Our next one is on the 29th January 2025 and you can find the link to sign up to attend or watch back previous ones at: aka.ms/ALZ/Community

We look forward to seeing you all there soon!

Azure CLI and Azure PowerShell Ignite 2024 Announcement

Alex-wdy — Wed, 20 Nov 2024 14:05:13 GMT

The priority for Azure CLI and Azure PowerShell remains to provide our customers with the most complete, secure, and easy-to-use tools to manage Azure resources.

At Microsoft Ignite 2024, we are announcing the following new capabilities delivering on our priorities:

Extending our coverage and commands API version upgrade.
Security improvements.
Investments in Copilot in Azure

Extending our coverage

In the past six months, we have added or refreshed coverage for new or existing Azure services within 30 days of their general availability.

You will see new and updated command lines for ArcGateway, AzTerraform, ConnectedMachine, Fabric, Astro, Synapse, AppComplianceAutomation, Storage, App, and other modules.

Note: To use the associated commands, you need to install the Azure CLI extension or the Azure PowerShell module.

For details about all the commands that have been updated, as well as a complete list of the new features in this release for the Azure client tools, see the release notes for each tool:

Azure CLI: https://learn.microsoft.com/cli/azure/release-notes-azure-cli 
Azure PowerShell:  https://learn.microsoft.com/powershell/azure/release-notes-azureps

Credential detection from Az CLIs outputs

We have been actively working on hardening your defense in depth with secrets awareness in Azure command line tools.

For Azure CLI and Azure PowerShell, in the past 6 months, we have collaborated with our internal team to replace verification patten with the Azure secret common library, expanding the coverage types of patches and the range of command lines. The range of command line detection has been almost 100% covered. The Azure CLI and Azure PowerShell use the same detection logic and are continually being upgraded.

We still encourage users to enable environment parameters:

AZURE_CLIENTS_SHOW_SECRETS_WARNING=True (Default)

For Azure PowerShell only

Our team is gradually transitioning to using SecureString for tokens, account keys, and secrets, replacing the traditional string types. Currently, we offer an opt-in method for the Get-AzAccessToken command line, which does not introduce breaking changes:

Get-AzAccessToken –AsSecureString

We encourage users to utilize the -AsSecureString parameter to output tokens securely. Over the next year, we plan to implement this security method across more command lines, converting all keys, tokens, and similar data from string types to SecureString. Please note that when the command line output defaults to -AsSecureString mode, it may result in breaking changes. Therefore, we advise users to stay updated with our breaking change documentation.

Support Azure Linux 3.0 for Azure CLI

Azure CLI has supported Azure Linux 3.0 from 2.65.0. The Azure Linux 3 user can install CLI with

tdnf install azure-cli

Starting from version 2.64.0 of Azure CLI, the base Linux distribution of Azure CLI is now Azure Linux 3.0.

It’s available at Microsoft Artifact Registry (MAR) https://mcr.microsoft.com/en-us/artifact/mar/azure-cli/about. You can get it with the below command：

docker pull mcr.microsoft.com/azure-cli

docker pull mcr.microsoft.com/azure-cli:azurelinux3.0

For further migration guidance especially involved with GitHub Actions, please check out more details from blog.

Deprecate SP with certificate with az login –password for Azure CLI

For az login,

--password will no longer accept service principal certificate in Azure CLI 2.67.0. Use `--certificate` to pass a service principal certificate.

# Logging in with secret should work as before az login --service-principal --username xxx --password mysecret --tenant xxx # Old way to log in with a certificate, will show a deprecation warning az login --service-principal --username xxx --password ~/mycert.pem --tenant xxx # New way to log in with a certificate az login --service-principal --username xxx --certificate ~/mycert.pem --tenant xxx

Note:

To sign in with a certificate, the certificate must be available locally as a PEM or DER file in ASCII format. PKCS#12 files (.p12/.pfx) don't work.

When you use a PEM file, the PRIVATE KEY and CERTIFICATE must be appended together within the file. You don't need to prefix the path with an `@` like you do with other az commands.

Azure PowerShell WAM Authentication Issues and Fixes

Since version Az 12.0.0, Azure PowerShell has supported Web Authentication Manager (WAM) as the default authentication mechanism. During this period, several critical issues affected users logging in interactively. These issues have been addressed and fixed by version 13.0.0, including:

The WAM login interface failing to pop up, resulting in login failures.
Login failures for users using the device-code authentication method.
The "Work and school account" option does not appear in the WAM pop-up window.
Incompatibility of the Export-AzSshConfig and Enter-AzVM commands from the Az.Ssh module when WAM is enabled.

For detailed announcements on specific issues, please refer to our WAM issues and Workarounds/azure-powershell issue.

In response to these WAM issues, our team has been actively fixing bugs, making improvements, and establishing monitoring and alert mechanisms with relevant teams to detect issues early and assess their impact. Additionally, we have integrated test cases baseline into the release pipeline.

We encourage users to enable the WAM function for security by using the command:

Update-AzConfig -EnableLoginByWam $true

If you encounter problems, please report them in Issues · Azure/azure-powershell

Note:

Sovereign Cloud does not currently support WAM, we plan to implement this in the coming months.

Change in Azure CLI extension management

Starting with Azure CLI version 2.56.0, a new `--allow-preview` parameter was introduced for the extension installations, with its default value set to True. This change, as outlined in our extension versioning guidelines, helps distinguish between stable and preview versions, ensuring consistency across stable releases while still enabling the publication of preview features.

Beginning with version 2.67.0, Azure CLI will now install only stable versions of extension modules by default. If a later preview version of an extension is available, users will receive a warning message that explains how to enable preview versions by using the `--allow-preview` parameter.

Important Note:

If no stable version of an extension is available, preview versions will be installed by default, along with a warning message, like below, notifying users of this behavior.
"No stable version of 'xxx' to install. Preview versions are allowed."

Azure PowerShell Long Term Support releases (LTS) support

Azure PowerShell already supports both Standard Term Support releases (STS) and Long-Term Support releases (LTS). Users can choose the appropriate version according to their project needs. Users can choose to stay with the LTS version until the next LTS version, or upgrade with the latest version to experience new features. The following document details the definitions of LTS and STS. Beginning with Az 12, even numbered releases are LTS versions.

Azure PowerShell support lifecycle: Azure PowerShell support lifecycle | Microsoft Learn

Azure CLI will provide LTS version in early 2025. More details could be found at Azure CLI lifecycle and support | Microsoft Learn

Enhancement to Invoke-AzRestMethod in Azure PowerShell

Azure PowerShell 13.0.0 introduces major enhancements to the Invoke-AzRestMethod cmdlet, empowering users with a new option to enable long-running operations (LRO) and flexible control over operation status polling in complex Azure workflows.

Key Features of Invoke-AzRestMethod Enhancement:

LRO Support with Enhanced Status Tracking: With the new -WaitForCompletion parameter, users can wait for the operations to complete and directly receive the final status. In debug mode, users can also monitor long-running operations (such as deployments or resource provisioning) and receive real-time status updates directly in their PowerShell session.
Flexible Polling Options for Customized Control: The addition of -PollFrom and -FinalResultFrom parameters enable users to define custom polling URIs and specify final result header sources, ensuring compatibility across various Azure resources and scenarios.

Example Usage:

Using the new -WaitForCompletion parameter, here’s how to create a Managed HSM (Hardware Security Module) and track its provisioning status until it’s fully completed:

Invoke-AzRestMethod -Method PUT -WaitForCompletion -Path "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.KeyVault/managedHSMs/{hsmName}"

This example monitors the creation of a Managed HSM, providing real-time updates throughout the longer provisioning process (in debug mode), ensuring the resource reaches a fully operational state.

For more details and examples, refer to the updated release notes: Azure PowerShell release notes 

Azure CLI/PS scenarios with Copilot in Azure

In the second half of 2024, we improved knowledge of Azure CLI commands and end-to-end scenarios for Copilot in Azure to answer questions related to Azure CLI commands or scripts, following our best practices.

In the past 6 months, we have optimized the following scenarios:

Enhanced Prompt Flow and RAG architecture tailored for CLI script generation, ensuring higher command and scenario accuracy.
Improved user intent recognition with hybrid search, enabling more precise retrieval of relevant knowledge from user queries.
Supported parameter value injection, simplifying the process for customers to input parameter values and generate directly usable scripts on Copilot in Azure.
Optimized the knowledge base to reduce hallucination issues.
More accurately identified out-of-scope questions.

In the 2024 Ignite Event, we’ve also released a public preview of AI Shell, which lets you access Copilot in Azure to help answer any questions you have about Azure CLI or Azure PowerShell. For more information about the AI Shell release please check out. AI Shell

To learn more about Microsoft Copilot for Azure and how it can help you, visit: Microsoft Copilot for Azure

Breaking Changes 

Azure CLI: Release notes & updates – Azure CLI | Microsoft Learn

Azure PowerShell: Migration guide for Az 13.0.0 | Microsoft Learn

Milestone timelines:

Azure CLI Milestones

Azure PowerShell Milestones

GitHub:
- https://github.com/Azure/azure-cli
- https://github.com/Azure/azure-powershell

Let's be in touch on X (Twitter) : @azureposh   @AzureCli

Azure CLI and Azure PowerShell team

Unlocking the Best of Azure with AzureRM and AzAPI Providers

stevenjma — Wed, 30 Oct 2024 20:01:51 GMT

With the recent release of AzAPI 2.0, Azure offers two powerful Terraform providers to meet your infrastructure needs: AzureRM and AzAPI. The key question is, when should you use each one? This article offers a clear guide for Terraform users, particularly those familiar with the AzureRM provider, on some ideal scenarios for each. The recommendations provided within this post are jointly provided between HashiCorp and Microsoft; click here for HashiCorp's blogpost.

Overview

At a high level, AzureRM provides a stable, well-tested layer on top of Azure APIs. It handles the entire resource lifecycle—creation, updates, and deletion—while managing breaking changes, and ensuring smooth operations. AzureRM is ideal for users looking for stability and simplified configuration management.

On the other hand, AzAPI is a lightweight wrapper around Azure APIs, enabling direct and early access to the latest Azure features. It allows for quicker adoption of new services or workarounds for AzureRM limitations, making it ideal for users who need cutting-edge functionality. Below, we’ll dive into the differences between the two providers and when to use each.

AzureRM: A Proven, Simplified Approach

AzureRM abstracts complexity by managing Azure API versions on your behalf. The provider ensures that resources are fully compatible with one another and that configuration changes don’t introduce breaking issues, thanks to its rigorous testing. If you’re using resources that don’t require constant updates or access to the latest API versions, AzureRM provides a more stable and simplified experience.

Key benefits of AzureRM:

Automatic API Versioning: AzureRM handles API version compatibility, making upgrades seamless.
Simplicity: Resource property names are intuitive (e.g., disk_size_in_gb vs. disk_size), reducing the need to consult Azure API documentation frequently.
Comprehensive Documentation: AzureRM offers extensive resources and examples for each service, making it easier to onboard and use in your projects.

AzureRM is ideal for scenarios where you prioritize stability, want to minimize complexity, and don’t need the very latest features.

AzAPI: Cutting-Edge Features and Access to Azure APIs

AzAPI, by contrast, provides a thinner layer, allowing for direct access to the latest Azure API versions as soon as they’re available. It’s well suited for scenarios where you need quick access to features before they are fully supported in AzureRM.

Key benefits of AzAPI:

Immediate API Access: AzAPI gives users access to the latest API versions forAzure resources, allowing teams to use new Azure services and features sooner.
Targeted Resource Updates: With the azapi_update_resource function, you can modify specific resource properties without upgrading the entire resource or provider.
Fine-Grained Control: AzAPI provides resource versioning to allow for more control over the infrastructure configuration. User defined retryable errors, HTTP headers, URL control and resource replacement definitions are a few other ways AzAPI provides granular control.

AzAPI is recommended for scenarios where early access to new Azure features is crucial, or when you need granular control over your infrastructure.

Documentation and Community Support

AzureRM has a more extensive collection of blog posts, community contributions, and official documentation. This makes it easier for new users to find examples and ramp up quickly.

AzAPI, while newer, follows Azure’s API structures more closely, making it easier for users familiar with Bicep or ARM templates to understand.

Conclusion: When to Use Each Provider

Choose AzureRM if you prioritize stability, simplicity, and automatic versioning. It’s best for teams that want to minimize the complexity of managing infrastructure and don’t need immediate access to new Azure features.

Choose AzAPI if you need cutting-edge access to the latest Azure APIs or need to customize resource configurations without waiting for AzureRM to be updated. It’s ideal for teams that require rapid innovation and fine-grained control over API versions.

Both providers provide a first-class experience, backed by Microsoft and HashiCorp, and can be adapted based on your needs. You can also transition between them seamlessly with tools like the upcoming Azure Terraform Migration tool release (aztfmigrate), making it easy to adjust your approach as your infrastructure evolves.

We hope this guide helps you determine when to use AzureRM or AzAPI, ensuring you get the most out of your Terraform and Azure infrastructure.

Announcing AzAPI 2.0

stevenjma — Mon, 21 Oct 2024 17:48:14 GMT

The AzAPI provider, designed to expedite the integration of new Azure services with HashiCorp Terraform, has now released 2.0. This updated version marks a significant step in our goal to provide launch day support for Azure services using Terraform.

What is the AzAPI Provider?

The AzAPI provider functions as a lightweight layer atop the Azure ARM REST APIs. It is a first class provider experience along with the AzureRM provider. Azure resources that might not yet be or may never be supported in AzureRM can be accessed by this provider, including private/public preview services and features.

Key Features of the AzAPI Provider Include:

Resource-specific versioning, allowing users to switch to a new API version without altering provider versions.
Special functions like `azapi_update_resource` and `azapi_resource_action`.
Immediate Day 0 support for new services.

Ready to see the new updates? Let’s take a look!

No More JSON!

All resource properties, outputs, and state representation are now handled with HashiCorp Configuration Language (HCL) instead of JSON. This change allows the use of all native Terraform HCL functionalities. For more info on scenarios on usage, check out our initial announcement.

Clarity with Outputs

Outputs are now customizable through the `response_export_values` property, which can function as either a list or a map.

For instance, to export response values for an Azure container registry:

If I set the value to a list, i.e. response_export_values = `["properties.loginServer", "properties.policies.quarantinePolicy.status"]` , I would get the following output:

{
    properties = {
        loginServer = "registry1.azurecr.io"
        policies = {
            quarantinePolicy = {
                status = "disabled"
            }
        }
    }
}

If I instead set the value to a map using JMESPath querying, i.e. response_export_values = `{"login_server": "properties.loginServer", "quarantine_status": "properties.policies.quarantinePolicy.status"}`, I would get the following output:

{
    "login_server" = "registry1.azurecr.io"
    "quarantine_status" = "disabled"
}

This feature uses a key-value configuration, making it easier to specify exact output values. For example, you can set `{"login_server": "properties.loginServer", "quarantine_status": "properties.policies.quarantinePolicy.status"}`.

retry Block

User-defined retriable errors via the retry block help the provider digest errors when expected. For example, if a resource may run into a create timeout issue, the following block of code may help:

resource "azapi_resource" "example" {
    # usual properties
    retry {
        interval_seconds     = 5
        randomization_factor = 0.5 # adds randomization to retry pattern
        multiplier           = 2 # if try fails, multiplies time between next try by this much
        error_message_regex  = ["ResourceNotFound"]
    }
    timeouts {
        create = "10m"
}

Preflight Support

Preflight validation, enabled by a feature flag, will identify errors without deploying resources, providing a quicker feedback loop. For example, in a config with several resources, an invalid network addressPrefix definition will be caught quickly:

provider "azapi" {
  enable_preflight = true
}
resource "azapi_resource" "vnet" {
  type      = "Microsoft.Network/virtualNetworks@2024-01-01"
  parent_id = azapi_resource.resourceGroup.id
  name      = "example-vnet"
  location  = "westus"
  body = {
    properties = {
      addressSpace = {
        addressPrefixes = [
          "10.0.0.0/160", # preflight will throw an error here
        ]
      }
    }
  }
}

Resource Replacement Triggers

Customize specific methods of replacing your resource.

replace_triggers_external_values: Replaces if specified external values change.
replace_triggers_refs: Triggers a resource replacement based on changes in specified paths.

Resource Discovery

Discover resources under a parent ID such as a subscription, virtual network, or resource group using the new `azapi_resource_list` data source. You can also filter using query parameters as shown below:

data "azapi_client_config" "current" {}

data "azapi_resource_list" "listPolicyDefinitionsBySubscription" {
  type      = "Microsoft.Authorization/policyDefinitions@2021-06-01"
  parent_id = "/subscriptions/${data.azapi_client_config.current.subscription_id}"
  query_parameters = {
    "$filter" = ["policyType eq 'BuiltIn'"]
  }
  response_export_values = ["*"]
}

output "o1" {
  value = data.azapi_resource_list.listPolicyDefinitionsBySubscription.output
}

AzAPI Provider Functions

AzAPI now supports several Terraform provider functions:

build_resource_id: Constructs an Azure resource ID.
parse_resource_id: Breaks down an Azure resource ID into its components.
subscription_resource_id: Constructs an Azure subscription scope resource ID.
tenant_resource_id: Builds an Azure tenant scope resource ID.
management_group_resource_id: Creates an Azure management group scope resource ID.
resource_group_resource_id: Forms an Azure resource group scope resource ID.
extension_resource_id: Generates an Azure extension resource ID with additional names.

To check out the references and examples, visit the Terraform registry.

AzAPI VSCode Extension Improvements

The release coincides with updates to the VSCode extension:

Code Samples: Quickly insert code samples from our auto-gen pipeline:

Paste as AzAPI: Convert JSON or ARM templates directly into HCL:

Conclusion

AzAPI 2.0 brings numerous enhancements, promising a better Terraform experience on Azure. With these features, we believe that you can use AzAPI as a standalone provider to meet any of your infrastructure needs. Stay tuned for a blogpost coming on suggestions for when to use each provider. Be sure to explore the new features; we're confident you’ll enjoy them!

If you haven’t yet, check out the provider: https://registry.terraform.io/providers/Azure/azapi/latest/docs

Azure CLI docker container base Linux image is now Azure Linux

JeremyLi — Fri, 06 Sep 2024 02:44:38 GMT

Starting from the version 2.64.0 of Azure CLI, the base Linux distribution of Azure CLI is now Azure Linux.

Impact of the change

az commands are unaffected.
shell commands specific to Alpine will not be functional (ex: apk).
The following GitHub action will use the new image and could impact scripts using Alpine specific commands or components

Addressing the change in GitHub actions

If you are using GitHub actions, remove any Alpine-specific commands from the inlineScript in azure/cli action to achieve a smooth transition to this new image.

Known issues with workaround

We have identified the following issues that may impact your pipelines or scripts:

Package missing

ICU package: Issue #29828 · Azure/azure-cli (github.com)

Jq: Issue #29830 · Azure/azure-cli (github.com)

Solution:

a. Pin azure/cli action to 2.63.0

- name: Azure CLI script uses: azure/cli@v2 with: azcliversion: 2.63.0 inlineScript: | <Your az commands here>

b. Install package manually: tdnf install -y icu, tdnf install –y jq

- name: Azure CLI script uses: azure/cli@v2 with: azcliversion: 2.64.0 inlineScript: | tdnf install -y icu tdnf install –y jq <Your az commands here>

tdnf not working in GitHub Actions: `tdnf` not working in GitHub Actions · Issue #29835 · Azure/azure-cli

A sample of affected use case:

jobs: test: runs-on: ubuntu-latest container: mcr.microsoft.com/azure-cli steps: - name: test run: | tdnf install -y zip

Solution:

a. Use azure/cli action

- name: Azure CLI script uses: azure/cli@v2 with: azcliversion: 2.64.0 inlineScript: | tdnf install -y zip <Your Azure CLI commands here>

b. Set GNUPGHOME to /root/.gnupg

jobs: test: runs-on: ubuntu-latest container: image: mcr.microsoft.com/azure-cli env: GNUPGHOME: /root/.gnupg steps: - name: test run: | tdnf install -y zip <Your Azure CLI commands here>

Thank you for your cooperation!

If you are not yet prepared to migrate to Azure Linux due to some specific issues, please open an issue on GitHub by clicking the below links, so we can assist you.

Open a Azure CLI issue

Open a Azure CLI action issue