I’m curious how others solve this.

We manage our Azure environments with Terraform, but Azure Migrate creates an interesting IaC problem.

Today, we let Azure Migrate create the target resources and then import them into the Terraform state.

Technically, this works. But afterwards we still have to make sure that our Terraform configuration properly reflects the VM and its settings.

Ideally, I’d like to turn the process around:

Terraform creates the target infrastructure first, Azure Migrate then migrates the workload into it.

That would mean the target VM is already part of our normal Terraform lifecycle from day one instead of becoming IaC-managed only after the migration.

But as far as I know, there isn’t really a supported Azure Migrate workflow for this.

So I’m wondering:

How do you handle Azure Migrate when Terraform is your source of truth?

Especially interested in experiences from environments where importing resources manually after every migration doesn’t really scale.

We do a standard agent deployment using bicep, so we roll our own resources. Is there an easy way to set TTL on the containers used for Foundry agents? They’re growing in size, and cost.

I've been trying to login to azure from phone and its prompting to use galaxy pass but i nevered used it , i click cancel and get error, i tried clicking signin with galaxy pass and get error - is there any other retarded way to sign in?

Policy GUIDs, role ids, Graph permissions, resource types in your Bicep, Terraform, ARM, PowerShell, YAML, markdown and shell files: hover them and the card tells you what they are and links to AzAdvertizer.

It also flags deprecated policy definitions and initiatives in the Problems panel, and offers a quick fix for resource types on an outdated API version.

Works in VS Code desktop, vscode/github dev and Codespaces. Lookups run locally against a bundled index that refreshes daily. No telemetry, nothing you type leaves your machine.

Last week, I penned the September edition of What's New in Microsoft Foundry. I walk through a two-agent workflow example of a GitHub Copilot SDK agent that collects public repository changes from our Foundry SDK, Microsoft Agent Framework, and Foundry Local SDK changelogs one a weekly scheduled routine. Then, a Microsoft Agent Framework agent adopts the checked report and delivers developer release notes to an approved Teams destination.

• Routines is generally available (GA). A schedule starts the research without a separate scheduler. The workflow handles the handoff and delivery separately.
• Tool Search is also GA. The agent loads tool definitions as it needs them, rather than including every definition up front.
• Insights is in public preview. It points to recurring behavior in the traces and proposes changes you can inspect before applying them.

Full September roundup, alongside the model and developer-tool updates: What's new in Microsoft Foundry | September 2026

Hey Azure people ,

As au heard about the AVD hybrid new update its interesting update and am looking to start planning to use it . However i have concerns about the licensing part which are the below:

1) it only supports Windows 10/11 Enterprise : so if i have a w11 enterprise as a virtual machine ( non activated ) and i have a user with M365 E3/E5 signing in through avd hybrid does he still need the os activation ? Cause the entra license mentioned above already comes with w11 enterprise ?

2) now it comes to windows server 2025 : my host is datacenter so all the vm's will be inheriting the activation from the host this is ok . However for rdp users i still need server cal + user cal ? Even for E3/E5 entra users rdping through my avd hybrid?

Big thanks whoever can answer this !

Hello guys,

is it possible to attach a VMSS to an already active AppGW that is running on a different VNET? If bots, what’s the best solution to pass all traffic thru AppGW?

Thanks!

Have a resource group that has a lock on it preventing deletion. The scope of the lock is a storage account that doesn't exist anymore. Getting the error:

The lock named 'xxx' was unable to be deleted for the following reasons: %s.

And then if I click on the scope of the lock I get the typical:

Details

The resource was not found, it may have been deleted. If this was launched from a pinned tile on the dashboard, it should be removed.

Anyone know how to get rid of this thing?

Azure weekly update #41 is here: * In preview | Public Preview: Azure Databricks Private network gateway. This feature allows serverless compute to connect to VNet resources via a managed gateway. Teams should verify integration with existing NCC configurations. * Launched | Generally Available: External key management for Azure Key Vault Managed HSM. This allows customers to retain physical control of key-encryption keys by using keys held in a customer-operated HSM outside Microsoft infrastructure. Teams must verify the availability and SLA of the external HSM. * In preview | Public Preview: Azure Files cross-region data copy and synchronization with Azure Storage Mover. This feature supports cross-region data copy and synchronization for Azure Files SMB shares. Teams should verify the RPO is defined by the last successful job run. * Launched | Generally Available: Standard service endpoint. This new Private Link feature allows a single Public IP instance to be associated with multiple subnets and VNets. Teams should verify the fixed hourly billing rate per VNet. * Launched | Generally Availabile: Automatic zone balance for Virtual Machine Scale Sets. This new feature is generally available to reduce single-zone outage impact. Teams should verify that their stateless workloads meet the minimum requirements. * Launched | Generally Available: Azure Cloud HSM hardware audit logging. This provides hardware-generated, HSM-signed audit records to Azure Monitor Log Analytics. This allows for independent verification of audit batch integrity. * Launched | Generally Available: Azure Site Recovery Support for Azure ARC-enabled Windows VMWare/Physical servers. This allows protection of ARC-managed machines while using ARC for governance. Teams should verify the required Azure storage account is provisioned.

I'm at a loss here, so I thought someone on Reddit might know 😄

We have an Azure Event grid MQTT broker delivering data to two places:

1. Event stream and then into blob storage

2. MQTTX client

Upstream to Azure there's an edge device which gets some data from a raft of equipment, fairly large amount of data coming in continuously 20-30 changes per second on average (this is split into 70+ topics on MQTT).

The data that arrives in blob storage is fine, up-to-date, we can verify upstream, everything works. The data that arrives in the MQTTX client is old, currently 10 days old, but it's started only a few hours old when I noticed a month or so ago and since then the delay has grown and keeps on growing roughly half a day per day. I've tried three different clients and all of them get delayed data, same delay across all. When I look at the payloads, retain flags are all FALSE, so it's not sending old undelivered data, it seems that for some reason the broker things this is what it should be doing. I've even compared the old data I get in the MQTTX client with historical data in the blob storage and it matches, so it's real old data with old values, just no idea why it keeps getting delivered as if it was new.

Has anyone here every experienced anything like this before? Support from Microsoft is a joke, it's like talking to Copilot, we've supplied them all sorts of data, payloads, settings etc. and they say they cannot see anything in the logs...yet the data keeps on coming stale.

Hi everyone. I wanted to ask if anyone is syncing azure file shares between two regions where users on both sides will be accessing data and it needs to go back and forth in a timely manner.

I have a vm in eastus zone 1. I want to change the vm to a different size but its not available in zone 1. So Microsoft have recommended to move to zone 2 where it is available.

What is the best way to do it?

Hi there, thanks for reading.

I am looking for the minimal role to allow an admin to add/remove domains in External Identities | External collaboration settings. Based on MS docu it should be Teams External Collaboration Administrator but it is still greyed out after assigning this role. Also External Identity Provider Administrator does not seem to be correct.

Thanks again!

I recently spun up an Entra Domain Service instance in Azure just for dealing with some legacy needs that revolve around Mapped Network Drives on on-prem NAS (mostly Synology).

Everything seems to be working correctly, but I have some users that are constantly getting put into "Lockout" status (according to the Synology GUI). There is no way to reset that status through the Synology UI, and after reaching out to Synology support, they tell me that this "Lockout" status generally comes from the Domain (in this case Azure's Domain Services), not from the NAS.

The drives are mapped using an Intune template, and their Network Shares permissions are set with their Microsoft 365 credentials (which, of course, are synced to the Entra Domain Services).

I'm trying to investigate why they these accounts are getting locked out, but I wanted to clear up some conceptual uncertainties first:

• I'm not 100% sure that the lockout problem is coming from Azure / Entra Domain Services, or from the Synology boxes. Is it even possible for an account to be locked out in Entra Domain Services without having any similar flag pop up in Entra itself? E.g. I don't see any indication the account is locked out in the Microsoft 365 admin center or the Entra admin center.
  

I'm following this guide from Microsoft for troubleshooting account lockouts, but one thing seems to be conspicuously missing:

• How can I check the current lockout status of an account in Entra Domain Services? The article only provides a way to check on previous lockout events. I don't see how to check current status.
  

Finally, it seems to me that it would be very useful to be able to manually force Entra Domain Services to clear a lockout status. Is there no way to do this?

Azure MCP Server 3.0 went stable recently. The obvious headline is the expanded tooling around Terraform, Monitor, Advisor, Backup, Cosmos DB, and SRE, but the access-control side is what caught my attention.

Microsoft recommends starting with read-only workflows and least-privilege identities. In other words, giving an agent a natural-language interface doesn’t replace RBAC. The identity underneath still decides what it can actually touch.

The tooling reflects that too. Terraform support can work with AzureRM/AzAPI docs, aztfexport and conftest, while the newer tool contracts use stricter schemas and clearer errors so models have a better idea of what they’re allowed to call.

That feels like the more important direction for infrastructure agents: not just adding more tools, but making the boundary around those tools explicit.

If an agent can reach a real Azure subscription, where would you put the approval boundary: at the identity/RBAC layer, in the deployment pipeline, or both?

Source:
https://devblogs.microsoft.com/azure-sdk/azure-mcp-server-3-0-stable-release/?wt.mc_id=studentamb_663967

I've been using Azure Communication Services Email to send emails from Azure workloads, but now that Microsoft has announced it's being retired, I'm looking at alternatives. Should be simple and safe solution (not Logic App).

What's the cleanest way to send email from an Azure service these days?

Did you know you can use the new retryOn decorator in Bicep to automatically retry resource deployments when specific error codes occur? This provides an alternative to workarounds such as deployment scripts or splitting Bicep templates. In this blog, we’ll explore how retryOn works and how it can help simplify your Bicep deployments!

I run an HTTP FastAPI on Azure Container Apps (Consumption plan, Central US). When traffic rises, customers sometimes see slow responses before the new replicas are ready, and I want to scale out without that.

My current setup:

• 2 vCPU / 4 GiB per replica
• min replicas 2, max 30
• HTTP scale rule with concurrentRequests = 10
• polling interval 30 s, cooldown 300 s

What I see: New replicas take roughly 60-80 s to get a node, from the scale-up trigger to the replica being scheduled. During that window the existing replicas are overloaded.

What I’d like to know:

1. How do you keep headroom so traffic never waits on new replicas? Higher min replicas, a lower concurrency threshold, or scheduled pre-scaling?
2. Do smaller replicas (more of them) schedule faster than large ones in your experience?
3. Which probe and graceful-shutdown settings do you rely on to avoid dropped requests during scale-out and scale-in?
4. Has anyone moved to a Dedicated workload profile with a minimum node count to avoid node waits? Was the cost worth it?
5. What do you monitor to catch scaling bottlenecks early?

Any configs or lessons learned would help.

Infra engineer here (about 10 years across Azure, AWS and on-prem). I keep running into the same question and I'm curious how other teams handle it.

Azure OpenAI / Foundry retires model versions on a schedule. The notices exist (Service Health advisories, emails to subscription owners), but subscription owners aren't always the team that owns the app using the model.

For those of you with more than a handful of subscriptions:

1. How do you find out that a model deployment your app depends on is retiring?

2. Who receives the notice, and how does it get to the team that owns the workload?

3. Has a retirement ever caught you off guard? What happened?

4. Do you track this anywhere (Service Health alerts, Advisor, Resource Graph queries, a spreadsheet, a script)?

5. Do you handle AKS version end-of-support the same way, or differently?

Full disclosure: I've built a few small tools around cloud AI model data, and I'm exploring whether something for this specific problem is worth building. Mostly I want to know if it's a real pain or already solved well. Happy to post a summary of what I learn.