Our Azure environment has grown a lot over the past year and we’ve had two incidents where Microsoft’s own support was basically useless. Slow response, generic answers, tickets bouncing around. We’re shopping for alternatives but every vendor we talk to sounds exactly the same.

Skipping the sales decks, what have people actually used for serious Azure support coverage? Specifically curious if third-party options can actually handle Sev1 issues without just escalating back to Microsoft anyway.

I just to know from internal folks that Azure is planning to 20% layoffs in Microsoft. Which month are they planning ?

Hi everyone,

I am doing a business case for a migration to Azure cloud.

The current on-prem server has an outbound traffic of approximately 40GB /day.

I found that for my region, the data sent outside the Azure data centres is 0.08 GB (according to this https://azure.microsoft.com/en-us/pricing/details/bandwidth/) . So the monthly egress expenditure for such server if we move to the cloud would be 0.08GB x 30 = 3.2$ per month?

Or that simple or is there anything I am missing?

Again, I am asking just for the egress traffic, not the cost of the server itself.

I appreciate your wisdom

I was setting up GPT-6.1 Sol and GPT-6 Luna on Azure this week, on Data Zone Standard deployments in France Central, because our users are in Europe and their data has to stay there. When I went to declare the prices, something didn't add up.

The Azure OpenAI pricing page still shows "$-" for every GPT-6 model, with a notice that prices are being published. So I read the meters straight from the Azure Retail Prices API. Prices per 1M tokens, short context:

Cached input, cache writes and the long-context meters follow the same pattern, and so do GPT-6 Sol and GPT-6 Astra.

For comparison, GPT-5.6 Sol in France Central costs $4.00 Global and $4.40 in the EU Data Zone: +10 %, the same premium as the US.

It isn't one region either. I get +20 % in every EU region I checked: France Central, Germany West Central, Poland Central, Spain Central, Sweden Central and West Europe.

So with GPT-6, keeping data in the EU suddenly costs twice the premium it costs in the US, and twice what it cost one model generation ago. I couldn't find this announced anywhere.

Does anyone know why? Is GPU capacity for GPT-6 scarcer or more expensive in Europe? Is it a pricing decision now that EU residency has become a requirement for many of us? Or will the numbers change once the pricing page is filled in?

Interested to know if this just a sign of the times or if we’ve done something wrong.

We have a long standing azure tenant where we can reasonably easily deploy new things and request quota and generally get approved. Annual spend into 7 figures (so not massive, but not nothing)

A management decision was made that we need a better separation of concerns so deploy a new tenant… but finding that lots of European regions are either not available (looking at you West Europe) or we can’t request quota for, they just get denied.

Also if we filling the odd foundry request form they get denied for anthropic globally.

Is this just was is to be expected with a new tenant and we have to get in a queue or is there a trick we’re missing.

Hi everyone,
We’re currently setting up Microsoft Intune in a GCC High tenant and trying to figure out the best way to provision brand-new or freshly reset Windows devices with Microsoft Entra Hybrid Join, ideally with an experience similar to Windows Autopilot.

In our commercial tenant, we’ve been using Windows Autopilot to automate device provisioning. We’d like to achieve something similar in GCC High.

Our environment:
Microsoft 365 GCC High
On-premises Active Directory
Microsoft Entra Connect
Intune (MDM user scope set to All)
Windows 11 laptops and desktops
Devices must remain joined to our on-premises AD due to internal network resources and file shares.

What we’re trying to achieve:
Unbox or reset a Windows device.
Start the Windows OOBE experience.
Have the device automatically join our on-premises AD.
Automatically register the device as Microsoft Entra Hybrid Joined.
Automatically enroll the device into Intune.
Apply configuration policies, security settings, and required applications.
Ideally, automatically assign a computer name and place the device in the correct AD OU.
The goal is to make the process as automated as possible, without manually joining each device to the domain or configuring everything individually.

My questions:
Has anyone successfully implemented a similar provisioning workflow in GCC High?
Is there a supported Autopilot-like approach for Hybrid Join in this environment?
Are provisioning packages (PPKG), Offline Domain Join, or PowerShell-based deployment workflows the best alternatives?
What does your actual deployment process look like, from a freshly installed Windows device to a fully managed Hybrid Joined device?
I’m especially interested in real-world experiences and solutions that are currently working in production.

Any advice or examples would be greatly appreciated. Thanks!

After the price increase announcement for selected Azure regions 2 weeks ago, our management want insights into these announcements through the Azure portal.

However, these announcements are only accessible to identities that have Owner or Contributor role on subscriptions. Since Least Privilege principles don't fancy casually handing out privileged roles, I am now looking into creating a Custom Role with just enough permissions to see the Service Health, including Billing Updates.

The Microsoft docs aren't helpful, as they only mention 'Custom role with the required permissions' without specifying what these permissions need to be. Reference: https://learn.microsoft.com/en-us/azure/service-health/billing-elevated-access#access-requirements

Initially I tried a restricted custom role scoped to the subscription level with only `Microsoft.ResourceHealth/events/read`, and `Microsoft.ResourceHealth/metadata/read`. Which clearly was not enough, and resulted in '"The client 'j.doe@domain.com' with object id 'abcdefabc-b33f-cafe-bd86-1234567890' does not have authorization to perform action 'Microsoft.ResourceHealth/events/read' over scope '/providers/Microsoft.ResourceHealth' or the scope is invalid. If access was recently granted, please refresh your credentials."'

I then tried a custom role with broader permissions:
- `Microsoft.Support/*`
- `Microsoft.ResourceHealth/*`
- `Microsoft.Resources/subscriptions/read`
Which resulted in the same 403 error for the billing updates.

I do see Health Advisories and Security Advisories.

Does anyone know what permissions are required? Or perhaps scope that needs to be applied.

This is the only thread where you should post news about becoming certified. For everyone else, join us in celebrating the recent certifications!!!

So we are running a fairly common azure setup i think

10-15 subs, random workloads etc.

Good governance in place, purview, defender for cloud etc, focus on compliance, data governance etc.

Now we have been looking at an IDM onboarding/offboarding tool and a fairly large consultant company has a solution that looked promising and they would like to deploy it a dedicated sub, so far no issue.

But, they want total control, they need it shielded aka no RBAC for us, no insight with purview, defender etc. They claim its because they need to protect their IP of what they deploy.

When i herd this i was a bit confunded as ive never herd a vendor requesting this, in my mind they are semi-batshit crazy to be honest but since the russian bots are sleeping i thought it would be a good time to ask here to see if someone has any sort of similar setup and are ok with it?

It boils down to us being very uncertain about giving someone a subscription and then not being allowed to have any access in it.

EDIT: Thank you for all responses, i feel better moving forward afte reading your replies.

​

Hi everyone,

I'm an independent developer using a relatively new Azure Pay-As-You-Go subscription. I'm trying to deploy GPT-5.1 (version 2025-11-13) through Microsoft Foundry for a private, single-user AI chat application.

However, I'm unable to deploy the model because my Global Standard quota is zero.

Current situation:

- Subscription: Pay-As-You-Go (not an Azure free trial).

- Model: GPT-5.1, version 2025-11-13.

- Global Standard: 0/0 TPM.

- Data Zone Standard: Insufficient quota.

- Global Batch: 50 million enqueued tokens available, but batch processing isn't suitable for my real-time chat use case.

- Deployment error: "Insufficient quota for selected options."

I also received an email titled "Important update: Eligibility for Quota Tier upgrade" on October 12, stating that my subscription was eligible for an automatic upgrade from Free Tier to Tier 1 unless I opted out within three days.

I'm hoping the upgrade will resolve the issue, but I haven't confirmed whether the tier change has taken effect or whether it will automatically grant GPT-5.1 Global Standard quota.

I found the official Microsoft Foundry quota increase request form, but it requires company information, including a company name, business email, and registered address. I'm an individual developer without a registered company.

My questions:

1. Does upgrading from Free Tier to Tier 1 automatically provide GPT-5.1 Global Standard TPM quota, or is a separate quota request required?

2. Has anyone experienced a delay between receiving the automatic tier upgrade notification and seeing the new quotas in Foundry?

3. Can individual Pay-As-You-Go developers request GPT-5.1 quota without a registered company? If so, which support or application process should they use?

4. Has anyone successfully obtained GPT-5.1 Global Standard quota on a new personal subscription recently?

I only need a small amount of TPM for low-concurrency, interactive API usage, not enterprise-scale capacity. I would also like to keep the specific GPT-5.1 model version rather than switch to another model.

I'd appreciate any firsthand experiences or suggestions. Thanks!

Saw this come through Message Center yesterday and figured it's worth flagging since the rollout starts in a few weeks.

MC1506733 says that from early November (finishing late November), users with no Entra role will be able to create agent identity blueprints by default. You have to opt out.

Why it matters: the blueprint is the template every agent identity gets created from. Credentials are configured on the blueprint, permissions granted to it flow down to every agent made from it, and whoever creates it becomes the owner and can spin up more agents from it without an Agent ID role. Creating one doesn't grant data access on its own since consent is still separate, but it's not really something I'd want as self-service.

To turn it off:

1. Entra admin center > Entra ID > Users > User settings
   
2. Under Default user role permissions, find **Users can create agent blueprints** (some tenants are showing it as "Users can register agent identity blueprints")
   
3. Set to No and save

You can change it now and it takes effect when the rollout hits your tenant.

A few things worth knowing:

- Admins and anyone with the **Agent ID Developer** role can still create blueprints, so that's the route for people who actually need to build agents
- Existing blueprints and agents aren't affected
- It's separate from "Users can register applications", so turning one off doesn't touch the other

Anyone already decided which way they're going on this?

Hey everyone,

I'm a founder of an early-stage startup in India, and I'm facing an unexpected billing issue with Microsoft Azure.

I had received $5,000 in Azure startup credits, and my usage was previously being covered by those credits. However, I've suddenly received a bill of around ₹9,000–₹10,000.

I've already raised a support ticket with Microsoft Azure, but I haven't received a proper response yet. Meanwhile, I'm continuing to receive emails warning that my account/subscription may be suspended if I don't pay the outstanding amount.

As an early-stage startup, this unexpected expense is a concern, especially when I believed my usage was covered by startup credits.

Has anyone faced a similar issue with Azure startup credits?

• Is there a way to escalate this to the Azure billing or Microsoft for Startups team?
• Can the bill be reviewed if the charges were unexpected or the credits weren't applied correctly?
• What should I do to avoid suspension while the support ticket is still pending?

Any advice from founders or anyone who has dealt with Azure billing support would be greatly appreciated.

Thanks!

We built a multi-agent proof of concept: an orchestrator delegated work to agents that analysed a document, searched SharePoint, drafted a response, and reviewed it. SharePoint contained only three small documents.
We prompted the main agent fewer than 20 times. Most tests timed out or returned “answer not found.” Yet downstream activity appeared to continue in the background, with agents repeatedly calling each other—ultimately generating 7.5 million+ Copilot Credits and an AUD $100k+ bill.
We received no direct notification that this activity was continuing or of the escalating costs. Investigating was difficult: the execution-history page crashed during review, and the Monitor export returned no usable records.
We’ve provided Microsoft with reports and screenshots. Support explains that autonomous executions are billable, but hasn’t addressed why this volume occurred or whether execution behaved correctly. The bill remains unpaid and disputed.

Has anyone successfully escalated a similar case and obtained a waiver? Which route actually helped—billing management, an account manager, a licensing partner, or another team?

We’re in Australia. Practical advice would be appreciated.

P.S.

We’re a small agency and don’t have a dedicated Microsoft account manager or customer success manager, so we’re looking for an escalation route available to customers without those contacts.

​

I've been away from the Fabric discussions for about a month, so I decided to see what Microsoft has accomplished in the meantime.

The answer is complicated.

Fabric has improved. There are new features, new integrations, and some genuinely useful improvements.

Unfortunately, some things that worked before now work worse, and some things that should have existed from the beginning still don't.

Microsoft has somehow managed to make Fabric both a better product and a worse platform simultaneously.

As someone who works with Azure, Databricks, SQL Server, and data engineering more broadly, I find this particularly frustrating. Fabric is being positioned as a major component of Microsoft's data platform strategy, yet many of its operational capabilities still fall short of what I expect from production Azure services.

Let's review.

1. Monitoring: Credit Where It's Due

The new Monitoring tab is better.

It's still not good. But it's better.

Unfortunately, while Microsoft was improving the monitoring UI, they also broke the explicit link between query insights and capacity metrics.

Previously, I could identify which query caused a capacity spike. Now I need an AI agent to tell me which query probably caused it.

I lost deterministic telemetry and gained an AI-generated guess that consumes additional tokens.

I'm paying more to get a worse answer to a question the platform could previously answer directly.

Imagine investigating Azure SQL performance and being told that instead of correlating query execution statistics with resource consumption, you should ask Copilot what probably happened.

But the Monitoring tab looks nicer.

Progress. Sort of.

1. Billing: Apparently Transparency Is Optional

Microsoft said they would provide a billing matrix because the new billing model needed to be defensible.

The billing changes went live October 1.

I still haven't seen the matrix.

That's two billing changes in a row without adequate transparency into how customers are being charged.

And now we've lost some of the telemetry needed to investigate those charges.

For those of us accustomed to Azure Cost Management, resource metrics, diagnostic logs, and usage attribution, this is particularly irritating.

Billing without sufficient telemetry is not a defensible operating model.

If you can't show customers how their charges were calculated, you have no business charging them that way.

I don't need an AI agent to guess why my bill went up.

I need the actual numbers.

I still maintain that this is unethical.

1. Scheduling and Orchestration: Still No Cron

Microsoft has announced pipeline dependencies, conditional retries, Business Actions, Fabric Actions, and improved ADF migration tooling.

All useful.

Still no cron.

Cron was introduced in 1975.

Fifty-one years ago.

Azure Data Factory supports scheduling capabilities that Fabric pipelines still lack. Azure Functions can use cron-style timer expressions. Even the humble Linux server has figured this out.

Apparently, Fabric hasn't.

The workaround remains running a pipeline every hour and checking whether it should actually do anything.

You could also call the "Is the Sun Up" API at the beginning of the pipeline.

If true, continue.

If false, exit.

Add a second API to check whether it's a weekday.

Enterprise orchestration.

I genuinely do not understand Microsoft's fear of enabling cron. Are they afraid people will start using Linux?

But now we have Business Actions.

Whatever those are.

1. dbt and General Availability: Different Definitions

Fabric now supports dbt Jobs.

That's useful, even though I personally loathe dbt.

However, Microsoft and I apparently have different definitions of General Availability.

dbt Jobs are GA.

Service principal and workspace identity support are still on the roadmap.

If I can't run a production workload under an appropriate non-human identity, I consider that feature beta or preview.

Microsoft apparently considers it production-ready.

We also seem to have different definitions of production.

So the Council of Nouns strikes again.

Azure has spent years developing managed identities, workload identity federation, Entra ID integration, and service principal authentication.

Yet somehow, a GA data engineering workload in Fabric can still be missing fundamental identity capabilities.

And while I appreciate the integration, I wonder how many external tools we'll need to add before Fabric becomes a complete data platform.

Presumably one of them will eventually provide cron.

1. CI/CD and Data Quality: Still Working on the Basics

CI/CD continues to be an exercise in discovering which Fabric items support Git integration, deployment pipelines, and automated deployment.

Microsoft calls this continuous integration.

I call it checking the documentation before every deployment to see whether anything changed.

The inconsistency is especially frustrating when working across Azure DevOps, Terraform, Databricks, Azure SQL, and other services where infrastructure and deployment automation are established practices.

A production platform shouldn't require a separate investigation into deployment support for every item type.

Then there's data quality.

We still don't have a native equivalent to Databricks Expectations integrated into the transformation pipeline.

You can ingest the data.

Transform it.

Publish it.

Whether it's correct is apparently outside the scope of a data platform.

Data quality isn't an optional feature of data engineering. It's part of data engineering.

But at least the deployment might succeed.

Depending on the item type.

And the workspace.

And which features are in preview this week.

1. Documentation and Airflow: Nobody Knows

Apache Airflow 3.x GA was scheduled for Q3 2026.

It's October.

The roadmap still says Planned, with a Q3 release date.

The description says Microsoft has already updated support to Airflow 3.3.

Microsoft Learn doesn't appear to have documentation for it.

So either Microsoft missed the release date and forgot to update the roadmap, or they shipped it and forgot to document it.

Both seem entirely plausible.

I'd check which one it is, but apparently that's not documented either.

Speaking of documentation, I also found a publicly accessible Microsoft Learn article marked Microsoft Confidential.

Apparently Microsoft can't consistently manage access to its own documentation.

But I'm sure the governance features are excellent.

1. The Broader Azure Problem

This is where I think the discussion extends beyond Fabric.

Microsoft is positioning Fabric as a unified analytics platform within its broader cloud ecosystem.

That's a reasonable vision.

But if you're an Azure architect or data platform engineer, you're accustomed to expecting certain fundamental capabilities from production services:

- Deterministic monitoring and diagnostic telemetry.

- Transparent, attributable consumption and billing.

- Reliable workload identity and non-interactive authentication.

- Repeatable infrastructure and application deployments.

- Flexible scheduling and orchestration.

- Integrated data quality controls.

- Accurate documentation and meaningful GA commitments.

These aren't exotic enterprise requirements.

They're the basics.

Azure already provides many of these capabilities across its existing services, although admittedly with varying degrees of consistency.

So it's particularly strange watching Microsoft build an ostensibly unified platform that requires us to work around missing capabilities we've had elsewhere for years.

And every workaround introduces another operational dependency, another failure mode, another piece of custom code, or another external service.

At some point, the simplicity promised by an integrated platform starts looking suspiciously like complexity that's been relocated rather than eliminated.

Final Assessment

Fabric has improved.

That's not sarcasm.

The new Monitoring tab is better. Pipeline orchestration is getting more capable. There are genuinely useful integrations and features that weren't available before.

It's also gotten worse.

We've gained more ways to run workloads while losing some of the direct visibility into what those workloads cost.

We've gained AI-assisted investigation while losing deterministic links between queries and capacity consumption.

We've gained GA features that still lack basic production identity support.

And we've gained new orchestration capabilities while still lacking scheduling functionality that existed in 1975.

Fabric is simultaneously more capable and less operationally trustworthy than it was before.

That's genuinely... something.

I don't expect every feature to be perfect.

I do expect a production data platform to provide reliable deployment, scheduling, identity management, monitoring, and defensible billing.

Those aren't exciting roadmap features.

They're operational prerequisites.

And the frustrating part is that I actually want Fabric to succeed.

I like the vision of a unified analytics platform. I like reducing integration overhead. I like making data engineering accessible without requiring teams to maintain fifteen different services.

But integration doesn't excuse the absence of fundamental operational capabilities.

And adding AI to compensate for missing observability isn't innovation. It's an elaborate workaround for a regression.

Fabric is better. Fabric is worse.

The vision is incredible.

Too bad vision doesn't build pipelines.

It builds PowerPoint slides.

#FabricIsTwine

Yes, I know hashtags don't work on Reddit.

I don't care.

Why am I getting error code 100014 when accessing https://admin.cloud.microsoft? The error says, “Login is not supported for consumer users without business presence.” I am using an Azure for Students subscription and a Microsoft Entra ID Free tenant. Is this issue occurring because I am using a personal Microsoft account, or do I need to configure any additional permissions or licenses to access the Microsoft 365 Admin Center? How can I resolve this issue?

I am looking for an AI tool to validate my azure bicep files for linting purpose.

I want to check for some basic rules like naming conventions,

Policies, code reusability,

Use of decorators etc.

Can someone suggest if you have any experience around that

We have environment handling fairly high throughput app - stable 500-1000 req/s.

We use private endpoints for CosmosDb, Storage Queues, Storage Blobs.

As per the documentation, in/out private endpoint traffic is charged at 0.01$ per GB, so $10 per TB.

Looking at one of our private endpoints metrics, I can see last 30 days there was a sum of ~50 TB data processed out, yet last month's charge for privatelink traffic was <100$?

What is going on here? I could imagine enterprise agreement could lower costs, but can't believe it made privatelink traffic costs 10x less than documented.

what do do here.. lol

can someone help!

Hi everyone!

I recently wrote a blog post about a specific Azure Lighthouse scenario that took a bit of digging to get right: assigning the Contributor role to a customer’s user-assigned managed identity from the service provider tenant.

The post walks through the process step by step, using Azure CLI and az rest from Azure Cloud Shell (Bash).

If you're working with Azure Lighthouse, cross-tenant management, or managed identities, I hope this walkthrough saves you some troubleshooting time.

Blog post: https://nicolgit.github.io/assignin-contributor-to-managed-identity-through-lighthouse/

One of the things I wanted to investigate was whether I could build a document extraction pipeline that competed with Azure Content Understanding on accuracy while significantly reducing inference costs.

The pipeline combines:

• Vision-language models for extracting user-defined fields and line items from PDFs.
• An independent text pipeline that provides a second source of evidence for validation.
• Disagreement detection to flag potentially incorrect extractions for human review.
• Visual grounding to trace extracted values back to the original document.
• Batch processing for handling 100+ documents in a single run.

I benchmarked Verdandi against Azure Content Understanding using GPT-5.5 and text-embedding-3 on a dataset of 100 documents, running each configuration twice.

My best Verdandi configuration, using GPT-6-Luna, achieved:

In this particular evaluation, Verdandi achieved approximately 9× lower cost per run, with slightly better extraction metrics.

These results are specific to my dataset and evaluation methodology. I'm not claiming Verdandi will outperform Azure Content Understanding across every document type or workload.

What I'm interested in is whether this architecture could be a viable alternative for teams whose primary requirement is structured data extraction rather than the broader capabilities of a managed document intelligence platform.

I'd appreciate feedback from people who have worked with Azure Content Understanding:

• Where does ACU provide the most value beyond extraction accuracy?
• What production considerations am I likely underestimating by building my own pipeline?
• For teams processing complex invoices and trade documentation, would you consider a custom pipeline if it offered comparable accuracy at substantially lower inference cost?

This is a personal engineering project, and I'm sharing the results because I'd like to understand where the approach holds up and where it doesn't.