Hi Team,

What is the general consensus on design decisions related to controls and restrictions against communication between subnets within vNets?Using NSGs or routing tables/rules vs multiple vNets with one per subnet? Looking at cost considerations when peering multiple vNets and simplicity to manage and other but at the same time having that zero-trust mindset. This is for both hub/spoke and vWAN architectures.

We migrated one of our biggest on prem sql servers to Azure a few months ago. We’ve hit the occasional high CPU flagged by a product owner whose app data lives in their DB that we host and created coding efficiencies, or in some cases we realized it was caused by MS maintenance. But now we are kind of seeing a pattern that everytime there is maintenance, new issues come out of the woodwork.

Perhaps more relevant is that we also recently upgraded from sql 2016 to latest sql version in azure sqlmi. A lot of the code was old. In hindsight, we should have used MS assessment tool to check what code will be impacted. I opened a ticket with Microsoft to investigate change on sqlmi level and also opened a ticket in devops for our DBAs to identify SPs and queries that are high CPU/slow/showing any performance issues at all. Then we will use one of the procs as a test case. I’m also going to set up a task to set up some monitoring/alerts.

Is there something I’m not thinking about that we should be thinking about? How would you handle?

Is anyone else having a bitch of a time getting compute sku capacity in Canada Central? 90% of the new subs we create have next to no compute skus available and the ones that we submit tickets for and they begrudgingly add capacity for us, it is usually only for 1 AZ. Just wondering if this is a universal issue with the region or they are just screwing with us.

Ok, so we used to use robcopy for file shares and now AzCopy for azure blob I guess. We need to feed a lot of massive research data from file shares to data lake. This needs to happen nightly on schedule from many sources dispersed geographically. While scheduled task can do the job, my manager does not think it is a solid solution because we have no visibility if the task fails. Ideally, should run as a service. Because this is feeding an AI modeling…etc. it is a critical project. TIA

Hello everyone,

I am planning to upgrade our current DevOps environment to the latest Version (Upgrade path is given by Microsoft Docs).

Unfortunately, we don't have a second environment to test the upgrade so maybe someone of you has some experience.

What we do have is that the Machine where our Azure DevOps instance is running is fully virtualized. We can do snapshots and restore. (HyperV)

Our instance unfortunately still uses XAML Builds for an legacy application that is still used by a lot of customers and is Business critical. These are sre not easy to migrate and are highly intertwined with business logic and some other dependecies. In Short: A Nightmare. We also use Classic Pipelines and Releases.

I know that XAML Builds are deprecated, but i inherited the Environment and the old engineer that build the whole Thing is not in the company anymore. So it is still kind of a "blackbox".

We could just snapshot the Environment before the upgrade and rollback. Never done it, but i think it should work if shit would hit the fan.

Does anyone have experience with Upgrading to a newer Version and XAML Builds?

What would be the best approach here?

Just a heads up for the community.

I've been told that come Feb 2027, VM prices will be increased in Azure anywhere between 8% to 18% depending on SKU and region.

Any VM that is under a current reservation will rename at the same price as what the initial commitment was.

MS will be making the announcement soon, but don't have an exact date.

Title. Since only the specific GH App can request a token , you cant run the Terraform state commands locally.

The workaround I can only think is to temporarily add Secret or if frequent then create Certificate in App Registration.

But are there other ways I am not aware, how do you guys handle such situations?

I’m testing the startup time of around 100 Azure VMs using Azure CLI (az vm start). So far I have two measurements:

Batch size 20: ~30 minutes total for all 100 VMs
Batch size 50: ~46 minutes total for all 100 VMs

The important part is that these are total wall-clock times for all 100 VMs, not the time for a single batch

Increasing the concurrency from 20 to 50 actually made the overall operation significantly slower. I’m wondering if this could be caused by Azure ARM/Compute throttling, backend queuing, or some other limitation around VM power operations.

My next test will be to submit start requests for all 100 VMs concurrently, without waiting for each batch to complete, and then poll the VM power states until all machines are running.

I don’t have the result for the 100-at-once test yet.

Questions

1. Has anyone tested starting 100+ Azure VMs simultaneously with Azure CLI?
2. Is there a recommended concurrency/batch size?
3. Can Azure VM power operations be throttled even if I’m not getting obvious 429 responses?

I’m specifically interested in real-world experience with large-scale Azure VM start operations.

I’ll update the post once I have the 100 at-once measurement.

I have a logic app triggered by service bus and has http action which runs a service fabric in the backend but this takes almost 15mins which is leading to time out and posts as failure status but the job runs. I want to handle this timeout exception. How can I resolve it?

Any insights are appreciated.

Disclosure: I work at a storage optimization vendor. Everything here uses native Azure tooling.

I cleaned up disks across a few subscriptions last week. The standard "unattached disks" query found 65 disks costing about $4,759/month. The checks below found 35 more, costing about $2,563/month.

Fix the base query

Filtering on Unattached alone misses two states:

Reserved: the disk is on a deallocated VM. The VM costs nothing while stopped, but the disk still bills in full. This was our biggest miss.

ActiveSAS: the disk is unattached but has an open export SAS.

Resources

| where type =~ 'microsoft.compute/disks'

| where properties.diskState in~ ('Unattached', 'Reserved', 'ActiveSAS')

| project name, resourceGroup, subscriptionId,

state = tostring(properties.diskState),

sku = tostring(sku.name),

sizeGB = toint(properties.diskSizeGB)

| order by sizeGB desc

What that still misses

1. Orphaned snapshots. These are snapshots whose source disk is gone.

Resources

| where type =~ 'microsoft.compute/snapshots'

| extend src = tolower(tostring(properties.creationData.sourceResourceId))

| join kind=leftanti (

Resources | where type =~ 'microsoft.compute/disks' | project src = tolower(id)

  ) on src

| project name, resourceGroup, subscriptionId, sizeGB = toint(properties.diskSizeGB)

2. Attached but never mounted. Azure reports these disks as healthy. Inside the VM, the disk was never formatted, or it was mounted without an fstab entry and lost at reboot. You have to check from the guest:

Linux: lsblk -f shows the disk with no filesystem type and no mount point.

Windows: Get-Disk | Where-Object PartitionStyle -eq 'RAW'

3. Mounted but idle. These disks are in use on paper but not earning their cost:

No I/O: disk read and write operations have been near zero for 30 days.

Mostly empty: for example, 5% used on 1 TB. Azure disk metrics don't show filesystem usage, so you need VM Insights:

InsightsMetrics  

| where TimeGenerated > ago(30d)  

| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"  

| extend mount = tostring(parse_json(Tags)["vm.azm.ms/mountId"])  

| where mount !in ("/", "/boot", "/mnt", "C:", "D:")  

| summarize minFreePct = min(Val) by Computer, mount  

| where minFreePct > 80  

Wrong tier: a P30 doing 40 IOPS could be an E30 at about a third of the cost.

Before you delete anything

Some disks look orphaned but aren't:

-ASRReplica disks belong to Azure Site Recovery.

AzureBackupRG_* resource groups hold Azure Backup restore points.

MC_* resource groups hold AKS volumes.

Databricks-managed resource groups break if you touch them.

If you're not sure, snapshot first.

Has anyone heard where Microsoft is in terms of launching East US 3 (Atlanta)?

They announced/started construction in 2021 and I get that was kind of in the depths of COVID but we're going on 6 years now

Anyone have an idea when this will be available, and what its paired region might be? We're in Atlanta, will be leveraging Express Routes, and about to start building out basically from scratch and it'd be really great to know when this is dropping but it's been silence it seems since the initial announcement

Microsoft announced that ACS Chat and Job Router are retiring on September 30, 2028, while existing workloads remain supported during the transition and no new resources creation is supported after 23 oct 2026

This is particularly concerning for us because we recently implemented a live-agent solution using ACS Chat + Job Router + Microsoft Teams.

Our architecture is roughly:

Customer → Chatbot → ACS Chat → Middleware → Job Router → Agent Queue → Teams

We already completed the implementation through Dev and QA, including custom routing, agent availability checks, conversation lifecycle/state management, queue handling, and Teams integration.

During our initial design phase, we actually evaluated Dynamics 365 Contact Center, but moved away from it primarily because of the cost/licensing model(~8k/user/month). So going back to D365 Contact Center isn’t really an option for us.

That’s what makes this retirement announcement painful becoz a significant amount of engineering effort has already gone into the current architecture, and it was almost done and we don’t want all of that work to simply become a dead end. 🙂

I’m looking for ideas from people who have built similar systems:

-> Is there a viable alternative to ACS Job Router without adopting D365 Contact Center?

-> Could we keep Teams as the agent interface and replace Job Router with a custom routing/queue service?

-> For the customer chat side, would Microsoft Graph + Teams work, or would a third-party CPaaS be more appropriate?

-> If anyone was in this same huddle, Has anyone already started planning a migration from ACS Chat/Job Router?

Looking for any suggestion and solutions that preserve the existing architecture as much of the existing implementation as possible, rather than completely rebuilding the solution.

Thanks in advance.

Of course it’s the Azure AD sync issue with Google Workspace. We run a hybrid setup where the primary identity layer sits on Azure AD (Entra ID), but half the company basically lives inside Google Workspace all the time. Keeping our user groups synced & permissions consistent across both platforms eats way more admin time than necessary.

We actually decided to pull in Cloudfresh last month to help streamline the cross-cloud licensing side & try to tune our Google Workspace SCIM setup so it matches our Entra ID source cleanly, they caught a few sync attribute misconfigurations on the Workspace side that were spawning duplicate accounts.

For what it’s worth, multi-cloud always seems to breed these weird lil edge-case admin chores for some reason.

Question: how do you handle group provisioning across more than one identity provider?