rss.livelink.threads-in-node

Right‑sizing Azure Savings Plans, one hour at a time

Dirk_Brinkmann — Thu, 11 Jun 2026 20:21:40 GMT

Most of us have, at some point, sized a commitment the same way we order food for a team offsite: estimate, round up, and hope nobody complains. It works for pizza. It is a less robust strategy for a three‑year Savings Plan.

Azure Cost Management already produces commitment recommendations for you, and they are a great starting point. But the headline dollar figure on the portal hides the most useful signal a FinOps team can get its hands on: the hourly Pay‑As‑You‑Go (PAYG) usage that the recommendation engine actually looked at. Once you have that signal in a spreadsheet, "right‑sized" stops being a vibe and starts being a number you can defend in a steering meeting.

This post walks through how to pull that data out of the Cost Management REST API, and shares a small companion PowerShell script that does the heavy lifting and produces analyst‑friendly CSV and Markdown outputs.

Why a single recommended number isn't enough

A Savings Plan recommendation is, at its core, an optimisation against a distribution of hourly compute spend over a lookback window. The portal typically surfaces the single commitment level that maximises savings under a "reasonable utilisation" assumption. That's a sensible default, but it answers only one question.

The questions FinOps practitioners also want to answer include:

What does my PAYG demand actually look like hour‑by‑hour? Smooth and predictable, or spiky and seasonal?
How does coverage and savings change if I commit a bit less, or a bit more?
Will the recommended commitment leave me with wastage on weekends or overnight?
Can I correlate the hourly profile with maintenance windows, batch jobs, or business hours?

You cannot answer those questions with a single dollar figure. You can answer all of them with the hourly series and the alternative commitment levels — and the API exposes both.

What the Benefit Recommendations API gives you

The endpoint is the Benefit Recommendations - List operation (api-version=2025-03-01). Pointed at any of the supported scopes — Billing Account (EA), Billing Profile (MCA), Subscription, or Resource Group — it returns one or more recommendations for the chosen lookBackPeriod (Last7Days, Last30Days, Last60Days) and term (P1Y, P3Y).

The two $expand options are where the magic lives:

$expand=properties/allRecommendationDetails returns an array of alternative commitment levels (AllSavingsBenefitDetails). Each entry includes commitmentAmount, coveragePercentage, benefitCost, overageCost, savingsAmount, savingsPercentage, wastageCost, and averageUtilizationPercentage.
$expand=properties/usage returns the hourly PAYG charge series (usage.charges) that the engine used. Combined with properties.firstConsumptionDate and properties.lastConsumptionDate, you get a complete time‑aligned view of demand.

Both expansions are cheap and worth requesting every time. They turn a single recommendation into a small, complete data product.

Meet the script: Export-BenefitRecommendations.ps1

To make this useful in five minutes rather than an afternoon, there is a PowerShell script on GitHub that wraps the API call and produces ready‑to‑use artifacts. It is interactive, so there is nothing to memorise:

=== Azure Benefit Recommendations Export === Select billing scope kind: * [1] Billing Account (EA) [2] Billing Profile (MCA) [3] Subscription [4] Resource Group Enter choice 1-4 (default 1): 1 Billing Account ID: <your-EA-billing-account-id> Select lookback period: [1] Last7Days * [2] Last30Days [3] Last60Days Enter choice 1-3 (default 2): 3 Select term: * [1] P1Y [2] P3Y Enter choice 1-2 (default 1): 2 ... Retrieved 1 recommendation(s).

It authenticates via the Az.Accounts module, always requests both $expand options, follows nextLink pagination, verifies API access up front (translating 401/403/404 into actionable hints), and writes four files using a predictable name pattern:

yyyy-MM-dd-<scope>-<lookback>-<term>-AllRecommendationDetails.csv — one row per commitment alternative, ready for pivot tables.
yyyy-MM-dd-<scope>-<lookback>-<term>-TopRecommendation.md — a Markdown brief on the top recommendation, including the recommended commitment row and the full alternatives table.
yyyy-MM-dd-<scope>-<lookback>-<term>-HourlyUsage.csv — hour‑by‑hour PAYG usage for the top recommendation, aligned to the API's actual data window (no padding, no trailing blanks).
yyyy-MM-dd-<scope>-<lookback>-<term>-Raw.json — optional full response dump, for archival or downstream tooling.

The naming convention is intentional: paste a folder of these into Power BI and the dates, scopes, and terms are already in the filename.

A worked example

Here is a real shape from a sample Last60Days / P3Y export against an EA billing account. The AllRecommendationDetails CSV gives us four commitment alternatives:

averageUtilizationPercentage,coveragePercentage,commitmentAmount,overageCost,benefitCost,savingsAmount,savingsPercentage,totalCost,wastageCost 100.000,28.868,4.124,30914.280,5889.072,6656.889,15.317,36803.352,0.000 100.000,39.168,5.848,26437.791,8350.944,8671.506,19.953,34788.735,0.000 9.984,97.883,16.359,919.948,23360.652,19179.641,44.131,24280.600,3.767 98.684,98.900,16.806,477.956,23998.968,18983.317,43.680,24476.924,315.907

Read those rows like an interactive lever:

Commit $4.124/hr → 28.9% coverage, 15.3% savings, zero wastage. Safe, but most of your spend is still PAYG.
Commit $5.848/hr → 39.2% coverage, 19.9% savings. Still safe, still conservative.
Commit $16.359/hr → 97.9% coverage, 44.1% savings, ~$3.77 of wastage. This is the sweet spot the engine flags as recommended.
Commit $16.806/hr → 98.9% coverage, 43.7% savings, but wastage jumps to $315.9 over the window. You bought more coverage and the engine charged you for it.

The hourly CSV is what makes the recommendation defensible. It contains 1,428 rows — one per hour from 2026-04-11T00:00 through 2026-06-09T11:00 (the API's reported data range, not "now minus 60 days"):

DateTime,HourlyPayGoUsage 2026-04-11T00:00,29.5350191832771 2026-04-11T01:00,29.566694701744 ... 2026-06-09T11:00,32.7312920192344

Drop that into Excel or Power BI, lay a horizontal line at the recommended commitmentAmount ($16.359/hr), and you immediately see how often demand sits above the line (covered by PAYG overage) versus below it (where the commitment is technically idle but, given the savings rate, still net‑positive). You can also slice by hour‑of‑day to spot weekend troughs or batch‑job spikes that change how you interpret "average utilisation."

Try it yourself

The script and full documentation live at github.com/DirkBrinkmann/azure-savingsplan-insights. Quickstart:

git clone https://github.com/DirkBrinkmann/azure-savingsplan-insights.git cd azure-savingsplan-insights Install-Module Az.Accounts -Scope CurrentUser # if you don't already have it #Connect to Azure Connect-AzAccount #Run the script .\Export-BenefitRecommendations.ps1

You will need read permission on the scope you target — Cost Management Reader on a subscription, or Billing Reader at the billing account / billing profile level, is enough.

Give it a spin against your own scope and tell us how it goes. The repo at github.com/DirkBrinkmann/azure-savingsplan-insights has Issues and Discussions enabled — bug reports, edge cases ("my response shape looks different"), feature ideas, and "I plotted this in Power BI and learned X" stories are all welcome. The script will only get better with real‑world data behind it, and yours is the kind we want to hear about.

Closing nudge

In FinOps terms, this is squarely an Inform phase activity: turning a black‑box recommendation into a transparent dataset your team can challenge, chart, and align on. The API has had this data all along; the script just makes it boring to extract — which is exactly what you want a FinOps tool to be.

Pull a Last60Days / P3Y export for your top‑spending scope, plot the hourly line, and decide your next Savings Plan with a number you can point to. Your future self (and your finance partner) will thank you.

Modern VM monitoring, powered by OpenTelemetry

viviandiec — Thu, 11 Jun 2026 18:57:11 GMT

At Build 2026, we're announcing the general availability of OpenTelemetry (OTel) Guest OS metrics for Azure VMs and Arc-enabled Servers. OTel provides a standards-based foundation for VM monitoring with consistent metrics across Windows and Linux, richer Guest OS and per-process visibility, and streamlined integration with open-source and cloud-native observability tools.

Alongside the GA, we're introducing an enhanced VM monitoring experience, recommended alerts, and out-of-the-box Grafana dashboards, all powered by OTel Guest OS metrics. We're also sharing upcoming VM troubleshooting capabilities in the Azure Copilot observability agent enriched by OTel Guest OS metrics.

What are OpenTelemetry Guest OS metrics

OTel Guest OS metrics are collected from inside a VM. Today's coverage includes a curated set of CPU, memory, disk I/O, networking, and per-process metrics including CPU utilization, memory usage, uptime, and thread count. The supported set is point-in-time and will continue to expand as the OTel Host Metrics Receiver evolves upstream.

This level of visibility helps customers diagnose operating system and application issues without manually signing into individual VMs.

Why they matter

1. Lower cost and faster queries

Default OTel Guest OS metrics are available at no additional cost. They are stored in Azure Monitor Workspace using metric-optimized storage and pricing, providing lower cost and faster query performance compared to LA-based metrics.

2. Per-process visibility for deeper troubleshooting

Customers can optionally enable per-process metrics for deeper visibility into VM resource consumption. This helps identify noisy processes, memory leaks, runaway jobs, or resource-intensive applications without manually signing into the VM.

3. Consistent metrics across Windows and Linux

Use the same metric names, dashboards, and alerts across operating systems without maintaining separate monitoring configurations.

4. Native PromQL support

Use PromQL with the scale and managed experience of Azure Monitor Workspace.

5. OpenTelemetry-based standardization

Use the same metrics across Azure Monitor, existing OTel pipelines, or other compatible observability backends.

Log Analytics (LA)‑based metrics vs OTel‑based metrics

Customers running workloads on Azure VMs and Arc-enabled Servers have long relied on Log Analytics (LA)-based metrics for fleet visibility. That experience continues to be generally available and trusted by thousands of customers.

We recommend evaluating your requirements to determine which approach best suits your needs. LA-based metrics remain the foundation for customers who need advanced analytics and correlation, while OTel-based metrics open new possibilities for modern VM observability. Learn more.

New Capabilities Powered by OpenTelemetry

VM monitoring experience powered by OpenTelemetry (GA)

We're excited to announce the general availability of the enhanced monitoring experience for Azure VMs and Arc servers. This experience brings comprehensive monitoring capabilities in a single, streamlined view, helping you more efficiently observe, diagnose, and optimize your virtual machines.

The new experience offers two levels of insight within one unified interface:

Basic view (Host OS-based): Available for all Azure VMs with no configuration required. This view surfaces key host-level metrics including CPU, disk, and network performance for quick health checks.
Detailed view (Guest OS-based): Requires simple onboarding. Azure Monitor continues to support the GA detailed view powered by Log Analytics-based metrics. Customers can now choose to power the experience using OTel Guest OS metrics, which enable recommended alerts and provide expanded visibility into Guest OS and process-level resource consumption, including CPU, memory, disk I/O, and networking.

Dashboards with Grafana for VMs

For deeper analysis and customization, customers can leverage Azure Monitor dashboards with Grafana powered by OTel Guest OS metrics and PromQL at no additional cost.

Built-in dashboards provide out-of-the-box visualizations for at-scale monitoring, host-level monitoring, Guest OS monitoring, and per-process monitoring, while still allowing teams to:

Customize panels and dashboards
Run ad hoc investigations
Import dashboards from the Grafana community
Share dashboards using Azure RBAC and ARM/Bicep deployment support

Together, the enhanced VM monitoring experience and Grafana dashboards provide both streamlined day-to-day monitoring and flexible deep troubleshooting capabilities for modern VM environments.

Query metrics in the context of your resources (GA)

We’re also announcing the general availability of resource-scope querying for Azure Monitor Workspace (AMW) metrics, including OTel Guest OS metrics. With resource-scope query, you can query metrics directly from the context of a resource, resource group, or subscription, without needing to know which workspace stores the data. This simplifies troubleshooting, aligns with Azure-native workflows, and enforces least-privilege access using Azure RBAC.

This capability powers scenarios like querying OTel Guest OS metrics directly from the Virtual Machine resource in Azure Portal, or resources can be scoped as a dedicated data source in Grafana to query with PromQL, making it easier for application and infrastructure teams to monitor and troubleshoot in the context of their workloads.

Coming soon: Observability Agent Troubleshooting for VMs (Public Preview)

Today, the Observability Agent helps customers investigate issues by correlating applications, infrastructure signals, LA-based metrics, logs, alerts, health information, and recent changes into a guided investigation narrative.

Support for OTel Guest OS metrics is coming soon, extending investigations with richer Guest OS and per-process visibility. With OTel Guest OS metrics, the Observability Agent will be able to incorporate finer-grained operating system and process-level insights into its analysis, helping customers more quickly identify resource bottlenecks and understand their impact on application performance.

Instead of manually piecing signals together across multiple tools and timelines, customers will receive a guided investigation summary with likely causes and recommended next steps. Combined with the new VM monitoring experience and Grafana dashboards, customers will have both AI-assisted investigations and powerful manual troubleshooting tools built on the same OTel foundation.

Onboarding VMs at scale to OpenTelemetry

Onboarding Azure VMs and Arc-enabled Servers to OTel Guest OS metrics is now simpler and more cost-efficient than ever. For teams getting started at scale, the easiest path is through the Monitoring Coverage experience in the Azure portal, where you can review recommended resources and onboard VMs through a guided workflow.

Customers that prefer infrastructure-as-code can use ARM and Bicep templates to apply the same monitoring configuration programmatically.

Azure Advisor recommendations provide another seamless entry point for onboarding, proactively identifying VMs that are not fully monitored and guiding customers to enable OTel -based monitoring with a few clicks. This helps teams continuously improve coverage across their fleet without needing to manually audit resources.

Customers can now also reuse an existing Data Collection Rule (DCR) during onboarding, making it easier to standardize monitoring across large VM fleets. After onboarding, teams can centrally evolve their monitoring configuration by updating that DCR to collect additional metrics and logs, with changes applying across all associated VMs.

Get Started

Explore the new OpenTelemetry-powered experiences today:

Customer spotlight: Less inbox, more connection at Nuveen

sarahLundy — Thu, 11 Jun 2026 19:40:15 GMT

Helping leaders reach employees in new ways

At the Microsoft 365 Community Conference, we explored a challenge many communicators are dealing with right now: employees are surrounded by nonstop signals—email, chats, meetings, and posts—and important messages get lost in the noise.

Dan Mulcahey, VP, Internal Comms at Nuveen, a TIAA company, joined us to share how he and his team are evolving their communications approach using Viva Engage to make messages more relevant, visible, and engaging over time.

Mulcahey highlighted how moving away from email to Engage marked a strategic shift in how leaders communicate and build connection with employees.

Why email wasn’t enough

The Nuveen comms team looked at the reality: email volume was high, open rates were going down, and leaders needed a better way to reach employees. From there, they piloted Engage, proved reach first, and built confidence over time. Reach came quickly, while engagement required more patience.

“We proved the reach first… But you need patience for the engagement.”

— Dan Mulcahey, VP, Internal Comms, Nuveen

Create for the channel

One of the biggest lessons from Nuveen was that communicators can’t just copy email content into a social channel and expect different results. The team had to create content for the medium. For example, Nuveen’s CEO launched a recurring “Fun with Facts” series that used humor and short videos to make even routine topics, like compliance training, more engaging.

That shift in content style reflects a broader change toward making communications feel more like what people already consume outside of work: more visual, more direct, and more conversational. What people experience on social platforms and consumer apps shapes what they expect at work, and internal communications need to keep up.

“People don’t come to work and suddenly turn off their brain. They don’t forget the platforms they use in the real world.”

— Dan Mulcahey

Mulcahey reported that since June 2023, for a business unit of around 3,700 employees, that approach generated 2.5 million impressions, 25.5K reactions, and 2K comments on Engage, along with what the team described as “one executive team of believers.”

In a video shared during the session, Josh Shamansky, Chief Human Resources Officer, said Engage had become central not only to communications distribution strategy, but also to content development. He also shared that employees and leaders were engaging in ways that email and the intranet could not support in the same way.

“Viva Engage has become the most important channel for leaders and employees to stay connected across the organization. It is hard to remember that we did it any other way.”

— Josh Shamansky, Chief Human Resources Officer, Nuveen

Start small, build momentum

The Nuveen team described a phased journey that started small in one business area, expanded to a 3,700+ person Nuveen business unit community, then grew to 10 more communities before expanding to the TIAA all-company level. They focused first on the parts of the organization most ready to adopt, used those wins as proof points, and let leadership advocacy help the model spread.

Mulcahey and members of his team — Chris Dickey, Comms Business Partner, and Chris Martin, Communications Operations Lead — talked openly about the importance of “starting small and sending wins up the chain,” democratizing communications operations, and enabling non-communicators to help carry the story forward.

That meant communicators weren’t the only people creating momentum: leaders, advocates, and business-area contributors became part of the engine. That matters even more in an AI era, where the opportunity isn’t just to create more content faster, but to build more distributed participation around the messages that matter.

If there is one takeaway, it’s this: relevance comes from building communications that fit the channel, reflect how people consume content, and unfold over time in a way employees can follow.

We’ll be sharing more blog posts throughout June to recap the Engage Track sessions at the Microsoft 365 Community Conference. Follow along on the Viva Engage Blog | Microsoft Community Hub, and learn about all the new and coming soon experiences in Engage that we highlighted at the conference.

Tech, Community, and a Movie: MVPs Help Bring Stir Trek to Life

BetsyWeber — Thu, 11 Jun 2026 18:01:24 GMT

What happens when you combine a full day of technical learning with a movie theater full of developers, designers, and tech leaders - and a shared commitment to giving back? You get Stir Trek: Tech & a Flick, a one-day community conference in Columbus, Ohio, that ends not with closing slides, but with popcorn and a blockbuster movie.

Since its first event in 2009, Stir Trek has built a reputation for being practical, welcoming, and unmistakably different. The format is simple: 50+ sessions of technical content, conversations with regional and national speakers, breakfast, lunch, movie refreshments, and a shared movie screening experience. But the impact goes beyond the agenda. Stir Trek also organizes a MEGA FOOD DRIVE to support local food banks and supports the Stir Scholarship, which provides support for women in Computer Science programs.

For Microsoft MVPs, that combination of technical learning, community connection, and service makes Stir Trek a natural place to show up, share knowledge, and help others take their next step.

Stir Trek attendees in the movie theater lobby

Why MVPs Show Up

This year, MVP speakers including Steve Smith, Barret Blake, Robert Fornal, Brian Gorman, Brian McKeiver, Cory House, Ed Charbeneau, Jay Harris, Joseph Guadagno, Matthew-Hope Eland, Sam Basu, and Samuel Gomez brought their expertise to the Stir Trek stage. Their sessions reflected what the MVP community does best: translate real-world experience into practical guidance that helps others learn, build, and grow.

For MVP Brian McKeiver, the chance to speak at Stir Trek was also a chance to meet technologists where they are right now. “What stood out to me at Stir Trek was the sheer curiosity that almost every person had this year about AI tooling like GitHub Copilot CLI and Microsoft Foundry because everyone is on the same learning curve,” he shared. “We are all trying to learn tips and tricks, best practices, and what not to do when building AI solutions.”

“Everyone is on the same learning curve.” - MVP Brian McKeiver

That focus on usefulness is part of what makes the event stand out. Stir Trek’s audience includes people across disciplines and experience levels, from software developers and engineers to designers, IT pros, tech leaders, and aspiring community contributors. For speakers, that means designing sessions that are approachable, relevant, and grounded in what practitioners can apply immediately.

MVP Brian McKeiver presenting at Stir Trek

MVP Robert Fornal brought that practical focus into his TypeScript session. “The session I brought to Stir Trek focused on TypeScript, which can be used right now, because I want developers to walk away with tangible improvements to their systems and processes,” he shared.

That curiosity reinforced the value of practical, community-led learning. It also showed why MVPs continue to invest their time in events where the audience is ready to engage deeply and learn together - even when showing up requires a significant personal commitment.

For MVP Joseph Guadagno, traveling from Arizona to Ohio to speak at Stir Trek was worth it because of the chance to connect with technologists from a different part of the country. “I get to meet technology people from a different part of the country which generally means different viewpoints and problems that need to be solved,” he shared. “The community impact I hoped to make was to further grow people. I hoped to at least meet and connect to one new person, which I did.”

A Conference That Feels Different

The movie-theater setting gives Stir Trek a character all its own. Instead of moving through a traditional conference center, attendees spend the day learning in theaters, connecting in shared spaces, and ending the experience together with a film. It creates a rhythm that feels both focused and fun.

Brian also pointed to the event’s unique rhythm. “The mix of technical sessions, hallway conversations, and a shared movie experience creates a community experience that really is unmatched,” he said. “Stir Trek is and always has been a pretty unique conference. The sense of overall community is very strong there.”

“The blend of technical sessions, hallway conversations, and a movie screening creates a community experience that really is unmatched.”

- MVP Brian McKeiver

That difference matters. The event is memorable not only because of the sessions, but because the structure invites people to stay, talk, laugh, learn, and participate in something shared. It lowers barriers, makes room for connection, and reminds attendees that community can be both purposeful and playful.

MVP Robert Fornal presenting at Stir Trek

For Robert Fornal, the format helps keep the focus on learning. “Stir Trek feels different from other technical conferences because of its unique theater environment and focused selection of high-quality presentations,” he said. “The movie-theater format changes the energy of the day by focusing the time on the presentation.”

“The movie theater snack that best captures the spirit of Stir Trek is trail mix, because it has a little bit of everything.” - MVP Kevin Griffin

The Community Work Behind the Curtain

Stir Trek is also a reminder that great community events do not happen by accident. MVP organizers and community leaders help create the conditions that make the day work - from program planning and speaker coordination to attendee experience and the details that make the event feel welcoming.

For organizers like MVP Kevin Griffin and MVP Carey Payette, the work reflects the same community-first mindset that defines the MVP Program. As Carey shared, one lesson from organizing Stir Trek is that accessibility goes beyond ticket price or session variety. “It is about creating a relaxed, friendly environment where people feel comfortable learning, connecting, and participating at whatever stage of their career they are in,” she said. “Stir Trek aims to keep prices low (budget cuts are very real in the tech industry) and offers scholarship tickets for students and the unemployed.”

The giving component is central to that mission. Through its annual MEGA FOOD DRIVE and the Stir Scholarship, Stir Trek connects technical learning with tangible community impact. In 2023, attendees donated more than 1,400 pounds of food, and the scholarship program has awarded more than $87,000 to support women in Computer Science programs.

The organizers and volunteers behind Stir Trek - including MVPs Matthew-Hope Eland (second from left, front row), Samuel Gomez (third from left, front row), Carey Payette (right side, front row), Kevin Griffin (second from right, back row), and Steve Smith (right side, back row)

Carey also described the impact organizers hope to create beyond the day itself: “A moment from organizing Stir Trek that reminded me why this work matters was hearing that attendees went back to work excited about what they learned. It is even better when those stories include people making professional connections, finding jobs, volunteering year after year, or giving their first tech talk at Stir Trek. That kind of impact makes all the planning worthwhile and proves that you can, in fact, build community inside a movie theater.”

“You can, in fact, build community inside a movie theater.” — MVP Carey Payette

Advice for Future Speakers, Organizers, and Community Builders

For anyone hoping to get more involved - whether as a future speaker, volunteer, organizer, or attendee - the MVPs emphasized starting with contribution. Attend with curiosity. Ask questions. Share what you are learning. Look for gaps you can help fill. Community impact often begins with one practical step.

For organizers, the advice is similar: start with the people you want to serve. “If a community wanted to create its own tech or shared experience event, I would encourage them to invite the people they would like to see in that environment,” said Kevin Griffin. “A lot of the success of Stir Trek was from us personally reaching out to people that we knew would make Stir Trek an amazing experience.”

What They Took Home

Like the best community events, Stir Trek sends people home with more than notes from a session. It gives attendees new ideas, new connections, and a reminder that technical communities thrive when people keep showing up for one another.

Brian McKeiver said one moment he will remember is the curiosity attendees brought to conversations about AI tooling like GitHub Copilot CLI and Microsoft Foundry. That shared sense of learning reinforced one of Stir Trek’s strengths: people were not just attending sessions; they were comparing experiences, asking practical questions, and learning alongside one another.

That mix of practical learning, community care, and shared fun is what makes Stir Trek memorable - and what makes MVP participation so meaningful. Whether they are speaking, organizing, mentoring, or simply making room for someone new to join the conversation, MVPs help events like Stir Trek become more than a day on the calendar. They become a place where community grows.

Want to learn more about the MVP Program?

To find an MVP and learn more about the MVP Program visit the MVP Communities website and follow our updates on LinkedIn.

Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes — with time for questions, examples, and real conversations.

Full account lock (Error 0x80004005) on multiple devices and networks. Automated support fails.

johangiron — Thu, 11 Jun 2026 17:53:05 GMT

Greetings to the community and the Microsoft support team,

I am turning to this forum because the automated support system and bots keep me in a closed loop, preventing me from reaching a human agent to resolve a critical lockout on my account.

Currently, I am unable to sign in to my Xbox Live account under any circumstances. The system constantly throws the following error:

Error code: 0x80004005 Message: "We couldn't sign you in to Xbox Live. Sorry, something went wrong. Try again in a while."

As a technician, I have rigorously isolated the variables and can confirm the following to save time on diagnostics:

It is not a local hardware failure: The exact same error replicates when trying to sign in from my Xbox console, my PC, and the mobile app.

It is not a local connectivity (ISP) issue: I have tested this through my home Wi-Fi and different cellular data networks, getting the exact same access denial.

All diagnostics point to the failure being directly at the server level: a token generation issue with my profile, an invisible security lock, or an internal synchronization failure.

I kindly request that a Microsoft Agent or moderator send me a Private Message (DM) here so I can provide the affected email address and have this case escalated to Tier 2 support. I need the internal status of my profile to be checked.

My Xbox Gamertag is: #Non9969

I look forward to your help. Thank you very much.

Putting file-level archiving into practice with Microsoft 365 Archive and Syskit Point

Trent Green — Thu, 11 Jun 2026 17:50:00 GMT

Most Microsoft SharePoint sites don't go quiet all at once. They stay active, new files added, documents edited, teams collaborating, while years of completed projects, superseded drafts, and old reports accumulate quietly in the background. The site looks healthy. But when Microsoft 365 Copilot draws on that content to generate responses, it can surface outdated, redundant, and inactive files alongside current materials. This can result in noise.

Organizations that keep their active content clean can give Microsoft 365 Copilot a stronger signal to work with, and their teams a better experience acting on what it surfaces. Microsoft 365 Archive and Syskit Point can help you address stale content at the source and can offer a practical way to improve the reliability of what Copilot returns.

File-level archiving, now in public preview

In March, we extended the capabilities of Microsoft 365 Archive with the public preview of file-level archiving, which allows organizations to move individual SharePoint files and folders within active sites to a lower-cost storage tier. Once an administrator enables file-level archive for a site, any user with edit permissions can archive individual files while the rest of the site remains fully operational. When a file is needed again, it can be reactivated individually, with no reactivation fee.

Microsoft 365 Archive is designed to help organizations save money. It can help organizations save up to 75% compared to adding additional SharePoint storage. Archive is available on a pay-as-you-go basis, with charges applying only when a tenant has exceeded its included storage quota. (See the Microsoft 365 Archive pricing model for more information.)

Critically, archived files are removed from Copilot's active index. As a result, when you archive outdated content, it no longer competes with current material when Copilot generates responses, summarizes documents, or answers questions against organizational data.

Archived files retain their existing security settings, compliance protections, and metadata, including retention policies, sensitivity labels, and legal hold status, within the Microsoft 365 trust boundary. (See the Privacy, security, and compliance in Microsoft 365 Archive page for more information.)

Scaling file-level archive with Syskit Point

Knowing which files to archive is the step that often slows organizations down. A site might be in daily use but contain hundreds of files that haven't been accessed in years. Identifying them manually, across a large tenant, is not practical.

To help our customers with this step, providers like Syskit are integrating with Microsoft 365 Archive to bring file-level archiving into their solutions. Syskit Point, a platform for Microsoft 365 governance, added support for file-level archive on day one of the public preview. Syskit Point provides the identification and governance layer that makes the feature actionable at scale.

"We're thrilled to see partners like Syskit building data governance capabilities on top of the file-level Microsoft 365 Archive platform. Customers have told us how important this more surgical archive targeting is, and that scaled policy applications are just as important to realizing the value of file-level archive," said Brad Gussin, Principal Group Product Manager, Microsoft 365 Archive.

Syskit Point works across three stages:

Identify what's genuinely inactive. Syskit Point can surface stale files using both last-accessed date and last-modified date; a distinction that matters when identifying content that is genuinely cold versus content that is old but still referenced. This can allow IT teams to act with confidence rather than guesswork.

Reduce file size before archiving. SharePoint retains up to 500 versions of a file by default. Syskit Point allows administrators to trim version history before archiving, compounding the storage savings beyond what archiving alone delivers.

Maintain governance throughout. Admins can archive inactive SharePoint files to cold storage directly from the Storage Metrics report. Syskit Point can become the governance layer on top of Microsoft 365 Archive, handling the full file lifecycle: archive, restore, delete, in one place.

For organizations rolling out Microsoft 365 Copilot, the question is no longer just who has access to what; it's whether the content Copilot draws from is worth drawing from at all. File-level archive, paired with the right governance layer, can help IT teams solve that problem.

About Syskit Point

Syskit Point is a governance layer for Microsoft 365 built for organizations where losing control has real consequences. IT teams can use it to keep their Microsoft 365 environment under control, secure it against oversharing and data leakage, optimize storage and licensing costs, and roll out AI with confidence. Syskit offers one platform, Microsoft 365 coverage, no custom setup required.

Learn more at syskit.com.

Build a Knowledge Graph in Azure HorizonDB with AI Functions and Apache AGE

Aditi_Gupta — Thu, 11 Jun 2026 17:42:46 GMT

Knowledge graphs appear in every AI architecture diagram, every conference keynote and every AI strategy deck. Yet the most common question we hear from customers and engineers alike is: "What does a knowledge graph actually do for me?"

That is a fair question, and one worth answering clearly, because most teams already have a knowledge graph problem and do not realize it.

The connections your relational tables cannot surface

Picture this: five incident tickets land over a week. One says the auth service returned 503s after an API gateway update, which broke checkout. Another says the payment service lost connectivity to fraud detection through a DNS failure. A third says auth got rate-limited by that same API gateway after a config change.

Each ticket makes sense on its own. But no one in your postmortem can answer: "What upstream services most commonly trigger failures that reach checkout?" That question requires tracing relationships across tickets, teams, services, and root causes. Your relational tables store the facts. They do not store the connections between them. That is a knowledge graph problem.

What becomes queryable once you have a knowledge graph

Once you build a graph from those tickets, every node is an entity (a service, a team, an incident) and every edge is a relationship (CAUSED_FAILURE_IN, OPERATES_ON, INVOLVES). The graph does not just store data differently. It makes a new class of questions answerable:

What is the most common upstream cause of checkout failures?
Which team resolves the most cross-service incidents?
Show me every cascading failure chain that touched the payment service in the last 90 days.
What is the timeline of incidents involving the same shared service?

Each of these questions can be answered with a single Cypher query, without nested subqueries, recursive CTEs, or manually correlating data across spreadsheets.

Why graph-augmented RAG needs a knowledge graph first

Traditional RAG retrieves chunks of text by vector similarity. It works well when the answer lives in a single document. It falls apart when the answer requires connecting facts across multiple documents. Ask "does this contract conflict with existing obligations?" and vector search returns a relevant clause. But it cannot follow links across regions, obligation types, and counterparties to prove a real conflict.

Graph-augmented RAG combines vector search, semantic ranking, and graph traversal into one retrieval pipeline. The graph provides the structural context that vector search alone cannot: the actual chain of cause and effect, not just the five most similar paragraphs.

But here is the catch most people miss: you cannot run graph-augmented RAG without a knowledge graph. And building the graph has always been the hard part. That is exactly what the new tutorial solves.

Building a knowledge graph in five steps inside Azure HorizonDB

We published a hands-on tutorial on Microsoft Learn that takes you from raw incident tickets to a connected, queryable knowledge graph. No external NLP pipelines. No separate graph database. Just SQL.

Here is the pipeline:

Extract entities and relationships from unstructured text with azure_ai.extract(). The LLM parses services, teams, root causes, and relationship triples in one SQL call.
Deduplicate entities with azure_ai.generate() using structured JSON output. "API gateway," "api-gateway," and "the gateway service" collapse into one canonical node.
Load into an Apache AGE graph using Cypher MERGE in PL/pgSQL loops. The tutorial builds service nodes, team nodes, incident hub nodes, all six relationship types, and a timeline chain linking incidents chronologically.
Query with Cypher traversals. Variable-length path patterns like *1..3 trace cascading failure chains up to three hops deep.
Visualize results in the PostgreSQL extension for VS Code, which renders Cypher output as an interactive node-edge graph.

The tutorial walks through every SQL statement, explains the tricky parts (like why EXECUTE format() is needed for parameterized Cypher, and how CROSS JOIN LATERAL expands team-service pairs correctly), and shows the exact output at each step.

The same pipeline applied to any domain

The tutorial uses incident tickets to keep things concrete. But the pipeline applies to any domain:

Domain	Key Entities	Question It Answers
Contract intelligence	Parties, clauses, obligations	Does this new vendor contract conflict with existing obligations?
E-commerce product catalog	Products, categories, customers, orders	What do customers who bought X typically buy next?
Fraud detection	Accounts, transactions, devices, IP addresses	Which accounts are connected through shared devices and circular transfers?
Healthcare clinical data	Patients, medications, conditions, providers	Does this new prescription conflict with existing medications?
Codebase dependency analysis	Tables, functions, views, triggers	If I alter this table, which downstream views and functions break?
Supply chain	Suppliers, components, facilities	Which tier-2 suppliers are single points of failure?
Research knowledge base	Papers, authors, concepts	What evidence chain supports this treatment for condition X?
Data lineage and ETL	Sources, transformations, dashboards	If this source schema changes, which dashboards break?
Identity and access management	Users, groups, roles, resources	Which users have transitive access to production through nested groups?
Regulatory compliance	Regulations, controls, systems	If this regulation changes, which controls need updating?
Customer 360	Customers, interactions, campaigns	What sequence of touchpoints leads to churn for enterprise accounts?
Insurance claims	Claimants, policies, events, providers	Which claims share overlapping parties or event timelines?
M&A due diligence	Companies, IP assets, contracts, liabilities	What hidden liabilities are linked to this acquisition target?

In every case, the shape is the same: azure_ai.extract() discovers the entities, azure_ai.generate() deduplicates them, and AGE stores and traverses the graph.

Get started

Tutorial: Build a knowledge graph from unstructured text using AI Functions and Apache AGE
Knowledge graph enhanced search: Graph-augmented RAG patterns for Azure HorizonDB
Solution accelerators: GraphRAG Legal Research Copilot, GraphRAG with Docker and AI Agents

We would love to hear what you build. Share your feedback on the PostgreSQL Hub developer forum.

Thank you!

Anthropic Claude Purview Data Connector showing all users as Guests..

Jroth — Thu, 11 Jun 2026 17:34:07 GMT

It appears this connector is not mapping fields properly causing internal users to be mapped as "guests", and since prompts/data isn't maintained for guest users the connector is effectively not gathering anything but noise. Unlike the other data connectors, one cannot create field mappings. Also the app being named using the guid of Microsoft's own "dataassessments" service principal I don't think is intended either. Has anybody else experienced this? See below for an example.

Store update

Naresh72 — Thu, 11 Jun 2026 17:28:06 GMT

i get a blank without details about the update. should i update it or cancel it. i did all methods like reinstalling ms store and even clean install windows 11 pro, still the update shows blank. its 13.30 mb file update, and shows every time there is new update in store

DoH is now generally available on Windows DNS Server

JorgeCañas — Thu, 11 Jun 2026 17:27:51 GMT

Today, we’re excited to announce that DoH support for Windows DNS Server is generally available on Windows Server 2025 for client-to-server DNS traffic.

When we first introduced DNS over HTTPS (DoH) for Windows DNS Server in public preview, we described it as a Zero Trust upgrade to the foundation of enterprise networking. With general availability, organizations can now deploy encrypted and authenticated client-to-resolver DNS traffic directly within their existing on-premises DNS infrastructure. The goal is to help improve privacy, reduce spoofing risk, and advance Zero Trust DNS without requiring a new resolver architecture.

This release helps organizations secure one of the most critical, and traditionally exposed components of modern networks while preserving compatibility with existing enterprise DNS deployments.

Why DNS security matters more than ever

DNS remains at the heart of every network interaction: every application, every service, every workload depends on it. Yet historically, DNS traffic has been transmitted in the clear. This could expose sensitive query and response data to passive monitoring and traffic analysis, man‑in‑the‑middle attacks, and unauthorized inspection of user and system behavior.

As enterprise environments adopt Zero Trust architectures and face evolving regulatory requirements, securing DNS further is no longer optional; it’s foundational.

What DoH brings to Windows DNS Server

DNS over HTTPS changes how DNS traffic is transported. DNS encapsulates DNS queries and responses inside HTTPS, encrypted by TLS. With general availability, Windows DNS Server enables the following capabilities:

Capability	Value for organizations
Encrypted DNS (between client and server)	• DNS queries and responses are encrypted in transit using HTTPS. • Helps prevent eavesdropping and unauthorized inspection. • Helps protect DNS data from tampering while in transit.
Authentication	• TLS certificates help clients verify the identity of the DNS server. • Helps reduce the risk of spoofing and impersonation attacks.
Standards-based interoperability	• Built on the IETF DNS over HTTPS standard, RFC 8484. • Designed to work with modern RFC 8484-compliant clients, including Windows clients that support encrypted DNS.
Integration with existing infrastructure	• Runs within the Windows DNS Server role; no separate resolver is required. • Existing DNS resolution behavior remains unchanged. • Traditional unencrypted DNS can continue alongside DoH where required, supporting incremental adoption. • Traditional unencrypted DNS is used for DNS server to DNS server communication.

From preview to general availability: What’s changed

In our previews, we worked closely with private and public sector organizations to validate real-world deployments and evaluate the experience.

With general availability, this release is designed for production use and delivers several key benefits: enhanced stability and supportability, clearer deployment guidance, greater operational confidence, and improved alignment with enterprise security best practices and Zero Trust architectures.

This milestone reflects your feedback and validation across diverse enterprise environments.

Advancing towards Zero Trust DNS

DoH on Windows DNS Server isn’t just a feature, it’s part of a broader strategy to enable Zero Trust DNS across the Windows ecosystem.

Windows clients already support encrypted DNS. Now, Windows Server provides the on-premises resolver counterpart, enabling encrypted and authenticated DNS across endpoints and infrastructure.

This unified approach helps organizations establish a consistent security posture for name resolution without requiring external DNS services or an architectural redesign.

For many organizations, including U.S. federal agencies, this model also helps support certain requirements for encrypted DNS protocols between clients and resolvers.

For organizations aligning with U.S. federal guidance such as OMB M-22-09 or NIST Secure DNS Deployment Guide, this release supports encrypted DNS communication between clients and Windows DNS Server using standards-based protocols. While this release focuses on encrypting client-to-resolver communication, support for encrypted communication between Windows DNS Server and upstream DNS resolvers is planned for a future update. Together, these capabilities will help enable fully encrypted DNS resolution paths aligned with aspects of U.S. federal Zero Trust objectives.

What to expect operationally

Enabling DoH on Windows DNS Server introduces encrypted communication for supported clients over HTTPS while preserving compatibility with most existing DNS deployments.

Organizations can expect DoH traffic between DoH clients and Windows DNS Server to be encrypted via TLS, DNS queries to be transported as HTTPS requests, existing DNS functionality to continue operating as expected, and mixed environments, encrypted and traditional DNS, to be supported.

This allows organizations to adopt encrypted DNS incrementally, without disrupting existing workloads.

Getting started

DoH is available on Windows Server 2025 running the June 9, 2026 update (or newer)...

Recommended deployment flow:

Configure a trusted TLS certificate.
Enable DoH in the DNS Server service.
Configure supported clients to use the secure endpoint.

Consult our documentation for more details: Enable DNS over HTTPS in DNS Server.

Share your feedback and help shape future improvements

In addition to standard support channels, you can also submit feedback directly from Windows Server using Feedback Hub. It provides a streamlined way to report issues, suggest enhancements, and share deployment experiences with the Windows DNS Server product team.

Work toward a more secure foundation

DNS has long been one of the most critical and exposed protocols in enterprise networks. With DoH now generally available in Windows DNS Server, your organization can help secure that foundation further.

Consider bringing encrypted DNS into existing infrastructure today. You can help strengthen your organization’s security posture, better align with modern Zero Trust principles, and help protect sensitive network signals from exposure.

Your DNS Server software just got an upgrade, and now it’s ready for production.

Azure Monitor SLIs now Generally Available

Sokuma — Thu, 11 Jun 2026 17:18:29 GMT

Azure Monitor SLIs are now generally available

Service Level Indicators (SLIs) and Service Level Objectives (SLOs) in Azure Monitor are now generally available. Teams can now measure reliability based on customer experience, not just infrastructure signals.

SLI: A quantitative measure of how well an application or service is performing from the customer’s point of view.

SLO: A defined target for an SLI that represents how good or bad the SLI is over a given time-period. This is also referred to as a baseline in Azure Monitor.

Traditional monitoring shows what is happening across your systems, but not always what customers are experiencing. A service can be technically available and still feel unreliable because of latency, partial failures, or dependency issues. SLIs help close that gap by measuring reliability from the customer’s point of view.

With GA, Azure Monitor now brings SLI authoring, SLO tracking, error budgets, and burn rate–based alerting into one experience, helping teams focus on whether they are meeting the reliability their customers expect.

What Azure Monitor SLI helps you do

Azure Monitor SLI lets you measure availability and latency with either request-based or window-based evaluation methods.

In Azure Monitor, SLIs are defined at the Service Group level, which provides a logical representation of your application across multiple resources.

This gives teams a clearer view of application health, customer impact, and the signals that matter most.

SLIs continuously evaluate your service by using existing Azure Monitor metrics and store the resulting evaluations in your Azure Monitor Workspace.

Azure Monitor uses these SLI evaluations to power error budgets, burn rate visualization, and alerting. This helps teams spot reliability issues earlier and make better release and incident response decisions.

Get started

To get started, you’ll need:

A Service Group.
Application metrics flowing into an Azure Monitor Workspace, for example through Managed Prometheus or OpenTelemetry Collect and analyze OpenTelemetry data with Azure Monitor (Preview) - Azure Monitor | Microsoft Learn

Learn more here.

Summary Azure Monitor SLI helps teams measure customer experience, track reliability against clear targets, and respond sooner with error budgets and burn rate–based alerting.

Learn more in the product documentation and start defining SLIs for your services in Azure Monitor today.

Azure Monitor Metrics Export Generally Available

Sokuma — Thu, 11 Jun 2026 17:17:35 GMT

Today, we’re excited to announce the general availability of Azure Monitor Metrics Export using data collection rules (DCRs). A scalable, flexible way to continuously export platform metrics with dimensional fidelity, lower latency, and more control over what you send downstream.

Azure Monitor Metrics Export is configured through data collection rules and can route platform metrics to Azure Storage accounts, Azure Event Hubs, or Azure Log Analytics workspaces. Compared to diagnostic settings, DCR-based metrics export supports multidimensional metrics, metric-name filtering, and improved scalability for large environments.

Here are some of the key benefits of Azure Monitor Metrics Export:

Control what you export: You can export all supported metrics for a resource type or filter to specific metric names, helping reduce downstream volume and manage cost.
Preserve dimensional fidelity: The DCR-based metric export supports multidimensional metrics, making downstream analysis and correlation more meaningful.
Get faster export latency: End-to-end export latency is typically within about 3 minutes, improving time to insight for operational and analytics workflows.

With Azure Monitor Metrics Export, organizations can build more scalable observability pipelines, route metrics to the destinations that fit their architecture, and unlock richer analysis for operations, reporting, and integration scenarios.

What’s new in GA

With general availability, Azure Monitor Metrics Export offers a production-ready path to continuously stream supported platform metrics using data collection rules. Azure Monitor Metrics Export now covers 44 Azure regions, up from 12 regions previously. This expanded footprint helps more customers adopt DCR-based metrics export closer to where their resources run, improving rollout flexibility for global deployments.

Customers can export metrics to Azure Storage, Azure Event Hubs, or Azure Log Analytics, preserve metric dimensions, and filter by metric name to better control downstream volume and cost.

Learn more about metrics export using data collection rules.

We’re excited to make Azure Monitor Metrics Export generally available and look forward to seeing how customers use it to build more reliable, cost-conscious, and extensible monitoring solutions on Azure.

A deep dive into Azure Bastion session recording

juquint — Thu, 11 Jun 2026 19:38:25 GMT

If you’ve worked with Azure Bastion’s Premium SKU, you’ve likely encountered one of its most powerful security features: graphical session recording. Capturing RDP and SSH sessions end to end strengthens compliance, supports forensic investigations, and improves operational accountability. How you configure session recording can make a significant difference. It determines whether you must manage manual tokens and expiry settings or benefit from a low-maintenance experience.

With the recently announced Public Preview: Managed Identity support for graphical session recording, managing Bastion authentication credentials to store session recordings to a designated storage account is simpler and reduces manual work.

In this blog, we’ll explain the Azure Bastion session recording feature, show how to set it up, compare SAS URL and Managed Identity options for storage authentication, and outline why Managed Identity is a great choice for production and enterprise environments.

What Is Azure Bastion session recording?

Azure Bastion is Microsoft’s fully managed, browser-based RDP/SSH gateway that removes the need for a public IP on your VMs. With the Premium SKU, you get access to session recording, which records graphical activity for every RDP and SSH session and uploads it as a browser playable video within the Bastion resource → Session recordings blade.

This gives security teams:

An audit trail of admin and user interactions
Forensic evidence for incident response
Visibility into privileged access across your environment

Prerequisites

Before you can enable session recording, you need:

Requirement	Detail
Azure Bastion SKU	Premium (Developer, Basic, and Standard do not support this feature)
Storage Account	General Purpose v2, same Azure region as Bastion
Permissions	Owner or Contributor on the Bastion resource and Blob Data Reader permission on the storage account for users to access the recordings

The two configuration options

When you enable session recording, Azure Bastion needs a way to authenticate to your Storage Account to upload the recorded sessions. There are two options:

SAS URL
Managed Identity

Let’s look at how to set up each authentication option.

Option 1: SAS URL

How it works

A Shared Access Signature (SAS) is a URI that grants restricted, time-limited access to Azure Storage resources. When using this option for session recording:

You navigate to your Storage Account and generate a SAS URL token scoped to your container with at minimum Read, Create, Write, and List permissions.
You paste the resulting SAS URL into the Bastion session recording blade.
Bastion uses that URL to authenticate and write recordings to a storage container for every session.

Prerequisites

If you have not configured a storage account container for session recordings, visit Configure storage account container.
Ensure you have Session recording and SAS URL selected in Azure Bastion configuration settings.

Setup steps

Go to your Storage Account. In the left pane, expand Settings, then select Resource sharing (CORS).
Create a new policy under Blob service with the following values and save your changes at the top of the page.

Next go to your Storage Account → Data Storage → Containers → Choose your container → Select Shared access tokens under Settings
Under permissions drop down, select Read, Create, Write, and List. This is the minimum set of privileges required for session recording.
Define a start and expiry date and select generate the SAS token and URL.

Copy the Blob service SAS URL provided.
In your Bastion resource → Session recording → paste the SAS URL and select Upload.

New Azure Bastion sessions will now be recorded and available with the option for immediate playback.

The challenges of using SAS URLs at scale

🔴 Token expiry overhead: SAS tokens expire after a set period. Once a token expires, Bastion can no longer write recordings, which can silently interrupt your audit trail until someone detects the issue and generates a new token.

🔴 Token access risk: If a SAS URL is accidentally logged or shared, it grants write access to your storage account for anyone who has access to it.

🔴 No Entra ID identity: Because SAS tokens provide preauthorized access for a limited time, they bypass Entra RBAC capabilities entirely. This means they don’t benefit from Conditional Access policies restriction capabilities.

🔴 Manual rotation: Unlike secrets stored in Key Vault with automated rotation, SAS tokens require a human or a custom automation pipeline to regenerate and update the Bastion configuration on a regular cadence.

Option 2: Managed Identity

How it works

Azure Managed Identity is a feature of Microsoft Entra ID that provides Azure services with an automatically managed identity—no passwords, secrets, or tokens required. When Bastion is configured with a Managed Identity for session recording:

Bastion’s system-assigned (or user-assigned) managed identity authenticates to the Storage Account via Microsoft Entra ID tokens issued by the Entra ID platform.
RBAC controls what that identity can do. Specifically, it requires the Storage Blob Data Contributor role on the storage account.
Token issuance, refresh, and lifecycle are all handled automatically by Azure.

Setup Steps

Go to your Storage Account. In the left pane, expand Settings, then select Resource sharing (CORS).
Create a new policy under Blob service with the following values and save your changes at the top of the page.

Next navigate to Identity (Preview). In our example, we are using a System Assigned Managed Identity, so we toggle Status to On to enable the Managed Identity to be used by Bastion for session recordings. An object (principal) ID will be generated, which is the unique identifier of the managed identity resources that is registered with Microsoft Entra ID for authentication purposes.

Ensure you have Session recording and either System Assigned or User Assigned Managed Identity is selected in Azure Bastion configuration settings.

Select the container you would like to store session recordings to and validate Blob Container URI is correctly noted in the configuration and click Apply to perform the configuration changes on the Bastion host.

Now we need to allow RBAC permissions for the Managed Identity to store session recordings in our configured Storage Account and Container. Under Permissions select Azure role assignments.

Select Add role assignment (Preview) and a new blade will appear. Here, will choose our scope which is Storage, we select our subscription, and target our Storage Account under Resource category, and for Role we will need to choose Storage Blob Data Contributor for the role assignment. Proceed to click Save to see our new role assignment listed.

The setup and configuration is complete and Azure Bastion will now use the configured system-assigned managed identity to store session recordings on our Storage Container. Recordings can be found after a session in the Session recordings option under Settings.

Benefits of a Managed Identity

🔴 No credentials to manage: No need to worry about credentials leaking or needing rotation.

🔴 No risks of silent failures: SAS tokens can expire and stop recordings without warning. Managed Identity handles tokens automatically, so recording continues without issues.

🔴 Better security visibility: It’s part of Entra ID, so you can see it in access reviews and control it with proper permissions.

🔴 Compliance improvements: It uses a real identity that can be tracked and audited, which aligns better with security and compliance requirements.

Conclusion

Azure Bastion session recording is essential for organizations that need to monitor privileged access. Using Managed Identity for authentication helps protect against credential leaks and requires no ongoing maintenance after setup, compared to the SAS URL configuration option.

References

SharePoint @mentions limited to random users

lightuser — Thu, 11 Jun 2026 16:13:52 GMT

Hi everyone,

We are hitting a strange issue with SharePoint @mentions where an affected user can only tag themselves and a few random employees, instead of the actual members of the site. I’ve attached a screenshot of what they see when trying to tag colleagues.

The Details:

The Glitch: Typing @ only populates a tiny fraction of the directory (see screenshot). The affected user (Michael Drabek) can tag me and himself, but none of the other 14 active members of this 16-member SharePoint site.
Cross-Testing: Another user on that exact same shared site is able to tag Michael successfully, so his profile is discoverable to others—he just can't see them.
Environment: This happens identically on both the web browser and desktop apps.
Verified: Michael has the correct SharePoint site permissions and full Microsoft 365 licensing.

It feels like a hidden Entra or User Profile Service sync glitch rather than a standard permissions issue, as his directory lookup seems completely restricted.

Has anyone seen the person-picker index get broken like this for a single user? Any tips would be appreciated.

Thanks!

Reduce unnecessary internet exposure with Microsoft Defender

hadarshindler — Thu, 11 Jun 2026 16:00:00 GMT

In today’s threat landscape, internet exposure, i.e. devices that allow inbound connectivity from the public internet, continues to be a major vector for initial access and compromise. Devices that are exposed to the public internet can significantly increase an organization’s attack surface, making them prime targets for initial access, exploitation, and lateral movement.

However, not all internet-facing devices represent a security issue. Many are intentionally exposed to support business-critical scenarios such as hosting web applications, enabling remote access, or supporting communication services. The challenge for security teams is not just detecting internet-facing devices, but understanding why a device is exposed, whether that exposure is expected, and what action should be taken. That’s why we’re introducing a new security recommendation in Microsoft Defender that helps organizations identify, review, and reduce unnecessary internet exposure across their environment.

Understand your internet-facing exposure

This recommendation focuses specifically on devices that are accessible from the public internet, meaning they can receive inbound connections initiated from external sources, not devices that only use the internet for outbound communication.

Externally reachable assets are often the first point of entry for attackers, making this a critical signal for security prioritization.

Microsoft Defender identifies internet-facing devices based on signals that indicate external inbound reachability, including:

External scan telemetry identifying devices reachable from the public internet
Network telemetry showing inbound connections from external sources

By correlating these signals, Defender surfaces devices that are externally reachable.

Introducing internet-facing exposure assessment

A new recommendation in Microsoft Defender provides a centralized view of devices that are externally reachable from the public internet, helping you understand and manage exposure across your environment.

This assessment categorizes devices based on their exposure state:

Exposed devices: Devices that are reachable from the public internet and require review
Compliant devices: Devices that are not externally reachable, or where the internet exposure has been explicitly validated and accepted by the organization’s security team as intended
Not applicable devices: Devices that do not exhibit inbound internet exposure

From the recommendation view, you can:

Drill down into exposed devices and understand why they are reachable
Review context such as exposed services and connectivity
Explore device-level details to support investigation
Track exposure posture across your environment over time

Take action on your internet exposure

To access this recommendation in the Defender portal, navigate to Exposure management → Recommendations → Devices → Misconfigurations. Once Defender identifies internet-facing devices, it provides the context needed to review and take action.

Your action plan

1. Assess your exposure
Review the recommendation to understand which devices in your environment are externally reachable from the public internet and why they were classified as internet-facing.

2. Validate whether exposure is required
Determine if the inbound connectivity is expected for each device. Confirm business need and ownership before taking action.

3. Prioritize high-risk assets
Focus on critical servers or sensitive environments that are exposed to the internet, as they present the highest risk for initial access.

4. Reduce unnecessary exposure
Restrict or remove inbound connectivity where it is not required by closing exposed ports, removing public access, or moving services behind controlled access layers.

5. Track and maintain posture over time
Continuously monitor internet-facing devices to ensure unnecessary exposure is reduced and new exposure is validated as environments evolve.

FAQ

1. Which devices are currently supported?

This recommendation applies to supported Windows client and Windows Server devices. Supported versions include Windows 10, version 1607 and earlier; Windows 10, version 1809 and later; and Windows 11.

2. Why might there be differences between this recommendation and the Internet-facing filter in device inventory?

This recommendation reflects devices observed as internet-facing during the recommendation assessment window. Device exposure can change over time, and different Microsoft Defender experiences may refresh at different times.

As a result, temporary differences may occur between this recommendation and the Internet-facing filter in device inventory.

For the most current device-level view, use the Internet-facing filter in device inventory. If a device was recently remediated or its exposure recently changed, allow time for the recommendation status to refresh.

3. Could regular employee laptops or personal devices appear as internet-facing?

This recommendation evaluates supported devices onboarded to Microsoft Defender for Endpoint and focuses specifically on inbound internet reachability.

Typical internet usage, such as web browsing, generates outbound traffic and does not by itself classify a device as internet-facing.

Devices are identified as internet-facing only when they are externally reachable from the public internet.

As a result:

- Personal devices that are not onboarded to Microsoft Defender for Endpoint are not included in this assessment.
- Corporate laptops may appear as internet-facing if they are directly reachable from the internet, which may indicate an unintended network exposure or configuration issue.

Learn more

For additional guidance on investigating and managing internet-facing devices, see:

Learn how Defender identifies and maps externally reachable devices across your environment Discovering internet-facing devices using Microsoft Defender
Learn how to review and investigate internet-facing device exposure Investigate devices in Microsoft Defender
Learn more about Microsoft Secure Score for Devices in Microsoft Defender
To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Text Truncation in Access Report Controls

khippen — Thu, 11 Jun 2026 15:28:57 GMT

Around May 14, 2026, we began experiencing text truncation on the right side of text box controls in Access (Office 365) reports. Approximately 2–4 characters are cut off whenever font size is below 10pt. All reports in our environment are affected and the problem was not present prior to May 14.

We ruled out layout as a contributing factor by verifying page size, margins, report width, control dimensions, padding, and layering were all correctly set. No layout changes resolved the issue. The problem does not occur when font size is set to 10pt or higher, suggesting the update affected font metric calculations for small font sizes.

Steps taken without resolution include adjusting all report and control sizing properties, testing multiple default printer configurations including Microsoft Print to PDF and Adobe PDF, and verifying Windows display scaling was set to 100%.

If anyone has any solutions, please let me know! Thank you for your time.

What’s New in Notebooks | June 2026

ezrapark — Thu, 11 Jun 2026 15:03:45 GMT

Today, Copilot Notebooks is rolling out to more people across your team, making shared notebook collaboration broadly accessible in the Microsoft 365 Copilot app and OneNote.

Copilot Notebooks are available to Copilot Chat users

Previously only available to Microsoft 365 Copilot users, Copilot Notebooks is now rolling out to Copilot Chat users, giving more people across the team a shared place to gather project context, work from reference sources, and turn that information into helpful mind maps and learning tools in study guide.

This gives Copilot Chat users a powerful workspace for knowledge sharing and collaboration: they can add files — including Word documents, PowerPoint presentations, Excel worksheets, and Outlook emails — into a notebook, ask questions across those sources, and understand content through mind maps and learning tools in study guide.

In mixed-licensed teams, everyone can collaborate in the same notebook¹, while Microsoft 365 Copilot users can add premium sources and use premium AI capabilities, like advanced creation experiences.

Starting today, Copilot Chat users can explore Copilot Notebooks in the Microsoft 365 Copilot app and in OneNote².

Availability: Rolling out to Copilot Chat commercial and education users² starting today.

Learn more about Copilot Notebooks and this change in our Support documentation. For more information for education users², read the Copilot Notebooks in Education blog.

¹Copilot Chat users have limited sources per notebook, access to standard sources only, and standard access to chat.

²Only Copilot Notebooks in OneNote on web will be available to Copilot Chat (Basic) commercial customers at this time.

Review our previous blog about Copilot Notebooks

What’s New in Notebooks | May 2026 | Microsoft Community Hub

Issue with Teams Transcript Trigger in Power Automate / Copilot Studio

David-Leguem — Thu, 11 Jun 2026 14:20:13 GMT

Hey everyone,

I’m currently trying to automate the retrieval of my Microsoft Teams meeting transcripts using an automation flow (Power Automate / Copilot Studio / similar tools).

However, the trigger related to transcripts (e.g., “When a transcript is available”) doesn’t seem to work properly on my end.

Has anyone here successfully set this up?
Have you managed to use this trigger reliably?

I did find a workaround to retrieve the transcripts, but it’s clearly less optimal than using a native trigger.

Curious to hear if others have run into the same issue or found a better approach.

Thanks! 🙏

Real-Time Simulation with Ansys Discovery on Azure AMD Radeon V710 GPUs

Sunita_AZ0708 — Thu, 11 Jun 2026 14:09:17 GMT

Overview of Synopsys-Ansys Discovery

Ansys Discovery is an interactive engineering application that unifies 3D geometry modeling, real‑time simulation, and visual analysis into a single, immersive workspace. It is purpose‑built to accelerate early‑stage engineering exploration while maintaining continuity into high‑fidelity validation workflows.

Discovery enables engineers and designers to create, modify, simulate, and iterate on designs in real time, dramatically reducing the time required to assess design feasibility, physics behavior, and performance tradeoffs. Unlike traditional sequential CAD‑then‑simulation workflows, Discovery collapses these steps into a continuous feedback loop that supports faster decision‑making and more informed design outcomes.

Ansys Discovery is organized into three continuously accessible stages:

Model – Focused on direct 3D geometry creation and modification, without simulation overhead
Explore – Provides instant, real‑time simulation results using GPU‑accelerated meshing and solvers for rapid insight
Refine – Enables higher‑fidelity simulation using body‑fitted meshing and CPU/GPU solvers for design validation

Running Discovery on Azure extends these capabilities by enabling scalable, cloud-based engineering workflows.

Key benefits

Running Ansys Discovery on Azure provides a scalable, cloud-based platform for simulation-driven design with the following advantages:
Access high-performance engineering workstations from anywhere
Azure provides global access to GPU-enabled virtual machines, enabling engineers to run Discovery from any location without dependency on local hardware.
Engineers no longer need high-end local GPUs, as compute and visualization are delivered through Azure-hosted environments. This reduces hardware refresh cycles and IT overhead.
Azure NVads V710 v5 supports fractional GPU allocation (1/6 to full GPU), allowing organizations to right-size cost and performance based on workload requirements.
Discovery’s GPU-accelerated Explore mode benefits from Azure GPU infrastructure, enabling instant physics feedback and faster design iteration cycles.
CAD models, simulation results, and design artifacts can be stored in Azure Files or Azure NetApp Files, reducing data duplication and improving collaboration across teams.
Azure allows rapid provisioning and scaling of GPU resources to match peak design cycles or project demands.
Intellectual property remains within enterprise-managed Azure environments, with access controlled using Microsoft Entra ID and Azure security services.
Cloud-hosted Discovery environments enable geographically distributed teams to collaborate on shared designs with consistent performance and user experience.

To support these capabilities, Azure provides a reference architecture optimized for GPU-accelerated simulation.

Architecture

The architecture for running Ansys Discovery on Azure is designed to deliver interactive, GPU‑accelerated simulation in a scalable and cloud-native environment. As illustrated in the diagram, engineers connect to Azure-hosted virtual workstations powered by NVads V710 v5 GPUs, enabling real-time geometry modeling and simulation through remote visualization. Design data and simulation outputs are stored in shared cloud storage services such as Azure Files or Azure NetApp Files, ensuring consistency and accessibility across distributed teams. This setup allows users to seamlessly move between interactive exploration and higher-fidelity validation workflows, while benefiting from on-demand scaling, centralized security, and reduced dependency on local high-performance hardware.

Azure GPU SKU Mapping

Architectural Mapping Overview

Ansys Discovery workloads on Azure naturally align to two primary GPU VM categories:

Graphics‑optimized, fractional GPU -> Design exploration
Full‑GPU -> Design Refinement

This mapping enables right‑sizing of cost, performance, and user experience on the following recommended Azure VM Series.

Azure NVads V710 v5series
NVads V710 v5 VMs are designed for graphics‑intensive, interactive workloads and provide:
- AMD Radeon™ Pro V710 GPUs
- Fractional GPU support (1⁄6 → full GPU)
- Cost‑optimized GPU visualization
- High‑frame‑rate remote graphics
- No additional GPU licensing required
These characteristics align directly with Discovery’s real‑time, GPU‑accelerated Explore mode, where instant feedback matters more than absolute solver depth.
Typical Discovery Workloads on NVads V710 v5
- Interactive geometry creation and modification
- Real‑time physics feedback in Explore mode
- Concept‑level CFD, structural, and thermal studies
- Design review sessions and rapid iteration loops
Early‑stage topology and shape experimentation

Recommended Sizes (Right‑Sizing Guidance)

Discovery Use Case	Azure VM Size	GPU Allocation
Single engineer, light models	Standard_NV4ads_V710_v5	1⁄6 GPU
Moderate assemblies, daily use	Standard_NV8ads_V710_v5	1⁄3 GPU
Large CAD models, advanced explore	Standard_NV12ads_V710_v5	1⁄2 GPU
Power users, complex scenes	Standard_NV24ads_V710_v5	Full GPU

Test Scenarios:

Test Name	Simulation Analysis Type
External Aerodynamics Test 2	Fluid
Internal Flow Test 1	Fluid
Internal Flow Test 2	Fluid
Internal Flow Test 3	Fluid
Heat Transfer Test 1	Thermal
Conjugate Heat Transfer Test 1	Fluid-Thermal
Conjugate Heat Transfer Test 2	Fluid-Thermal
Static Structural Test 1	Structural
Static Structural Test 2	Structural
Static Structural Assembly Test 1	Structural
Static Structural Assembly Test 2	Structural
Natural Frequency Test 1	Modal
Natural Frequency Test 2	Modal

Result Table:

Test Name	Solve Time (s)	Element Count	Test Result
External Aerodynamics Test 2	47.68	1.44E+06	Pass
Internal Flow Test 1	26.70	7.90E+05	Pass
Internal Flow Test 2	9.34	9.64E+05	Pass
Internal Flow Test 3	18.00	1.39E+06	Pass
Heat Transfer Test 1	4.55	2.51E+06	Pass
Conjugate Heat Transfer Test 1	12.34	1.34E+06	Pass
Conjugate Heat Transfer Test 2	30.89	1.54E+06	Pass
Static Structural Test 1	4.76	3.06E+06	Pass
Static Structural Test 2	4.78	3.04E+06	Pass
Static Structural Assembly Test 1	12.98	2.97E+06	Pass
Static Structural Assembly Test 2	14.16	1.88E+06	Pass
Natural Frequency Test 1	36.04	1.45E+06	Pass
Natural Frequency Test 2	16.10	1.11E+06	Pass

These results demonstrate consistent performance across fluid, thermal, and structural simulations, with sub-minute solve times even for multi-million element models.

Conclusion:

The validation confirms that Azure NVads V710 v5 delivers consistent, scalable performance across diverse simulation workloads. With fractional GPU flexibility and strong visualization capabilities, it enables organizations to adopt real-time simulation without overprovisioning infrastructure.

All workloads successfully passed, demonstrating consistent performance across simulation types. Importantly, we’re seeing rapid solve times even at multi-million element scale, which reinforces the ability to use Discovery for real-time engineering exploration at enterprise level. Azure NVads V710 v5 is uniquely optimized for Discovery’s real-time simulation workflows. It provides GPU acceleration tuned for interactive engineering, not just batch compute.

The fractional GPU model allows organizations to right-size cost and performance based on user needs—from individual engineers to power users. This ensures maximum flexibility while maintaining high-quality visualization and responsiveness.

What to Do When You Hit Capacity in Azure Databricks: Engage, Mitigate, Plan!

Rafia_Aqil — Thu, 11 Jun 2026 18:53:37 GMT

Microsoft's Cloud Architects: Paul Singh PaulSingh, Eduardo Dos Santos eduardomdossantos, Chris Walk cwalk, Peter Lo PeterLo, Tim Orentlikher tim_orentlikher, Ajmal Hossain ajmalhossain, Chris Haynes Chris_Haynes, and Rafia Aqil Rafia_Aqil

Start Here: Engage Microsoft

Capacity constraints in Azure Databricks are not an Azure Databricks product issue. Azure Databricks does not own or reserve compute, it dynamically provisions VMs from Azure when clusters are created or scaled. This means cluster creation, autoscaling, or job execution can stall when the underlying VM SKUs are constrained at the regional level. The fastest path to resolution is a structured conversation with your Microsoft account team, who can engage the Azure capacity intake process on your behalf.

Create a Quota Support Ticket via Microsoft Support and bring the following to your account team with your Support Ticket Number. Each field maps directly to what capacity intake teams will ask for: missing fields slow the request.

What to Prepare Before You Reach Out Your Account Team

Field	What Capacity Intake Needs	Example
Subscription IDs	The exact Azure subscriptions that will host the workspaces and clusters	7ebee83d-7923-426c-8449-59fd4dff25ab
Region(s)	Primary region, plus any acceptable alternates	East US 2
VM family / SKU	Specific series and version requested	Eadsv5, ESv4, DSv4, DSv2
Core count / new limit	Total vCPU or core count per SKU	10,000 cores for Eadsv5
Workload characteristic	CPU-bound vs. memory/shuffle-heavy vs. IO-heavy; batch vs. streaming vs. SQL	“Memory-intensive ETL with large joins and shuffles”
Scale and timing	When you need it, ramp profile, peak vs. steady state	“Need by month-end; ramp from 2,000 to 9,650 cores over Q3”
Business context	Business use case	“Migration off AWS”

What “Capacity” Really Means: A Layered Mental Model

Before diving into fixes, it is important to understand what is actually happening behind the scenes. Capacity constraints can occur at three distinct layers, and solving them requires addressing each one.

Layer 1: Azure Infrastructure

This is the layer most teams underestimate. Capacity here is governed by:

VM SKU availability in the region. D-series and E-series: the two most common Databricks worker families: have repeatedly hit capacity constraints across multiple Azure regions, causing cluster creation failures, autoscale stalls, and provisioning delays.

Regional supply constraints, which are dynamic and shared across all Azure tenants.

vCPU quotas and limits per subscription, which are separate from regional supply. Quota is your subscription’s limit to deploy resources (like a credit card limit); regional capacity is the underlying infrastructure available. Both must be sufficient.

Layer 2: Azure Databricks Platform

The Azure Databricks control plane has its own published ceilings that your architecture must proactively respect. Key limits from the official Azure Databricks resource limits documentation:

Resource	Limit	Scope
Jobs created per hour	10,000	Workspace
Tasks running simultaneously	2,000	Workspace (Run Job and For Each parent tasks excluded)
Parent tasks running simultaneously (Run Job / For Each)	750	Workspace
SQL warehouses	1,000	Workspace
Attached notebooks or execution contexts	145	Cluster
Virtual machines	25,000	Per subscription per region

Note: For limits marked as non-fixed in the official documentation, you can request an increase through your Azure Databricks account team. Reference: https://learn.microsoft.com/en-us/azure/databricks/resources/limits

Layer 3: Workload (Spark Execution)

Even when both lower layers cooperate, Spark’s own execution model can produce capacity-like symptoms:

Parallelism and task distribution, which dictate how many cores a job can usefully consume.

Memory pressure from joins, shuffles, and skewed keys.

IO demand and caching behavior, including Delta cache effectiveness and Spark cache misuse.

Understanding these layers is critical. Retries sometimes succeed because capacity is dynamic: as other workloads complete, nodes are released back to Azure and briefly become available.

Recognizing When You’ve Hit Capacity

Capacity issues rarely present as a single clean error. Instead, they appear as inconsistent behaviors:

Clusters stuck in Pending state

Autoscaling fails or never reaches the desired size

Jobs intermittently fail to start

Retry attempts sometimes succeed

These inconsistencies occur because capacity is shared across Azure tenants and fluctuates throughout the day. Running workloads outside peak business hours in the impacted region’s time zone is one of the most effective short-term mitigations.

Immediate Actions: How to Unblock Your Workloads

When you are actively hitting capacity constraints, speed matters. Please reach out to your Microsoft Account team and try these mitigations that are ordered from quickest to most involved.

Retry and Run During Off-Peak Hours

Capacity availability changes throughout the day as workloads complete and release VMs. Running outside peak business hours for the impacted region significantly improves success rates.

Switch VM SKU or Family

If a specific VM SKU is constrained, switching to another can immediately unblock provisioning.

Move within the same family (for example, DSv4 → DSv5)

Or switch families entirely (for example, D-series → F-series or L-series)

This is one of the most effective but often underused approaches. Also,

Choosing the Right VM Family

Most Databricks environments default to D-series (general purpose) and E-series (memory optimized). These are also the most heavily used and most capacity-constrained VM families. Consider alternatives based on your workload:

VM Family	Best For	When to Use	Trade-off
D-series	General workloads	Default choice	Often constrained in high-demand regions
E-series	Memory-heavy Spark jobs	Joins, shuffles, analytics	High demand; higher cost
F-series	CPU-intensive jobs	Parsing, transformations	Lower memory per core
L-series	IO-heavy workloads	Delta caching, large datasets	Higher cost; large local NVMe

Practical decision framework:

Memory-bound workloads (joins, shuffles): Move from E-series to L-series. Similar memory per core, plus large local NVMe for Delta caching.

CPU-bound workloads: Move from D-series to F-series. Higher CPU performance at lower cost.

IO-heavy or cache-sensitive workloads: L-series can significantly improve performance and reduce shuffle pressure.

Designing a single VM family is one of the biggest production risks in Azure Databricks environments.

Implement Regional Diversity in your Databricks workload

As Azure capacity constraints are region- and SKU-specific, it is important to build architectural flexibility into your Databricks deployments.

For critical or large-scale workloads, consider deploying multiple Databricks workspaces across different Azure regions to reduce dependency on any single region’s capacity.

This approach enables:

improved resilience to regional capacity constraints

greater flexibility in workload placement

Important: Multi-region deployment requires deliberate architecture, including deploying separate workspaces and replicating data and configurations across regions—it is not automatic.

Why Adding More Nodes Is Not Always the Answer

When jobs slow down, the instinct is to scale compute. With Spark, more nodes do not always solve the problem.

Common workload issues that masquerade as capacity problems:

Data skew

Excessive shuffle operations

Inefficient partitioning

Overuse of UDFs

In real workloads, shuffle operations can grow significantly larger than input data, placing heavy pressure on both compute and memory that more nodes cannot relieve.

Smarter optimization strategies:

Reduce shuffle through repartitioning and query optimization

Enable Photon for faster execution

Optimize Delta tables using Z-ordering and compaction

Leverage caching strategically (not just Spark cache: use the Delta/disk cache)

These optimizations can reduce your dependency on scarce VM capacity altogether.

What to Do When Your Capacity Is Approved

Once Azure approves your capacity request, retaining it requires active steps. Because Azure capacity is dynamic and shared, approved capacity is held only while compute remains actively deployed and running. This is especially important in highly constrained regions. Microsoft recommends the following:

Configure an Instance Pool

For workloads that cannot yet use serverless compute, configure an Azure Databricks Instance Pool with a minimum number of idle nodes aligned to your production requirements.

An instance pool pre-allocates and maintains a set of idle, ready-to-use VM instances. When a cluster is created from the pool, it draws from these warm nodes: eliminating the need to request new VMs from the regional Azure capacity pool between job runs.

Key behaviors:

The pool holds a minimum number of nodes continuously, keeping them warm and immediately available.

Clusters attached to the pool pull from warm nodes, avoiding re-acquisition from Azure between runs.

No DBU charges apply while nodes are idle in the pool.

Azure VM infrastructure costs do apply for all minimum idle instances. Size the pool conservatively: aligned to production need only: to balance capacity retention against ongoing cost.

Important: Instance pools hold idle nodes on a best-effort basis. Periodic platform events can recycle pool nodes, briefly causing the pool to fall below its configured minimum idle count while Azure re-acquires replacement nodes. Pools significantly improve availability and startup latency, but they do not change the fact that the underlying VMs are still requested from Azure on demand. They are not a hard reservation.

Reference: https://learn.microsoft.com/en-us/azure/databricks/compute/pools

Designing for Resilience: Long-Term Best Practices

To avoid repeated capacity issues, your architecture needs to evolve beyond reactive mitigations.

Plan for Capacity Early

Understand VM quotas and limits before you need them: not after a constraint occurs.

Avoid designing a single SKU. Build flexibility into cluster configurations so you can switch families without re-engineering jobs.

Standardize Compute Configurations

Consistent, policy-driven environments make it easier to adapt when capacity constraints occur. Use Databricks Cluster Policies to constrain cluster creation to approved, available VM families: this prevents teams from inadvertently requesting constrained SKUs.

Move Toward Serverless Where Possible

Serverless compute abstracts capacity management away from the customer. As the Databricks platform expands serverless support, migrating eligible workloads is the most durable long-term strategy. Azure continues to expand infrastructure capacity, but there are no guaranteed timelines for relief in constrained regions.

Note: If your workload supports serverless compute, Databricks recommends using serverless compute instead of pools or classic VM-backed clusters. Serverless removes dependency on specific VM SKUs and regional capacity: scaling is managed by the platform with significantly improved availability. Reference: https://learn.microsoft.com/en-us/azure/databricks/serverless-compute. For eligible workloads: including Databricks Jobs (automated workflows), Databricks SQL Warehouses, and Delta Live Tables: serverless compute eliminates VM SKU dependency entirely. Configuration guidance is available in the Azure Databricks deployment guide, Development Section, Step 9.

Multi-Region Strategy for Critical Workloads

For the most critical workloads, evaluate a multi-region deployment as part of your business's continuity planning. This is a significant architectural investment: see the FAQ for the full scope: but it is the only approach that provides true regional redundancy. Coordinate this with your Microsoft account team.

Reference: Azure Databricks & Microsoft Fabric Disaster Recovery: The Complete Better‑Together Strategy for Cloud Architects

Final Takeaways

Capacity issues are infrastructure-level constraints, not Databricks product failures

VM family selection is critical: do not rely solely on D-series and E-series

Workload optimization can reduce dependency on scarce resources before requesting more capacity

Serverless compute is Microsoft’s preferred long-term recommendation for eligible workloads

Azure On-Demand Capacity Reservations provide guaranteed capacity for mission-critical scenarios: distinct from instance pools (best-effort) and Reserved Instances (billing discount only)

Architectural flexibility: multi-SKU, multi-region awareness is your best defense against future constraints

FAQ

Why do retries work?

Capacity in Azure regions is shared across all tenants and fluctuates throughout the day as workloads complete and release VMs. A retry succeeds when capacity temporarily frees up. Retrying during off-peak hours improves success rates significantly.

Why does capacity fluctuate during the day?

Capacity is a function of regional supply and concurrent demand. As workloads complete, nodes are released back to Azure. Peak business hours in the impacted region’s time zone tend to be the tightest windows.

Why are instance pools not a hard reservation?

Pools hold a minimum number of nodes on a best-effort basis. Periodic platform events recycle pool nodes, so a pool can briefly fall below its configured minimum idle count while Azure re-acquires replacement nodes. Setting minimum idle to 0 avoids paying for idle VMs at the cost of slower acquisition time. Pools significantly improve availability and startup latency but do not guarantee capacity at the Azure infrastructure level.

Why does serverless behave differently from classic clusters?

Serverless compute removes customer control over individual VM SKUs. Databricks manages the underlying capacity across a shared pool. SKU-swap and pool-based mitigations do not apply. Customer-side levers reduce to retry and off-peak scheduling. The trade-off is that serverless is the simplest and most reliable option when the workload supports it.

Why is changing regions a last resort?

Region changes require redeployment of the Azure Databricks workspace and migration of all dependent artifacts: jobs, clusters, libraries, networking (private endpoints, VNet injection), Unity Catalog assignments, identities, and source data. The destination region must be validated for the same SKU and zonal configuration. For these reasons, region change should always be coordinated with the Microsoft account team and attempted only after preferred mitigations have been exhausted.

Why does VM family selection matter so much for capacity?

Different VM families have different supply curves. D-series and E-series are the most requested Databricks worker families and the ones most frequently constrained. Choosing a SKU based on whether the workload is memory/shuffle-heavy, CPU-bound, or IO-heavy improves both performance and the probability that capacity is available. The capacity team often steers customers toward newer-generation alternatives when supply differs by generation version.

What does the Microsoft account team actually do?

They route the request into the Azure capacity intake process, advise alternate SKUs and regions, surface zonal vs. regional considerations, and provide forward visibility into known constraints. The customer’s job is to bring a complete, accurate workload profile so the account team can advocate effectively.

It is also recommended to open an Azure Support ticket. This will save time later, as the capacity planning teams would like to track issues and requests via a support ticket. Once an Azure Support ticket is opened, the ticket number should be shared to the Microsoft Account Team, at a minimum to the Customer Success Account Manager (CSAM), if one is assigned to your organization.