New blog articles in Microsoft Community Hub

Built by experience: The journey to Azure Linux 4.0

poorvinarang — Wed, 21 Oct 2026 21:06:03 GMT

Azure Linux 4.0 builds on years of experience creating, operating, securing, and maintaining a Linux distribution for cloud-scale workloads. That journey began with CBL-Mariner, which emerged publicly in 2020 as Microsoft’s open-source Linux distribution for its cloud infrastructure and edge products and services. The distribution was built around a focused goal: provide a consistent, lightweight Linux foundation for Microsoft workloads.

Over time, the scope grew. The project became Azure Linux, and in May 2023 it became generally available to customers as a container host for Azure Kubernetes Service (AKS). That was an important step: technology developed through Microsoft’s own operating experience was now available as a supported option for customers running production Kubernetes workloads. Azure Linux 4.0 is the next step in that evolution. It brings the lessons accumulated across Microsoft and AKS scenarios to a broader audience as a general-purpose server distribution for Azure Virtual Machines and Virtual Machine Scale Sets, as well as a foundation for container images.

A distribution is more than a collection of packages

Building a distribution involves much more than assembling open-source packages. Every package introduces decisions: which version to carry, how it interacts with the rest of the system, how changes are validated, how security fixes are delivered, and how customers move forward without unnecessary disruption. As a distribution grows, so does the long-term responsibility attached to each of those choices.

Earlier Azure Linux releases were designed around focused Microsoft and container-host scenarios. Preparing Azure Linux for a broader range of customer workloads required a larger package ecosystem and a model that could remain sustainable as that ecosystem evolved. Azure Linux 4.0 uses Fedora Linux package sources as its upstream foundation, giving the team a coherent starting point, a mature RPM ecosystem, and an active open-source community.

Azure Linux curates that foundation for Azure server and container scenarios rather than simply reproducing Fedora. It builds its own packages and images, integrates with Azure, and maintains its own support and release policies. The result combines a strong and sustainable upstream foundation with deliberate choices for Azure workloads.

Stay close to upstream - and make differences clear

Every downstream difference carries an ongoing cost. The team must understand, test, maintain, and reconsider it as upstream evolves. Azure Linux 4.0 therefore stays close to Fedora where practical. When an Azure scenario requires a difference, the team documents and intentionally scopes that difference so it remains understandable, reviewable, and maintainable over time.

The same principle applies beyond package content. Azure Linux 4.0 increasingly uses familiar tools and practices from the Fedora and RPM ecosystems. This reduces the need for distribution-specific processes and makes the project more approachable to developers who already know that ecosystem. Staying close to upstream also strengthens our relationship with the open-source communities on which Azure Linux depends and helps us contribute broadly useful improvements wherever possible.

Balance stability with a modern cloud platform

Customers need a stable foundation, but they also need access to current cloud and developer capabilities. Hardware advances, security requirements change, and application runtimes introduce new supported versions. A lifecycle that is too short creates constant migration pressure, while one that is too rigid can leave customers waiting too long for important platform improvements. Our experience operating a distribution has taught us to treat predictability as a product feature.

Azure Linux 4.0 is designed around a deliberately balanced support lifecycle: long enough for customers to plan and operate with confidence, while allowing the platform to evolve at a cadence that fits modern cloud workloads. It includes four years of full support, and its maintenance model is intended to keep routine servicing conservative while placing more impactful package changes into planned, clearly communicated refresh windows.

Security updates and critical fixes continue throughout the lifecycle, while planned refreshes provide a clear path to newer capabilities and give customers time to prepare, test, and deploy changes. This model creates a dependable base without treating stability and progress as opposing goals.

Built for cloud workloads

Azure Linux is general purpose, but it is purposefully focused on server and cloud workloads. Customers can use the core image as-is or extend it for their applications, while its focused composition reduces unnecessary software and the security and maintenance surface that comes with it.

The same foundation can support multiple Azure deployment models. Customers can use Azure Linux 4.0 on individual virtual machines, scale it through Virtual Machine Scale Sets, or use Microsoft-maintained Azure Linux container images as a starting point for containerized applications. That consistency can simplify how teams approach images, packages, security baselines, and operations across VM and container environments.

From Microsoft’s workloads to yours

The Azure Linux team did not begin this journey by designing a distribution in the abstract. The distribution evolved through real operating experience across Microsoft’s cloud infrastructure, edge products and services, and AKS. Those experiences shaped the priorities behind Azure Linux 4.0:

Keep the base focused and reduce unnecessary components.

Treat security servicing as a continuous responsibility.

Make changes understandable and intentional.

Stay close to upstream to improve long-term maintainability.

Provide customers with a predictable lifecycle and refresh model.

Design for consistent use across server and container scenarios.

Make support part of the product experience rather than an afterthought.

Azure Linux 4.0 brings those lessons together for a broader customer audience. It is a Microsoft-built and supported Linux option, optimized for Azure and available at no additional operating-system charge beyond the underlying Azure compute.

It also remains one choice within the broad Linux ecosystem on Azure. Microsoft continues to work closely with established Linux distribution partners, and customers should choose the distribution that best fits their workload, ecosystem, and support needs.

The next chapter

With Azure Linux 4.0, we are bringing years of distribution engineering and operating experience to Azure customers in a new way. What began as a focused Linux foundation for Microsoft workloads expanded to a supported AKS container host and is now becoming a general-purpose option for Azure VMs, scale sets, and container images.

We are excited for customers to evaluate Azure Linux 4.0, tell us what works, and help shape what comes next. Azure Linux 4.0 is currently available in public preview for evaluation and testing.

Learn about Azure Linux 4.0

Deploy Azure Linux on Azure VMs and Virtual Machine Scale Sets

Explore the Azure Linux open-source project

Wolters Kluwer scales tax and accounting software with PostgreSQL on Azure

Pooja_Y — Wed, 21 Oct 2026 21:03:30 GMT

This blog was authored by Sven Hubert, Associate Director IT Operations at Wolters Kluwer, Oliver Heimlich, Lead Product Software Engineer at Wolters Kluwer, Volker Krebs, DevOps Engineer at Wolters Kluwer

As part of Wolters Kluwer, a global leader in professional information, software solutions, and services, Wolters Kluwer Tax & Accounting Germany develops software that helps tax advisory firms and midsize businesses streamline payroll, bookkeeping, banking, and tax compliance. With decades of experience, we are a leading technology partner in the industry's transition towards an integrated digital ecosystem.

More than 6,000 tax advisory firms and 14,000 midsize businesses rely on our solutions, which process 2.5 million payslips every month, 2.5 million tax returns annually, and support 15% of Germany’s annual financial statements.

All these applications run on PostgreSQL, but their data requirements vary significantly, from transactional accounting and dense payroll data to complex tax structures requiring frequent recalculation. At the same time, decades-long customer relationships mean years of historical data must remain readily accessible.

Combined, those demands have helped drive our PostgreSQL data from about 6 TB in early 2026 to nearly 10 TB by September 2026, and it's still roughly doubling every year. Keeping ahead of that kind of growth is what led us to adopt elastic clusters in Azure Database for PostgreSQL, enabling us to scale PostgreSQL horizontally as our data volumes and workloads continue to expand.

Looking for a more sustainable way to scale

Our PostgreSQL architecture has evolved as our business has grown. Before moving to Azure Database for PostgreSQL three years ago, we managed PostgreSQL ourselves on Azure infrastructure, which meant our team was responsible for server patching, backups, and day-to-day database operations. Azure Database for PostgreSQL gave us the managed platform-as-a-service (PaaS) model we wanted and reduced that operational burden.

But our data kept growing. Reaching 6 TB was not a hardware problem. We could still scale vertically with relatively little operational effort. The challenge was that the growing size of our datasets increasingly affected PostgreSQL's day-to-day operation. By that point, 42 tables exceeded 10 GB and several had grown beyond 100 GB. Larger tables and indexes made maintenance tasks, queries, updates, and retention-driven cleanup operations more expensive, and a single poorly performing query could impact the wider system.

Our engineers were manually creating or tuning indexes in production almost every week, consuming roughly half of one engineer's time, while peak memory usage approached 90%. We wanted to retain the managed experience of Azure Database for PostgreSQL while gaining the ability to scale horizontally. With our data continuing to roughly double each year, it became clear that we needed a more sustainable scaling model.

Finding a path to horizontal scale

Those requirements narrowed the field quickly. We wanted to stay on PostgreSQL so we could preserve our existing data-access layer and the time-based partitioning we'd already built with pg_partman. Any new solution also needed to run on Microsoft Azure and provide a managed PaaS experience rather than require us to manage the infrastructure ourselves.

Data residency requirements limited our options even further: we needed high availability and disaster recovery in multiple German regions.

We evaluated several options, running proof-of-concept tests on synthetic banking data. But it was hard to find one that supported development and CI testing without requiring a live cluster and was also available in two German regions.

When elastic clusters in Azure Database for PostgreSQL reached general availability in both Germany West Central and Germany North, we had our path forward. Elastic clusters use the Citus extension to turn PostgreSQL into a distributed database. It's still PostgreSQL, so scaling out is transparent to our applications, and we keep the managed-service model we already relied on. We also had a head start because our custom data-access layer was already sharding-aware from that earlier proof-of-concept work. The move meant extending a partitioning strategy we understood, not rewriting the application from scratch.

Getting that architecture right took longer than the cutover itself. Across roughly 400 tables, we decided which ones to distribute by tenant, which to replicate as reference tables, and which also needed pg_partman's time-based partitioning layered on top. That combination mattered because our data is both multi-tenant and long-lived, with some customers' records going back decades. We spent about three months on that design and cleanup work as well as continuous testing to ensure a smooth and short migration. The production migration itself ran over a single weekend earlier this year, when we used pgcopydb to move roughly 6.4 TB of data onto the new cluster.

What we learned as an early adopter

Working with elastic clusters at production scale taught us things we hadn't seen in smaller test environments, particularly around connection pooling. We hadn't used PgBouncer in our previous architecture, so we initially ran elastic clusters without it as well. But distributing and partitioning our data multiplied the number of shards, and in Citus, memory cost per connection scales with shard count. Adding PgBouncer reduced our physical connections to close to one-sixth of their previous level, helping us use cluster resources far more efficiently.

We also learned that the test environment has to match production exactly, not just the data but every configuration setting. We enabled high availability only after the production migration, and that surfaced an issue we hadn't seen in testing. Now we validate failover, health probes, and traffic routing with high availability enabled before making any changes to the cluster.

However, being early to the platform also meant we didn't have to work through issues like that on our own. We had direct access to the Azure Database for PostgreSQL product group throughout the project, beyond the standard support model. That relationship has become an ongoing feedback loop, where we bring current challenges and upcoming requirements to Microsoft's team, test new capabilities against our own environment, and help shape what matters most as the platform evolves.

Leaving weekly database troubleshooting behind

We went into this migration primarily looking for a more sustainable way to scale. What exceeded our expectations was the performance improvement we saw after the migration and the relatively short tuning and optimization work that followed.

Before the migration, some queries encountered multi-second I/O waits as the database grew larger. Since then, average statement execution time has stabilized below 20 milliseconds, and peak memory now stays consistently below 80%. The weekly cycle of hunting slow queries and hand-building new indexes has stopped completely. Long-standing performance tickets have been closed as "not reproducible," and work that had consumed close to half of one engineer's time now requires only occasional attention.

That shift means our engineers spend less time chasing the next database bottleneck and more time building the features our customers use. That matters on the development side, too: roughly 100 developers work against the databases across development, test, integration, and production, with around two dozen systems running at once. Once we'd proven the configuration in production, rolling it out across those environments was straightforward. We use the same Terraform provisioning scaled down to inexpensive single-node clusters, and a plain Citus Docker container for local work.

Preparing for the next doubling

Just as important, we now have room to keep scaling. The growth that took us from roughly 6 TB to nearly 10 TB hasn't slowed, and we don't expect it to. As that data grows, we need our applications to keep performing for the thousands of firms and businesses that rely on them every day. But for the first time, that expansion feels like something our architecture is designed for rather than something we're constantly reacting to.

Today, our production deployment of elastic clusters in Azure Database for PostgreSQL runs across six nodes. As data volumes continue to increase, we expect to add a seventh and eighth, testing the scale-out process against a restored production backup before applying it live. With elastic clusters, we can now scale both horizontally and vertically as our capacity needs change. And we're continuing to work with Microsoft on what comes next, from further optimizing connection pooling to major PostgreSQL version upgrades, as we prepare for the next doubling and the one after that.

SWOOP Analytics Festival 2026 | Viva Engage Edition

sarahLundy — Wed, 21 Oct 2026 20:28:30 GMT

Join internal communications and digital workplace professionals on Wednesday, November 11, 2026, for practical lessons and real-world stories at the free, live SWOOP Analytics Festival 2026 | Viva Engage Edition. The online event includes sessions for Asia Pacific (APAC), Europe, the Middle East, and Africa (EMEA), and the Americas (AMER).

Hear directly from organizations that use Viva Engage every day. They’ll share their experiences, challenges, experiments, and lessons learned, plus practical advice you can use in your own organization.

This year’s Festival will explore how Viva Engage, SharePoint, and Microsoft Teams work together. You’ll also get fresh insights from SWOOP Analytics’ latest benchmarking. Learn how communication intelligence connects insights across communication channels to help communicators make smarter decisions about their content, channels, and communities.

Choose the regional session that works for you

APAC | 12:00 PM–2:30 PM AEDT

Customer presenters:

Abi Banks, Zespri
Clara Antonello and Lauren Chan, AGL
Courtney Nuyad, AustralianSuper

EMEA | 9:00 AM–11:30 AM GMT / 10:00 AM–12:30 PM CET

Customer presenters:

Jed Saint and Sally Jackson, National Grid
Chloe Bloomfield and Ben Johnson, Arup
Tom Boden, Vestas

AMER | 9:00 AM–11:30 AM PT / 12:00 PM–2:30 PM ET

Customer presenters:

Brook-Lyn Lush, JJ Tardieu, and Scott Watson, Rio Tinto
Evan Krause, HCSC
John Alexander, Constellation Energy
Tai Collins, The Home Depot

Come ready to learn, ask questions, and swap ideas

Whether you want fresh ideas for Viva Engage, proven approaches from successful networks, or practical ways to connect your communication channels, you’ll leave the Festival with useful strategies for your organization.

Choose your regional session and register

Optimize selective analytics reads in Azure Data Lake Storage with ABFS Vectored Read

madhurinrao — Wed, 21 Oct 2026 20:01:19 GMT

ABFS Vectored Read helps compatible analytics engines reduce request overhead when reading selected portions of columnar files in Azure Data Lake Storage. By coordinating multiple noncontiguous byte ranges through the Azure Blob File System (ABFS) driver, it can combine nearby ranges into fewer storage requests and execute those requests asynchronously.

For data engineers working with selective Parquet queries, this brings the storage read pattern closer to what the query needs: a coordinated set of ranges rather than a collection of independent small reads. When the Parquet reader supports vectored I/O and the runtime includes a compatible ABFS client, Spark workloads that use higher-level APIs can enable this capability through configuration - without rewriting queries, changing application logic, or migrating data.

Why selective reads need coordinated I/O

Consider a query that selects a few columns from a Parquet dataset and filters out most row groups. The reader can skip much of the data the query doesn't need, but the data it needs may be spread across different parts of the file.

Reading each range independently can create many small storage requests. Each request carries network and processing overhead, so selecting less data doesn't necessarily remove the cost of coordinating those reads. Vectored Read lets a compatible reader provide the ranges together, giving the client an opportunity to plan the I/O as a group.

How ABFS Vectored Read works

A compatible reader submits the file ranges it needs together. ABFS validates and sorts the ranges, combines nearby ranges when appropriate, and divides the resulting work to fit its read buffers. It then queues the storage requests asynchronously and returns the requested bytes to the corresponding range buffers.

Illustrative request pattern, not a benchmark. Actual grouping depends on range layout and client configuration; coalesced storage requests can include bytes between the requested ranges.

This is a client-side optimization. It does not change the file format or rewrite your stored data. The engine still receives the data for the ranges it requested.

What this means for your workloads

For compatible selective-read workloads, Vectored Read offers:

Less request overhead: Combining nearby ranges can reduce separate storage requests and network round trips.
Coordinated I/O: Asynchronous reads allow the client to work on multiple requested ranges without treating every range as an isolated operation.
Configuration-based adoption: Compatible Spark workloads using the Hadoop Parquet and ABFS path can use the feature without rewriting their queries.

The best starting point is a workload that reads selected portions of Parquet files through abfs:// or abfss://. Full sequential scans may see less benefit, and engines that bypass the Hadoop/ABFS path do not use this capability. Support depends on the Hadoop, hadoop-azure, and parquet-hadoop libraries included in the runtime, not only on the Spark version. See Availability and resources for the minimum versions and verification guidance.

The benefit depends on the number, size, and spacing of requested ranges, the coalescing configuration, storage and network latency, concurrency and caching. Combining ranges can reduce requests and round trips, but it can also read additional bytes between noncontiguous requested ranges. Compare query duration, storage transactions, bytes read, and resource utilization against a controlled baseline using representative data and concurrency.

Get started

First, verify that your runtime contains Apache Hadoop 3.3.5 or later, including the hadoop-azure module, and parquet-hadoop 1.12.3 or later. The presence of an ABFS URI alone does not establish that the optimized implementation is installed.

For Spark, enable the Parquet setting before the application starts, using the spark.hadoop. prefix:

spark-submit \
--conf spark.hadoop.parquet.hadoop.vectored.io.enabled=true \
<other-options> \
<application>

Replace the command placeholders with your normal submission options and application. Set the property explicitly rather than relying on a default, which can vary by packaged Parquet version. For managed services, use the service's supported cluster or session configuration mechanism.

See the Microsoft Learn guide for the supported-version matrix, Hadoop configuration alternative, controlled before-and-after test, troubleshooting, and instructions to disable the feature.

Availability and resources

Azure Databricks does not currently support ABFS Vectored Read because its runtime ships an ABFS version that does not include this capability. In addition, Photon does not use the ABFS driver for data access, even when a workload uses an abfs:// or abfss:// URI. Therefore, the presence of an ABFS URI alone does not indicate that Vectored Read is available.

For other packaged or managed runtimes, verify that the environment includes Apache Hadoop 3.3.5 or later with the hadoop-azure module, and parquet-hadoop 1.12.3 or later.

Start with one representative selective-read workload and compare it with your baseline. For background, see the ABFS driver overview.

Build AI-powered apps without creating a vector database

spucelik — Wed, 21 Oct 2026 19:05:35 GMT

Developers building AI applications face a familiar challenge: how do you ground AI experiences in enterprise content while maintaining security, compliance, and governance?

You can use the Microsoft 365 Copilot Retrieval API for SharePoint Embedded, which helps you add Microsoft 365 Copilot and agent experiences to your SharePoint Embedded apps when you want to control the grounding step, the prompt, and the model yourself.

In addition, you can use the SharePoint Embedded Model Context Protocol (MCP) server, to build and manage apps with a coding agent.

Together, these capabilities can help developers move faster from application setup to AI-powered user experiences.

Build enterprise apps without creating a document platform

Microsoft SharePoint Embedded is becoming a governed content layer for AI-powered applications, with clearer production guidance. With this API-only solution, your team can focus on building the line-of-business and multitenant SaaS applications for enterprise content, without having to create a parallel content, collaboration, and compliance stack.

With SharePoint Embedded, content stays within Microsoft 365 under the tenant’s settings, including Microsoft Purview compliance controls (audit, eDiscovery, retention, data-loss prevention, sensitivity labels, and conditional access). Your applications inherit enterprise governance, meaning you don’t have to rebuild it. And if you’re building customer applications, you don’t have to take custody of your customer’s data.

Furthermore, SharePoint Embedded is a consumption-based pay-as-you-go offering through an Azure subscription, with no upfront commitment. As a result, you can choose the billing model that better meets your needs: 1) standard billing of the tenant that owns or develops the application, or 2) pass-through billing to the tenant registered to use the application.

Ground Copilot and agent experiences on enterprise content

SharePoint Embedded grounds AI agents on enterprise content while keeping that content and its compliance controls inside the customer’s Microsoft 365 tenant. There are two ways for you to build SharePoint Embedded agent experiences that let your app answer questions over files stored in SharePoint Embedded containers:

Microsoft Foundry Agent Service with a SharePoint knowledge source – for agents you build on Foundry. Foundry runs retrieval for you as part of the agent.

Microsoft 365 Copilot Retrieval API – for custom agents and apps that run their own grounding step. Call it from any app, including a Foundry agent that doesn’t use the SharePoint knowledge source.

Today, let’s focus on the Retrieval API, which enables applications to retrieve relevant passages from SharePoint Embedded content and use those results as grounding data for AI experiences. Developers maintain control over the prompt, orchestration flow, and model while relying on Microsoft 365 to handle retrieval across enterprise content.

Because the content stays within Microsoft 365, developers don’t need to build and maintain separate content indexing infrastructure. This means that you can skip building and maintaining a pipeline that extracts text, creates embeddings, stores them in vector database, and keeps permissions in sync – for the life of the application. Also, you don’t have to build access syncing, because the Retrieval API results are already trimmed to each user’s permissions.

Furthermore, Microsoft 365 Copilot licenses are not needed for every user who queries the Retrieval API, if at least one user in the tenant has a Microsoft 365 Copilot license. The licensed user(s) can initialize the semantic index.

Watch the SharePoint Embedded presentation from a recent Copilot, Microsoft 365 & Power Platform community call to learn more about the Retrieval API:

How the Retrieval API works

Using the Retrieval API, developers submit a query and specify sharePointEmbedded as the data source, with pay-as-you-go billing on the Copilot Studio message meter. After a user asks a question, your app calls the Retrieval API. The API returns relevant text extracts from content stored within SharePoint Embedded containers, and your app passes the text extracts to its own model as grounding data.

This gives developers flexibility to build custom copilots, domain-specific assistants, document intelligence solutions, and other AI-powered experiences while keeping content governance aligned with customer expectations.

For more information and guidance, see Use the Retrieval API.

Use natural language to build and manage apps with the Model Context Protocol server – now in public preview

While the Retrieval API helps developers create intelligent runtime experiences, we’re also making it easier to build SharePoint Embedded applications in the first place.

The SharePoint Embedded Model Context Protocol (MCP) server, now in public preview, enables you to build and manage apps with a coding agent. The open-source SharePoint Embedded MCP server npm package (@microsoft/spe-mcp) lets MCP-compatible AI clients, such as GitHub Copilot in Visual Studio Code or the CLI, Claude, Cursor, and Azure AI Foundry, provision and manage SharePoint Embedded applications through natural language.

The MCP server can help developers streamline the management of SharePoint applications, allowing for quicker setup and configuration through AI assistance. Instead of clicking through portals and stitching together Microsoft Graph and Azure CLI commands by hand, you can describe what you want, such as “create a trial container type for my app”, and let your coding agent invoke SharePoint Embedded tooling on your behalf.

The MCP server supports scenarios such as:

Creating and managing container types and containers

Provisioning SharePoint Embedded applications

Configuring billing

Uploading and managing content

Scaffolding reference applications

Searching documentation and learning resources

For more guidance and information, see Use the MCP server to build apps with a coding agent.

Start building

Whether you’re building a SaaS application, an industry-specific copilot, a document-driven workflow solution, or a custom AI assistant, SharePoint Embedded provides a foundation for combining enterprise content with modern AI experiences.

You can go from zero to a working AI app on your own content in an afternoon — no vector database and no separate search index to run.

The fastest way to start is to point your coding assistant at the SharePoint Embedded MCP Server (in preview) and let it scaffold a sample app for you. Run: npx @microsoft/spe-mcp and then ask it to create a SharePoint Embedded project and a sample app you can upload files to. It runs with pay-as-you-go billing, so there’s no upfront commitment.

Build your first grounded AI App

Once your app is set up, use the Microsoft 365 Copilot Retrieval API for SharePoint Embedded to start building grounded AI experiences today.

Want to learn more about SharePoint Embedded? Get started today at the task-based SharePoint Embedded documentation hub.

What happens when attackers get AI too?

Alexis_Tiacoh — Wed, 21 Oct 2026 18:47:03 GMT

ASK MICROSOFT ANYTHING

How AI-powered attacks happen: Real threat scenarios and the security controls that stop them

Tuesday, October 27 | 9:00–10:00 a.m. Pacific time | Virtual | LIVE

How might attackers use AI

Artificial intelligence is creating new questions for cybersecurity. Defenders are exploring AI to analyze large volumes of information, identify suspicious activity, support investigations, and assist response teams. Attackers may explore similar capabilities, raising questions about which activities AI could influence and where practical limits remain.

That leads to an interesting question: What changes when attackers have access to the same AI capabilities similar to those that defenders use? Microsoft security experts will be exploring this topic through realistic threat scenarios and a practical discussion of current capabilities and limits.

How might AI affect familiar attacker behavior

Many cyberattacks begin with research into a target. Attackers map out a target’s people, systems, identities, applications, and entry points. Then they test ideas, craft convincing communications, modify scripts, sift through information, and adapt when an approach fails. Those behaviors aren’t new. The question is whether AI could change their speed, scale, or required effort.

Rather than assume the answer, we’ll examine where AI assistance might, and might not, change the time, expertise, or manual effort involved in specific attacker activities. For example:

Could AI assistance change how attackers conduct reconnaissance? Could it affect the personalization of social engineering content?

How might attackers use AI to examine stolen or publicly available information?

Where can natural-language tools assist with creating, modifying, or troubleshooting scripts, and what are their limits?

Could AI change how attackers test and refine their approaches?

One significant effect may come from how several capabilities work together, rather than from any single one. What changes when they are combined, and where do practical limits remain?

What does an AI-powered attack actually look like

That’s where the conversation gets interesting. Does AI enable genuinely new attacks, or does it change the effort, cost, and reach of familiar ones?

We’ll look at which attack stages AI assistance might influence, where its limits remain, and what changes when AI systems receive tools and permissions to act with human oversight. Most importantly, we’ll discuss which security controls remain important as attacker methods evolve.

These questions are at the heart of our upcoming live AMA session: How AI-powered attacks happen: Real threat scenarios and security controls that stop them. We’ll examine realistic scenarios and discuss where AI may intersect with attacker behavior. Then we’ll open the conversation to you. This fully live session opens with a focused 25–30-minute presentation, followed by a live AMA for your scenarios, questions, and challenges.

Watch the session on the Microsoft Community Learning YouTube channel or the Microsoft Tech Community event page.

Bring us the hard questions

Maybe you’re wondering:

Where could AI assist parts of an attack, and what are its limits?

How might generative AI affect phishing and social engineering?

How should identity teams think about AI-assisted adversaries?

What risks should defenders consider when attackers combine multiple AI-assisted capabilities?

Which security controls deserve renewed attention as AI capabilities evolve?

How should defenders separate realistic AI threats from hype?

Or maybe your question is simply, "What aren’t we thinking about yet?”

The fundamentals still matter

The other side of this conversation may matter even more. AI could change what attackers attempt, how they perform some tasks, and the expertise or effort certain techniques require. Attacker workflows may evolve, but their objectives still involve identities, devices, applications, data, permissions, and security boundaries. That gives defenders a practical lens to apply established security knowledge to AI-assisted attacks, and test whether existing principles still hold across the attack lifecycle.

That’s the conversation we want to have.

Bring your scenarios.

Bring the thing your security team has been debating.

Post your questions on the Microsoft Tech Community event pageand join us live on October 27.

Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations

saikishor — Wed, 21 Oct 2026 19:11:53 GMT

Written in collaboration with yuvalpery and Gunjan Jain

Introduction

Today, two critical remote code execution (RCE) vulnerabilities were disclosed in PHP. We strongly recommend that customers upgrade to a patched version of PHP as soon as possible. Upgrading is the only way to fully remediate these vulnerabilities. Read more on the PHP official website.

Microsoft has been part of the coordinated industry response to these vulnerabilities, working alongside the PHP Foundation, Wiz, security researchers, and other industry partners to help protect customers. Azure Web Application Firewall (WAF) has developed mitigations against known exploitation patterns to provide an additional layer of protection while customers apply the PHP security updates. These protections intended to complement patching and are not a replacement for it.

About the vulnerabilities:

CVE-2026-109618 - RCE via OOM corruption
CVE-2026-109619- RCE via stale global state

Both vulnerabilities can be exploited over the network without privileges or user interaction, with a high potential impact on confidentiality, integrity, and availability.

The vulnerabilities relate to PHP handling of memory when a request terminates abnormally, for example due to memory exhaustion or a fatal error. Under certain conditions, improper memory handling could allow an attacker to achieve remote code execution.

Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35.

Refer to vendor guidancefor patching of different versions of PHP.

Recommended action: upgrade PHP

We recommend that customers:

Upgrade all PHP deployments to a patched version, including virtual machines, containers, base images, and platform runtimes. We suggest prioritizing internet-facing workloads.
Rebuild and redeploy container images that include their own PHP runtime, since updating the host does not update PHP inside an image.
Migrate to a supported PHP branch if the branch currently in use no longer receives security fixes.
Treat the Azure WAF mitigations below as a temporary, supplementary measure. They address a specific technique and do not remediate the underlying vulnerabilities.

Azure WAF protection

Request-side signals alone may not be sufficient to reliably identify certain exploitation attempts. Signals in the server response can provide additional evidence that malicious activity has occurred, enabling more targeted mitigation with higher confidence and lower false positive. For this vulnerability, Azure WAF identifies known malicious patterns in the session and removes the potentially malicious elements from the response before it reaches the client. This provides an additional layer of protection for supported exploitation scenarios, while patching PHP remains necessary to fully address the underlying vulnerability.

Azure Front Door WAF: managed rule

A managed rule to handle potential attack vector in response is currently rolling out for Azure Front Door WAF, expected to complete October 28. Customers who are unable to patch PHP immediately and require interim protection before the rollout completes, contact Microsoft Support to expedite enablement.

Once the rule is available, its details are as follows:

Rule group: MS-ThreatIntel-Response-CVEs

Rule ID: 99006001

Default state: disabled. Customers need to enable the rule.

Supported rulesets: DRS 2.0, 2.1 and 2.2. Unlike other WAF rules, this rule does not block or challenge any traffic. When the rule identifies malicious signals in the session that provides strong evidence of exploitation, it removes the potentially malicious elements from the response while leaving the remainder of the response unchanged. Mitigation for this rule takes effect only when the rule action is set to Block on anamoly. Please note that the response side mitigation does not generate WAF log entries or hit counts.

Application Gateway WAF: interim mitigation

Customers can apply an interim mitigation now using the HTTP header rewrite capability of Application Gateway, which is available on v2 SKUs. A WAF managed rule for Application Gateway is expected to roll out at a later date. Until then, we recommend the following rewrite rule:

1. Create a rewrite rule in a rewrite set associated with your routing rule(s).

2. Add a condition that evaluates the Set-Cookie response header against the following regular expression:

^PHPSESSID=(?:[a-zA-Z0-9\-]|%2[Cc])*(?:[^a-zA-Z0-9\-;%]|%(?!2[Cc]))+[a-zA-Z0-9\-]*[^;]+;

3. Set the action to delete the matching Set-Cookie response header. Alternatively, the header can be set to a replacement value of your choice. Please note that setting a value overwrites the entire header, including attributes such as Path=/;.

Additional considerations:

The rule applies only to a Set-Cookie header that matches the pattern. Other Set-Cookie headers in the same response are not affected.

We recommend validating the rule on a non-production gateway before broader deployment.

For further information, see Rewrite HTTP headers and URL with Azure Application Gateway.

Application Gateway for Containers (AGC):

For PHP workloads behind AGC, upgrading PHP is the recommended remediation. A WAF managed rule for AGC is expected to roll out at a later date.

Summary

Service	Available protection	Recommended action
Azure Front Door WAF	Managed rule 99006001 rolling out, expected to complete by 28 October 2026; mitigation using high confidence signals without blocking traffic	Upgrade PHP to a patched version. If you are unable to patch, contact Microsoft Support if the interim protection is needed before the rollout reaches your profile
Application Gateway WAF	Header rewrite mitigation available now; managed rule expected to roll out later	Upgrade PHP, to a patched version. If you are unable to patch, apply the rewrite rule in the interim
Application Gateway for Containers	Header rewrite not supported; managed rule expected to roll out later	Upgrade PHP to a patched version

Conclusion

Following PHP security guidance and upgrading to a patched version is the recommended and complete remediation. Azure WAF mitigations can help reduce exposure during the upgrade period, and we encourage customers to upgrades at the earliest opportunity.

Using PostgreSQL to reflect on its own history and code: introducing pghacker-mcp.dev

maxluk — Wed, 21 Oct 2026 20:23:40 GMT

By: Maxim Lukiyanov, PhD, Principal Software Engineer

Every feature in PostgreSQL has a story. Before a line of code lands, it's proposed, debated, reviewed and often rewritten on the pgsql-hackers mailing list, sometimes over years. That conversation has been going on in public since 1997, and its 645,000 messages hold the reasons behind most of PostgreSQL's design decisions.

It's one of the richest records of engineering knowledge I know of, and it's exactly the context AI agents need when they work on PostgreSQL or build on it. Agents can search the archive, but searching hundreds of thousands of messages takes them a long time, they can still miss the message that settled a question, and they have no map of how the facts connect: which thread led to which commit, which patch became which line of code, who argued for what, and what was finally decided.

So I built pghacker-mcp. It's a free, public Model Context Protocol (MCP) server that gives any AI agent the PostgreSQL community's design history and PostgreSQL's source code, every commit on every branch, connected in one knowledge graph, and it answers with citations you can check. There's no sign-in, and the whole project is open source. Fittingly, it's powered by PostgreSQL itself, running on Azure HorizonDB: PostgreSQL, the database, reflecting on PostgreSQL, the project.

With the PostgreSQL community gathering in Valencia for PGConf.EU 2026 this week, it felt like the right moment to share it. In this post, I'll show you what it can do, and then take you under the hood.

Ask PostgreSQL why

With pghacker-mcp connected, your agent can follow a feature from proposal to commit or revert, including the alternatives that were ruled out and why. It can also read, search and blame any version of PostgreSQL's code, back to the threads behind each line.

Every answer comes with citations to the messages, commits and lines of code behind it. For example, ask whether retrying a failed fsync() can lose data. Your agent will explain that it can, because on Linux a retried fsync() can report success after the first failure lost the data, and that in 2018 PostgreSQL chose to PANIC instead.

That's the real point of pghacker-mcp. Any agent can sound like it knows PostgreSQL's history. With pghacker-mcp, yours can show you where that history is written.

How it works

pghacker-mcp has three parts, built around one PostgreSQL database:

The indexer, written in Rust, loads new mail and commits every hour and keeps the commit history and the graph up to date.
Crawler agents, running on PilotSwarm, an open source durable runtime for agents from Microsoft, have read all 58,734 threads and recorded what each one decided: features, decisions and each author's positions, with verbatim quotes. Reading a 250-message debate and saying who argued what takes a language model, and it's what makes this project possible today.
The MCP server, also in Rust, is public, stateless and read-only, with 17 tools: familiar ones like grep, read_file and blame, thread search, and a query tool for SQL and Cypher.

PostgreSQL turned out to be a great code search engine

Agents ask about code across time: how a function looked in 2015, who wrote a line, or whether a fix reached the back branches. That means pghacker-mcp needs every version of PostgreSQL's code, searchable fast.

That's a bigger challenge than it sounds. PostgreSQL's history has 105,000 commits on 39 branches, and the tree at an average commit holds about 2.6 million lines. Checked out one by one, they would add up to more than 250 billion lines. On my laptop, git log -S fsync_fname, which finds the commits that changed uses of PostgreSQL's fsync helper, takes about 54 seconds to search the whole history, and running git grep on every commit would take about six hours.

So the commit history stores each version of a line just once, with the range of commits that contain it. The idea is older than git. It's how SCCS stored every version of a file as one weave of interleaved deltas in the 1970s, and it's how temporal databases record the period in which a row is valid, here measured in commits, not time.

The trick is in how commits are numbered. Every commit gets a 64-bit address: master's commits are spaced 2³² apart, and each branch numbers its commits in the gap right after the commit it forked from. PostgreSQL's history has no merge commits, so the descendants of any commit form one continuous range, much as in the nested set model for storing trees in SQL. "Is this line in commit X?" becomes a simple range test on the line's bounds:

lo <= X AND X < hi AND (alive IS NULL OR alive @> X)

The int8multirange column alive covers the one exception: lines deleted on one branch but kept on another. With this model, all 105,000 commits fit in 24 million line versions, 6.5 GB with indexes.

What surprised me is that PostgreSQL already had every tool this design needs. The bounds are plain bigint columns, the same half-open interval an int8range describes, and int8multirange handles the exceptions. A B-tree on each line's file and bounds, (lineage, hi, lo), narrows a search to the files and commit you asked about. And a GIN index with pg_trgm's gin_trgm_ops narrows a regular expression down to a few candidate lines, which PostgreSQL then checks exactly. That's the technique Russ Cox described in how Google Code Search worked, and pg_trgm has supported it since PostgreSQL 9.3, thanks to Alexander Korotkov.

Together, these indexes search the whole history far faster than local grep can, because grep has to scan every version of the tree, while PostgreSQL's indexes go straight to the few lines that can match. pghacker-mcp finds every line that ever contained fsync_fname in every one of 105,000 commits, in 50 milliseconds.

Trigrams carry most of the load. I studied how AI coding agents actually search code, and of 35,728 real grep calls from my own agent sessions, 91% could use a trigram index, including 98% of those that spanned a folder or a whole repository. Nearly all of the other 9% searched files the agent had already named, where PostgreSQL simply reads those few lines.

Just as important, grep works exactly as agents expect. They can send pghacker-mcp the same grep commands they already write, flags, pipes and all. Replayed against GNU grep, 7,254 real grep commands from my agent sessions returned exactly the same output, every one. Agents don't need to learn a new search language: grep just works, on every version of PostgreSQL.

Everything else this project needs runs in the same engine: BM25 ranking and vectors for the mail, and a graph for the links. One SQL query can join them all. I never needed a separate search engine, vector store or graph database. I chose PostgreSQL to store the code, and it turned out to be a great engine for searching it, too.

A knowledge graph from the mailing list to the code

Search finds text. But questions about design are about connections: which thread a commit came from, which patch first proposed a line, who argued for what, and what was decided. Relationships like these are natural to express as a graph, so pghacker-mcp keeps them in a knowledge graph, built with Apache AGE in the same database: about a million vertices, from authors and messages to files and commits, and four million edges between them.

The most important design decision was who creates which links. Links that are facts are made by deterministic code. The Discussion: link that committers add to commit messages, or a message that mentions the commit, connects a commit to its thread; there are more than 40,000 such links. Patches posted to the list are matched to the lines and commits they became. Judgments, like what a thread decided and where each author stood, come from the crawler agents, and each one must quote its messages exactly, or it's rejected.

Here's the fsync story again, this time starting from the code:

One blame call takes a line of PostgreSQL 19 to its 2018 commit and to the patch where it first appeared. The commit's Discussion: link leads to the thread, and the thread to its decision. Three tool calls, from today's code to the debate behind it.

Because these connections are stored rather than rediscovered on every question, your agent can also ask what no single thread can answer: which features a file implements, who argued for or against each of them, which commits changed the file, and which release each feature shipped in or targets.

Search tells you where something was said. The graph tells you how it all connects: why the code is the way it is, and who shaped it.

MCP is growing up fast

In the last year and a half alone, MCP gained elicitation, structured output, tasks and extensions, and the 2026-07-28 revision made it stateless: no sessions, no handshake, and every request carries the client's capabilities. For a public server like pghacker-mcp, that's a big deal, because any server instance can answer any request.

But what excites me most are two newer features that change what a server can offer, and pghacker-mcp uses both.

Skills: a server that teaches agents

Tools give an agent abilities; skills give it know-how. An Agent Skill is a SKILL.md file of instructions that teaches an agent a workflow. The new official skills extension for MCP lets a server publish skills next to its tools, so agents that connect can discover and load them.

pghacker-mcp publishes one skill, review-as-author. Give your agent a patch and the name of a pgsql-hackers regular, and it reviews the patch the way that person likely would: each point backed by a quote of their own, marked as a prediction, and, given a date, based only on what they had written by then.

Ask your agent to review the May 2022 patch set for logical replication of DDL as Tom Lane would have, and it predicts he'd push back on putting it into core, quoting his own 2012 warning that decompiling parse trees would be "a permanent drag on every type of SQL feature addition". Tom actually raised that objection on this patch in March 2023, 80 patch versions later. That's feedback worth having early.

Clients that don't support the skills extension yet can load the same skill through a tool, load_skill_review_as_author.

Elicitation: a server that can talk to the user

Originally, an MCP server could only answer the model. Elicitation lets it ask the user a question directly, through a form the client shows, with the model taking no part. In the 2026-07-28 revision, it works as a multi-round-trip request: the server answers a tool call with input_required and a form, and the client retries the call with the user's answer.

I use it for something every public service needs: feedback. Once in a while, pghacker-mcp asks "Was the last answer helpful?", with 👍, 👎 or Skip. It asks at most once in an hour of use, backs off for a day if you decline, and never asks if you connect with ?feedback=off.

It sounds small, but it's a new interaction mode: a server that hears directly from the people it serves. I believe we'll see a lot more of this, from confirmations to choices to preferences. MCP is no longer just a way for agents to call tools. It's becoming a flexible protocol between servers, agents and the people who use them.

Why I built it on Azure HorizonDB

Everything I've described, from the mail and embeddings to the code history and the graph, lives in one Azure HorizonDB database: 29 GB on 32 vCores, running PostgreSQL 17 with pgvector, pg_trgm, pg_textsearch and Apache AGE. Even PilotSwarm keeps its agents' durable state there, and the indexer writes to it every hour while the public server reads.

Full disclosure: I work on the team that builds HorizonDB, so I'm biased. But this project shows what HorizonDB was designed for. HorizonDB separates compute from storage and sends only WAL from compute to storage, so I never had to provision storage or IOPS as the archive and the history grew. If the public server needs more read capacity, read replicas share the same zone-resilient storage instead of copying it. And because HorizonDB is built on PostgreSQL, every extension this project needed is there, and nothing in the code is specific to HorizonDB. One command runs the same project on your laptop, with PostgreSQL 17.

HorizonDB is in public preview and open to everyone. If you're building AI apps and agents on PostgreSQL, create a cluster and give it a try.

In conclusion

pghacker-mcp unlocks the PostgreSQL community's knowledge for every AI agent. With the commit history, your agent can search any version of PostgreSQL in milliseconds. With the knowledge graph, it can connect code to the debate behind it. And with skills and elicitation, a server can teach agents and hear from the people who use it.

To try it, add the server to your agent. In GitHub Copilot CLI or Claude Code, it's one command:

copilot mcp add --transport http pghacker https://pghacker-mcp.dev/mcp
claude mcp add --transport http pghacker https://pghacker-mcp.dev/mcp

pghacker-mcp.dev has the steps for the GitHub Copilot app, VS Code, Codex, Cursor and OpenCode. Then ask it something you've always wondered about PostgreSQL. The code is on GitHub: read it, file issues, contribute, and tell me how its answers work for you.

For nearly three decades, the PostgreSQL community has explained in public why PostgreSQL is built the way it is. Now PostgreSQL itself can help every agent, and every developer, find those explanations.

Azure Content Understanding

anishekkamal — Wed, 21 Oct 2026 17:45:22 GMT

Azure Content Understanding is becoming a structured-understanding layer for documents, images, audio, and video. Use the GA API for production automation. Evaluate preview capabilities only when synchronous processing, semantic chunking, in-page segmentation, metadata/signature extraction, improved training, or agentic reasoning justifies the added risk.

Use the GA API as the production baseline.
Use preview APIs for controlled evaluation, not default production dependency.
Enable confidence and grounding so automation can route uncertain results to review.
Map analyzers to supported Foundry model deployments and track model retirement.
Validate region, file limits, retention, processing location, and privacy obligations before production.

Why this matters

Enterprise AI pipelines need more than OCR. They need structured fields, layout-aware text, classifications, confidence scores, grounding to source content, and outputs that downstream systems can trust. Azure Content Understanding in Foundry Tools processes documents, images, audio, and video into user-defined structured output for automation, analytics, retrieval-augmented generation, and agentic applications. The current design question is not whether to use the service, but which API version and pipeline pattern should carry production work.

The safe default: Content Understanding 1.0 GA

Use the 2025-11-01 GA API for production workloads. Microsoft documentation identifies Content Understanding as generally available with that API version, while the 2026-06-01-preview API is explicitly public preview, without an SLA, and not recommended for production workloads. The GA path supports stable multimodal extraction, classification and segmentation, confidence scoring, grounding, custom analyzers, prebuilt analyzers, and human-review thresholds.

The August product update also improves the GA path. Microsoft announced broader GPT-5 series support, lower token usage, improved grounding efficiency, and a refreshed confidence model for existing production workflows. Treat those improvements as strong reasons to modernize existing analyzers and model deployments, not as a reason to move production directly to preview features.

What the preview adds

The 2026-06-01-preview API is a proving ground for next-generation content workflows. It adds synchronous Read and Layout operations for small, low-latency inputs that need results in the response without polling. It also adds improved training behavior, semantic chunking, richer classification signals, in-page segmentation, signature detection, document metadata extraction, and agentic mode for complex document reasoning.

Agentic mode is especially important, but it should be used carefully. It can reason across document evidence, perform calculations, validate results, interpret visual information, and return structured fields. It is also slower and more token-intensive than standard extraction, supports only document analyzers in the initial preview, supports one input file per analysis request, does not support extract-method fields, and does not support labeled samples to improve the analyzer.

A practical pipeline pattern

A production pipeline should start with an input source such as application upload, workflow storage, or a search indexing process. Content Understanding applies a prebuilt or custom analyzer. The result should pass through confidence and grounding checks before it is trusted. High-confidence results can flow to a workflow system, search index, vector store, analytics table, or agent tool. Low-confidence or high-impact results should route to human review.

For RAG, use Content Understanding when documents need more than plain text splitting: tables, figures, layout-aware markdown, image descriptions, semantic chunks, or grounded fields. The Azure Content Understanding skill in Azure AI Search is generally available in the 2026-04-01 REST API, while preview search features add AI-based descriptions for embedded images, charts, and diagrams plus semantic chunking. Use those preview features only after representative retrieval evaluation.

Production considerations

Plan for region, model, and quota early. Content Understanding requires a Foundry resource in a supported region, and processing location depends on the operation and chosen Foundry model deployment type. Content Understanding uses Foundry model deployments for generative operations; teams can configure default deployments at the resource level or pass model deployment mappings per request. Supported model lists and retirements matter: the GPT-4.1 family is documented as retiring in October 2026, with migration to GPT-5.2 recommended.

Privacy and retention also matter. Microsoft documents that customer data at rest is stored in the same region as the Content Understanding resource, output results are retained for up to 24 hours for asynchronous retrieval, and users remain responsible for legal and regulatory compliance for sensitive content, speech, images, video, and biometric data.

Decision guidance

Choose GA when the workflow is production, regulated, high-volume, SLA-sensitive, or already meets accuracy goals. Evaluate preview when GA cannot solve the problem: immediate small-document response, semantic chunking, in-page segmentation, signature or metadata extraction, improved analyzer training, or complex agentic reasoning. Do not make preview the only production path unless preview terms, limits, fallback, monitoring, and cost risk are accepted.

Decision guide

Production checklist

Is the workflow using the GA API or a preview API?
Does the input fit synchronous or asynchronous file, page, audio, or video limits?
Are confidence scores and grounding enabled where automation needs auditability?
Is the connected Foundry model deployment supported and not near retirement?
Are region, processing location, output retention, and privacy obligations acceptable?
Is there a human-review path for low-confidence or high-impact results?
Is there a fallback if preview behavior, limits, or availability changes?

Conclusion

Content Understanding should be treated as a production pipeline component, not a helper script around OCR. The GA API is the stable foundation for extraction, classification, grounding, and review. The preview API is valuable for experiments that need lower-latency Read/Layout, semantic chunking, in-page segmentation, metadata extraction, improved training, or agentic reasoning. The best teams will use both deliberately: GA for dependable automation, preview for measured learning with a rollback path.

Open-Weight Models in Microsoft Foundry

anishekkamal — Wed, 21 Oct 2026 17:44:49 GMT

Open-weight models can be valuable, but they are not automatically cheaper, safer, or more controllable. In Microsoft Foundry, the right decision depends on deployment path, licensing, data-processing location, quota, support posture, operational ownership, safety controls, and lifecycle risk.

Do not treat all visible or downloadable models as open source; review the license first.
Start with Serverless API when a supported Foundry Model meets the workload need.
Use partner/community models only after Marketplace, Product Terms, and regional availability checks.
Treat managed compute as a preview path for open-source or custom models, not a production default.
Validate data processing location, quota, safety controls, support model, and lifecycle before committing.

Why this matters

Open-weight models are now part of serious enterprise AI planning. Teams consider them for cost control, technical flexibility, transparency, data residency, regulatory pressure, and the ability to build in-house capability. But the useful question is not whether an open-weight model is better than a proprietary managed model. The useful question is which deployment and operating model fits the workload.

Use precise language

Open source does not simply mean that model weights or code are visible. The Open Source Initiative defines open source through license requirements such as free redistribution, source code access, derived works, non-discrimination, and technology-neutral terms. Many AI models are better described as open-weight: weights may be available or inspectable, but the license can still restrict use, redistribution, or competition. Architecture should not start until license and use rights are reviewed.

Four adoption paths

Microsoft Foundry gives teams several ways to use models. Foundry Models sold by Azure are hosted and operated by Azure, billed through the Azure subscription, covered by Azure service-level agreements, and supported by Microsoft. This is usually the lowest-friction production path when a supported model meets the requirement.

Foundry Models from partners and community expand provider choice, but some are Non-Microsoft Products under Product Terms and can require Azure Marketplace subscription, purchase permissions, billing-country availability, and publisher-term review. Serverless API is documented as the preferred and most capable Foundry deployment option for Foundry Models, including models sold by Azure and select partner/community models.

Managed compute is different. It hosts open-source, partner, and custom models on dedicated GPU capacity that Foundry manages. Microsoft owns the GPU topology, runtime, container image, and security patching, while the customer chooses the model, deployment template, accelerator family, and scaling behavior. However, managed compute is public preview, has no SLA, and is not recommended for production workloads in current documentation. A fully self-managed path can offer maximum control, but the organization owns the serving runtime, patching, scaling, observability, safety controls, and cost optimization.

Decision criteria

Start with workload fit. If a managed model satisfies accuracy, latency, region, and governance needs, avoid extra operational burden. Consider open-weight options when you need specific model behavior, weight-level control, a dedicated GPU path, specialized deployment templates, or a license that supports your intended use. Then test the economics. Token billing, reserved throughput, and hourly accelerator billing behave differently. Open-weight is not automatically cheaper once runtime efficiency, scale-to-zero behavior, GPU quota, engineering time, monitoring, and incident response are included.

Data residency and availability

Deployment choice also affects data processing. Serverless deployment types can process inferencing data globally, within a Microsoft-specified data zone, or in a single region depending on the selected tier. Model availability varies by provider, deployment type, region, quota, subscription, and cloud. Foundry guidance says to verify project region, feature support, model availability, quota, dependent services, and sovereign cloud constraints before production rollout.

Responsible AI and safety

Responsible AI is not optional because a model is open-weight. Microsoft Foundry guidance frames production readiness around discovering risks, protecting model and runtime behavior, and governing with monitoring and compliance integrations. In managed compute public preview, built-in content filtering is not part of the managed compute data path; applications that need request or response filtering should call Azure AI Content Safety APIs directly. That limitation can be decisive for production.

Lifecycle and procurement risk

Model lifecycle matters. Foundry Models move through Preview, Generally Available, Legacy, Deprecated, and Retired stages. Preview models are not recommended for production, and some generally available models from selected providers follow a shorter lifecycle than the standard lifecycle. Procurement also matters. Marketplace plans can require a valid payment method, purchase permissions, review of terms, and country or region availability. A model being visible in a catalog is not the same as being approved for a regulated workload.

Recommended operating pattern

Use Foundry Models sold by Azure when they meet the requirement and you want the simplest production support model. Use partner/community models when capability or provider choice matters and Marketplace and Product Terms are acceptable. Use managed compute for experimentation, evaluation, controlled preview adoption, or cases where dedicated GPU hosting of open-source or custom models is worth the constraints. Use self-managed hosting only when the organization is prepared to operate the full platform.

Decision guide

Production checklist

Is the model sold by Azure, from a partner/community provider, managed compute, or self-managed?
Does the license permit the intended commercial, regulated, or redistribution use case?
Is the model GA, Preview, Deprecated, or approaching retirement?
Who supports the model and runtime, and what SLA or preview terms apply?
Where is inferencing data processed for the selected deployment path?
What quota, billing model, accelerator capacity, and fallback option apply?
Which safety controls are built in, and which must the application add?
What will the team do if the model becomes unavailable, too expensive, or operationally risky?

Conclusion

Open-weight models should be adopted because they fit a workload, not because they are popular. The strongest enterprise pattern is disciplined choice: verify legal rights, choose the lowest-burden deployment path that satisfies the requirement, validate data and region constraints, measure cost with real traffic, and add safety and monitoring before production use.

Microsoft Foundry, Azure Databricks, or Microsoft Fabric?

anishekkamal — Wed, 21 Oct 2026 17:44:02 GMT

The question customers keep asking

Customers often ask: If Azure Databricks already supports data engineering, machine learning, and AI agents, why should we use Microsoft Foundry? And if Microsoft Fabric also includes data science and AI features, where does Fabric fit?

The confusion is understandable. All three platforms are adding new AI capabilities, and there is real overlap. A long feature checklist can look useful today and become outdated quickly. The better question is not which platform can do AI. The better question is which platform should own each part of the solution.

A simple rule of thumb: use Azure Databricks for large-scale data and machine learning, use Microsoft Fabric for business analytics and shared data experiences, and use Microsoft Foundry for AI applications and agents that connect models, tools, and business systems. Use more than one only when each platform has a clear job.

Start with the outcome, not the product name

Begin with what the user needs. Is the main goal to prepare data and build models? Is it to deliver dashboards and trusted business insights? Or is it to build an AI application that can use several models, tools, and systems? The answer gives you a practical starting point. It does not create a hard boundary, but it helps you choose a primary owner.

Start with the dominant outcome, then choose the primary platform owner.

What each platform is best at?

Azure Databricks: data, machine learning, and AI close to the data

Azure Databricks is a strong choice when the solution starts with large amounts of data. Teams use it to collect, clean, transform, and analyze data, then train and run machine learning models. It also provides tools for building and operating AI applications and agents.

For customers that already use Databricks, this matters. If an agent mainly works with Databricks data and tools, Databricks may already provide the simplest end-to-end path. The data, models, access controls, monitoring, and production operations can stay close together.

Microsoft Fabric: business analytics and shared data experiences

Microsoft Fabric is built as a software-as-a-service data and analytics platform. It brings together data movement, engineering, warehousing, real-time analytics, data science, and Power BI over OneLake. This makes it a strong choice when the main outcome is trusted business reporting, shared measures, dashboards, and broad self-service access.

Fabric also supports a data agent that lets people ask questions in plain English over selected Fabric data. The agent is read-only and uses each person's permissions, which makes it well suited for governed data questions rather than general business actions.

For a customer already using Databricks, Fabric does not have to mean moving everything. Fabric can mirror the Databricks catalog structure and read the underlying data through shortcuts. This provides a path to Power BI and Fabric analytics without copying the table data. The access rules still need to be configured in Fabric because Databricks permissions do not automatically carry across.

Microsoft Foundry: AI applications and agents across systems

Microsoft Foundry, formerly Azure AI Foundry, is a managed platform for building, running, and scaling AI agents. It supports simple prompt-based agents as well as custom agent code. It also brings models, tools, tracing, evaluations, identity, safety controls, and publishing into one AI application experience.

Foundry becomes especially useful when the AI application must work across several systems. For example, an agent might use Databricks data, a Fabric data agent, SharePoint content, a business application, and custom services. Foundry can act as the AI application layer that brings those pieces together without replacing the data platforms underneath.

It is also a strong fit when teams want a managed place to run agents, a shared set of tools and connections, consistent quality testing, dedicated agent identity, or delivery through Microsoft 365 Copilot and Teams.

If you already use Databricks, do you need Foundry?

Not automatically. Databricks has strong capabilities for agents, model access, serving, evaluation, monitoring, and governance. Adding another platform should solve a real problem, not repeat work that Databricks already handles well.

Stay Databricks-centric when

The agent mainly uses Databricks data, models, and tools.
Databricks serving, evaluation, monitoring, and access controls meet the production need.
The same data and machine learning team owns development and production.
The user experience is delivered through a Databricks application or API.

Add Microsoft Foundry when

The agent must use data, tools, and business applications across several platforms.
You need one managed place to run agents and reuse tools and connections.
The experience must be delivered through Microsoft 365, Teams, or several application channels.
The solution needs services for document processing, search, speech, vision, or centralized safety controls.

Add Foundry for a new responsibility, not because Databricks lacks AI.

Add Foundry when it brings a new operating role to the solution.

Where Fabric fits in a Databricks and Foundry architecture

Fabric often answers a different question: How will business users find, understand, and use the data? Databricks may remain the system of record for engineering and machine learning, while Fabric provides OneLake access, Power BI, shared business measures, real-time insights, and plain-language questions over trusted data.

Foundry can then sit above those data and analytics services when the user experience needs an AI agent that works across them. This creates a clear layered design: Databricks owns the data and machine learning foundation, Fabric owns the analytics and business meaning, and Foundry owns the AI application and agent experience.

Not every customer needs all three. Complexity should earn its place.

A layered pattern keeps the handoffs clear and preserves existing investments.

Five questions that make the decision easier

What is the main user outcome: data and model building, analytics and reporting, or an AI application that acts across systems?
Where does the trusted data live today, and can the solution use it without creating another copy?
Which team will build, secure, monitor, and support the production solution?
Which systems must the solution connect to, and where will people use it?
What clear value justifies another platform, cost model, security boundary, and support responsibility?

If there is no clear answer to the last question, do not add another platform yet. Start with the simplest design that meets the need, measure it, and expand only when a real requirement appears.

Common mistakes to avoid

Using a feature checklist as the main decision method. Features change quickly; ownership and operating needs are more stable.
Building the same data pipelines or storing the same data in both Databricks and Fabric without a clear reason.
Assuming that Databricks permissions automatically transfer into Fabric. They do not; security must be tested on both sides.
Choosing a platform mainly because of one preview feature. Confirm availability, regions, limits, and pricing before making a production commitment.
Adding a platform without naming the team that will own the cost, security, monitoring, and support.

Practical recommendations:

For customers already centered on Databricks

Keep Databricks as the primary data and machine learning platform. Add Fabric when Power BI, shared business measures, or broad analytics access create clear value. Add Foundry when the AI application must work across systems or needs a separate agent platform and Microsoft 365 delivery.

For customers centered on Fabric

Use Fabric for the data and business intelligence experience. Add Foundry when agents need broader models, tools, actions, or delivery channels. Add Databricks when advanced data engineering, open machine learning workflows, or an existing Databricks estate makes it the better execution platform.

For new projects

Start with one end-to-end business scenario. Choose the smallest set of platforms that can deliver it. Test security, cost, performance, and support ownership before expanding. A simple solution that is easy to operate is usually better than a more impressive architecture with unclear boundaries.

Final takeaway

You do not need to choose one platform as the winner. You need clear responsibilities. Azure Databricks can remain the home for data and machine learning. Microsoft Fabric can make trusted data easier for the business to use. Microsoft Foundry can power AI applications and agents that work across systems.

The best architecture is usually easy to explain: preserve what already works, keep one trusted system of record, give each workload one primary owner, and add another platform only when it brings a clear new capability or operating model.

Microsoft Foundry, Azure Databricks, or Microsoft Fabric?

anishekkamal — Wed, 21 Oct 2026 17:43:20 GMT

The question customers keep asking

A simple rule of thumb: use Azure Databricks for large-scale data and machine learning, use Microsoft Fabric for business analytics and shared data experiences, and use Microsoft Foundry for AI applications and agents that connect models, tools, and business systems. Use more than one only when each platform has a clear job.

Start with the outcome, not the product name

Start with the dominant outcome, then choose the primary platform owner.

What each platform is best at?

Azure Databricks: data, machine learning, and AI close to the data

Microsoft Fabric: business analytics and shared data experiences

Microsoft Foundry: AI applications and agents across systems

If you already use Databricks, do you need Foundry?

Stay Databricks-centric when

The agent mainly uses Databricks data, models, and tools.
Databricks serving, evaluation, monitoring, and access controls meet the production need.
The same data and machine learning team owns development and production.
The user experience is delivered through a Databricks application or API.

Add Microsoft Foundry when

The agent must use data, tools, and business applications across several platforms.
You need one managed place to run agents and reuse tools and connections.
The experience must be delivered through Microsoft 365, Teams, or several application channels.
The solution needs services for document processing, search, speech, vision, or centralized safety controls.

Add Foundry for a new responsibility, not because Databricks lacks AI.

Add Foundry when it brings a new operating role to the solution.

Where Fabric fits in a Databricks and Foundry architecture

Not every customer needs all three. Complexity should earn its place.

A layered pattern keeps the handoffs clear and preserves existing investments.

Five questions that make the decision easier

What is the main user outcome: data and model building, analytics and reporting, or an AI application that acts across systems?
Where does the trusted data live today, and can the solution use it without creating another copy?
Which team will build, secure, monitor, and support the production solution?
Which systems must the solution connect to, and where will people use it?
What clear value justifies another platform, cost model, security boundary, and support responsibility?

If there is no clear answer to the last question, do not add another platform yet. Start with the simplest design that meets the need, measure it, and expand only when a real requirement appears.

Common mistakes to avoid

Using a feature checklist as the main decision method. Features change quickly; ownership and operating needs are more stable.
Building the same data pipelines or storing the same data in both Databricks and Fabric without a clear reason.
Assuming that Databricks permissions automatically transfer into Fabric. They do not; security must be tested on both sides.
Choosing a platform mainly because of one preview feature. Confirm availability, regions, limits, and pricing before making a production commitment.
Adding a platform without naming the team that will own the cost, security, monitoring, and support.

Practical recommendations:

For customers already centered on Databricks

For customers centered on Fabric

For new projects

Final takeaway

The best architecture is usually easy to explain: preserve what already works, keep one trusted system of record, give each workload one primary owner, and add another platform only when it brings a clear new capability or operating model.

Scale Data Collection Endpoint private connectivity with IP Endpoint Compression - Preview

Mahesh_Sundaram — Wed, 21 Oct 2026 17:22:27 GMT

Scale Azure Monitor Private Link with data collection endpoint IP compression

As organizations expand their Azure Monitor deployments, private networking needs to scale with them. For enterprises running large, distributed environments, that can create an increasingly important challenge: how do you grow private monitoring without consuming private IP address space at the same rate?

Azure Monitor is introducing private IP endpoint compression for data collection endpoints (DCEs) connected through Azure Monitor Private Link Scope (AMPLS).

This capability is designed to reduce the private IP footprint by ~90%-95% associated with DCEs while preserving the Azure Monitor Private Link architecture and the security controls customers already use.

The challenge: private monitoring at enterprise scale

Organizations often centralize Azure Monitor connectivity through carefully governed hub-and-spoke networks.

As these environments grow, they can include monitored resources, data collection rules (DCRs), DCEs, and Log Analytics workspaces distributed across multiple regions.

When private connectivity is required, DCEs are connected through AMPLS. The associated private endpoint uses addresses from a customer-managed subnet.

As more DCEs are added, this can increase the private IP footprint required for Azure Monitor connectivity and create challenges such as:

Increased subnet-capacity planning
Additional network-governance reviews
Delays when onboarding workloads or regions
Provisioning challenges when available subnet capacity becomes constrained
More operational complexity in centralized DNS and hub-and-spoke environments

As customers onboard more Azure resources to send telemetry over private networks, they need a scalable way to preserve valuable private IP address space without increasing the operational complexity of their network-isolated monitoring environment.

Introducing DCE private IP endpoint compression

DCE private IP endpoint compression changes how DCE service endpoints are represented behind an AMPLS private endpoint.

Instead of having the private IP footprint scale directly with every DCE, the compressed architecture groups compatible DCE service endpoints regionally and allows them to use a smaller, bounded set of private IP configurations.

Requests continue to be routed to the intended DCE based on the requested endpoint and the existing Azure Monitor authorization context.

The result is a more scalable private-network architecture without introducing a new data collection model.

What does this mean for customers?

Large enterprises have limited, tightly managed, often fragmented private IPv4 spaces. Private endpoints require IP addresses from customers' private IPv4 subnets. With private IP endpoint compression, all DCEs in a region share 3 regional private IPs. For example, 20 DCEs drop from 60 private IPs to 3, which is 95% fewer. Private IP address use stops growing with every DCE you add. There are no changes to how DCEs, DCRs, AMPLS, Azure Monitor Agent or Log Analytics work.

Use private address space more efficiently

A smaller, bounded private IP footprint can preserve valuable subnet capacity for additional workloads and Azure services.

This can be particularly useful for enterprises operating with constrained private IP address space or centralized network-allocation processes.

Make network planning more predictable

Instead of treating each additional DCE as a proportional increase in private IP requirements, network teams can plan capacity around the regional architecture. This approach makes the network planning more predictable for enterprise customers.

Scale monitoring across more workloads and regions

Reducing pressure on private IP address space can make it easier to expand monitoring across applications, subscriptions, and regions without repeatedly redesigning private endpoint subnets.

Reduce operational friction

A more compact endpoint representation can reduce the networking work associated with subnet capacity reviews, expansion planning, and Private Link onboarding.

What stays the same?

One of the goals of this design is to improve network scalability while preserving the Azure Monitor model customers already use.

DCE private IP endpoint compression doesn't change:

The role of AMPLS as the private Azure Monitor network boundary
The role of the private endpoint connecting a virtual network to AMPLS
AMPLS Open and Private Only access modes
DCR collection, transformation, and routing logic
Azure Monitor Agent configuration semantics
Log Analytics tables, retention, or KQL query behavior
The amount of telemetry ingested into Azure Monitor
Application Insights data collection, which doesn't use DCEs
Azure Monitor ingestion charges
Azure Private Link data-processing charges based on data volume

Customers should continue following their existing DNS, routing, network security, public network access, and AMPLS configuration requirements.

Preparing for the controlled preview

DCE private IP endpoint compression is currently intended for subscriptions participating in a controlled preview.

For customers participating in the preview, we recommend starting with a nonproduction or limited deployment.

Before expanding the deployment:

Map your topology. Understand the virtual networks, peering, AMPLS resources, private endpoints, DCEs, DCRs, workspaces, DNS zones, and supporting subnets involved.
Review DNS ownership. Pay particular attention to networks sharing Azure Monitor private DNS zones and use a deliberate AMPLS topology.
Establish a baseline. Record your existing private endpoint IP configurations and DCE DNS responses.
Confirm regional alignment. Review the relationship between monitored resources, DCE configuration access, ingestion endpoints, and destination workspaces.
Review access modes. Confirm the appropriate use of AMPLS Open or Private Only access modes for your security requirements.
Validate end to end. Verify DNS resolution, Azure Monitor Agent configuration access, DCR health, ingestion, transformation, and query behavior before expanding the deployment.

Looking ahead

Bottom line: DCE private IP endpoint compression is designed to make private Azure Monitor deployments easier to scale by reducing the relationship between DCE growth and private IP consumption, while preserving the Azure Monitor and AMPLS architecture customers use today.

Customers interested in participating in the controlled preview can contact the author via email with their subscription need to be allowlisted for the preview. This preview is available only to allowlisted subscriptions. To request access, submit your Azure subscription ID through the DCE IP Endpoint Compression preview onboarding form. Wait for Microsoft to confirm that your subscription is preview-enabled before you create the test DCEs. IP compression applies automatically to newly created DCEs in preview-enabled subscriptions. There's no additional setting to enable when you create a DCE or associate it with AMPLS. We look forward to helping customers scale private Azure Monitor deployments while making more efficient use of their network address space.

Resources

Learn more about designing and configuring private connectivity for Azure Monitor:

Scale Data Collection Endpoint (DCE) private connectivity with IP Endpoint Compression (Preview) - Azure Monitor | Microsoft Learn
Use Azure Private Link to connect networks to Azure Monitor
Learn how Azure Monitor Private Link Scope (AMPLS), private endpoints, and Azure Monitor resources work together to provide private connectivity.
Design your Azure Monitor Private Link configuration
Review network topology, DNS, AMPLS limits, hub-and-spoke architectures, and other considerations when planning Azure Monitor Private Link.
Configure Azure Monitor Private Link
Follow the configuration guidance for creating an AMPLS, connecting Azure Monitor resources such as Data Collection Endpoints (DCEs), and connecting the AMPLS to a private endpoint.
Prevent IPv4 Exhaustion in Azure - Azure Architecture Center | Microsoft Learn

Choosing the Right Azure Virtual Machine for Ansys CFX

Hugo_Meiland — Wed, 21 Oct 2026 17:11:34 GMT

If you are moving Ansys CFX turbomachinery simulation software to the cloud, the first question is not whether Azure can run your computational fluid dynamics (CFD) workloads, but it is which Virtual Machine (VM) delivers the best balance of performance and cost. Azure offers multiple AMD EPYC-based HPC VMs, each optimized differently for compute, memory bandwidth, and price. As a result, the largest VM or the lowest hourly-cost option is not necessarily the most economical choice once the cost of completing a simulation is considered.

Ultimately, two metrics matter most: the time to complete a simulation and the cost to run the simulation. To evaluate both, we benchmarked a CFX airfoil case at 10M, 50M, and 100M mesh nodes across Azure HBv5, HBv4, HX, and Fams_v7 VMs. We then validated the optimal HBv5 tuning approach using the TUDA transonic compressor benchmark from TU Darmstadt, a widely recognized open benchmark for turbomachinery CFD. This allowed us to assess whether the observed performance benefits extend beyond a single airfoil test case to a fundamentally different CFD workload.

Key findings include:

The latest generation HBv5 VM is 2-3x faster than a 176-core node on real meshes, and on any 50M mesh nodes and up it is highly cost effective.
On small meshes the economics flip: a 176-core HBv4 delivers the lowest cost per solve.
Despite its low hourly cost, Fams_v7 is the most expensive per simulation on large meshes.
The TUDA compressor study confirms that the performance benefits seen in the airfoil benchmarks also apply to larger turbomachinery workloads, while smaller models require more careful MPI rank tuning to achieve optimal results. The practical answer to "which VM should I choose?" depends on mesh size and how you run. This guide gives you the crossover points to make that decision with confidence.

Benchmark overview

The benchmark used an external-aerodynamics airfoil model at 10M, 50M, and 100M mesh nodes. All simulations were performed in single precision using the CPU-based CFX solver. The study evaluated 168 VM, mesh, and rank-count configurations across four Azure VM families and included 254 solver runs, retaining the best result for each configuration.

Performance was measured using CFD Solver wall-clock time rather than total workflow runtime. This distinction matters because preprocessing, partitioning, storage, and workflow orchestration overheads vary by environment. Solver wall-clock time isolates the computational workload and provides the clearest view of how each VM family executes and scales CFX.

There is also a practical CFX-specific reason to focus on the solver timer. CFX output can report timing for both partitioning and solving, and partitioning is often less sensitive to core count. If users measure the partitioner, scaling may appear artificially flat. The 50M and 100M cases required large partitioning due to 64-bit indexing, while the 10M case used 32-bit indexing.

VM	Azure family	CPU	Cores	Notes
HBv5	HBv5-series	EPYC 9V64H Zen 4 cores with HBM	368	High-bandwidth memory for bandwidth-bound HPC
HBv4	HBv4-series	EPYC 9V33X “Genoa-X” with 3D V-Cache	176	DDR5 with large L3 cache
HX	HX-series	EPYC 9V33X, same as HBv4	176	Larger memory footprint for big models
Fams_v7	Fasv7-series, F80ams_v7	EPYC 9005-series "Turin”	80	Compute-optimized general VM

Table 1. AMD EPYC-based Azure VM families evaluated in the CFX benchmark.

Note: HBv4 and HX share the identical 9V33X CPU, so on compute they are near interchangeable. The primary difference is memory capacity, not speed.

Performance comparison

The performance story is best seen in the chart below. HBv5 delivered the shortest solver runtime across all three mesh sizes, and its advantage widened as the workload grew. On the 100M-cell model, HBv5 completed the solve in roughly one-third of the time required by HBv4 or HX.

Figure 1. Best solver wall-clock time by VM family and mesh size. Lower is faster.

Three observations stand out:

HBv5 wins every mesh, and its lead widens with size: it is about 2x faster than a 176-core node at 10M, and about 2.9x faster at 100M.
HBv4 and HX produced similar solver performance, consistent with their shared AMD EPYC 9V33X processor generation.
Fams_v7 showed strong low-rank performance, but it caps at 80 cores and ends up about 7x slower than HBv5 on the 100M mesh.

Why cost-per-simulation matters

Raw speed and sticker price both mislead in the cloud, because you rent the whole VM by the hour regardless of how many cores a job uses. The metric that governs your bill is cost per completed simulation.

Cost per run = solver wall-clock seconds / 3600 x VM hourly rate (Linux, South Central US.) This ties speed and price together, and it is the metric a cloud-adoption business case should be built on.

VM	$/hr PAYG	$/hr 3-yr reserved
HBv5	23.76	11.88
HX	10.37	5.18
HBv4	8.64	4.32
Fams_v7	8.47	3.30

Table 2. Azure retail list prices used in the benchmark calculations: Linux, South Central US.

VM	Airfoil 10M	Airfoil 50M	Airfoil 100M
HBv5	$0.057	$0.242	$0.274
HBv4	$0.041	$0.248	$0.289
HX	$0.058	$0.251	$0.345
Fams_v7	$0.104	$0.604	$0.717

Table 3. Cost per solve using PAYG pricing and best solver wall-clock time.

Figure 2. Cost to solve the 100M-cell benchmark once.

The cost analysis reveals an important shift as model sizes increase. For the smallest 10M mesh case, HBv4 delivers the lowest cost per simulation, despite HBv5 achieving the fastest runtime. However, as workloads grow to 50M and 100M mesh nodes, HBv5 emerges as both the fastest and most cost-effective platform, with its performance advantage more than offsetting the higher hourly VM rate.

In contrast, Fams_v7 illustrates the danger of evaluating cloud resources based solely on hourly pricing. While it offers one of the lowest hourly costs, its longer runtimes make it the most expensive option on a per-simulation basis for larger CFD workloads. For organizations running CFX regularly, Reserved Instances can further improve the economics, reducing infrastructure costs by roughly 50% while preserving the same performance characteristics.

How CFX scales on Azure HBv5

HBv5 keeps winning as meshes grow because it provides scaling headroom. On the 100M mesh, HBv5 goes from 550 seconds at 16 ranks to 42 seconds at 368 ranks, a 13.2x speed-up, and still gains from higher rank counts at the top of its range.

Figure 3. HBv5 scaling for the 100M-cell CFX airfoil benchmark.

Fams_v7 can be attractive at very low rank counts, but its scaling is constrained by its 80-core configuration. HBv4 and HX scale to 176 cores before approaching a plateau. HBv5 continues extracting value up to 368 ranks, which is why its advantage grows as models become larger.

Transonic compressor validation on HBv5

The TUDA transonic compressor benchmark is selected because it tests the same HBv5 tuning approach on a different physics, i.e., a turbomachinery workload, not just the original airfoil case. The result is consistent: spreading ranks one-per-CCD-first across the 48 CCDs, combined with MPI pinning, helps heavier cases to continue scaling as more of the node is used.

Figure 4. TUDA transonic compressor scaling on HBv5 with CCD-spread + MPI pinning. Lower solver wall-clock time is better.

This case is a 43M mesh node model and improves from 218 seconds at 48 ranks to 57 seconds at 368 ranks, a 3.8x speed-up, showing that large turbomachinery models have more parallel work available per rank and can keep scaling further up the CCD ladder.

Figure 5. Radial Compressor 20M scaling on HBv5 using CCD-spread MPI rank placement.

The Radial Compressor 20M benchmark shows the other side of the sizing rule. Solver wall-clock time decreases from 1,173 seconds at 48 ranks to 331 seconds at 368 ranks, a 3.5× reduction in turnaround time, but most of the benefit is captured before the full-node configuration. Above roughly 150–250 ranks the scaling efficiency tapers, because the case is smaller per rank and communication/startup overheads become more visible. This makes the radial-compressor case a useful example: HBv5 still delivers the fastest turnaround, but smaller turbomachinery models should not automatically use every core if cost-per-solve is the goal.

Choosing the right Azure VM for your CFX workload

The practical rule is to match the VM to the workload rather than to the price tag. For production meshes of roughly 50M mesh nodes and above, HBv5 is the preferred starting point because it offers the strongest combination of turnaround time and cost per completed simulation. For smaller or high-volume short runs around 10M mesh nodes, HBv4 can provide a better cost-per-solve profile.

HX should be selected over HBv4 when the additional memory footprint is required, not because compute performance is expected to differ materially. Fams_v7 can be useful for development, sanity checks, or occasional small runs, but it should not be the default production-throughput VM for larger CFX workloads. Users should also validate MPI choice, use large partitioning when required, measure solver time rather than partitioning time, and avoid over-provisioning ranks on small meshes

Rule of thumb: The bigger the mesh, the more HBv5 wins on both speed and cost. The smaller the mesh, the more a 176-core HBv4 wins on cost. The crossover in this data sits below the 50M mesh.

Practical tuning notes for CFX on Azure VMs

Validate MPI choice. MPI performance varied across the Azure VM families tested, with HBv5, HBv4, and Fams_v7 favoring one configuration and HX another. Validate MPI options for your workload and VM configuration.
Partition big meshes with -part-large. The 50M and 100M meshes need 64-bit integer indexing, while the 10M mesh runs 32-bit.
Measure the solver wall-clock, not the partitioner. CFX output can report total wall-clock time twice: first for partitioning, then for the solver. If scaling looks flat as ranks increase, you may be timing the partitioner.
Do not over-provision ranks on small meshes. Tiny cases can hit communication overhead before they use every core.

Key takeaways for Azure cloud adoption

HBv5 is the preferred platform for production-scale CFX workloads, delivering both the fastest runtimes and the lowest cost per solve on larger meshes.
HBv4 remains attractive for smaller workloads where minimizing cost per simulation is more important than minimizing runtime.
Cloud sizing decisions should be based on cost per simulation rather than hourly VM pricing.

Taken together, Azure gives CFX users a practical cloud-sizing framework: select the VM based on mesh size, solver scalability, and cost per completed simulation.

Learn More:

Learn more about Ansys CFX capabilities

Request a Microsoft Azure Free Trial

Cohere Rerank V5 is now available in Microsoft Foundry

RashaudSavage — Wed, 21 Oct 2026 16:27:58 GMT

Today, we’re announcing the availability of Cohere Rerank v5 in Microsoft Foundry, helping developers improve the relevance and efficiency of enterprise search and retrieval-augmented generation (RAG). With Fast and Pro versions and a new Context Focus capability, Rerank 5 helps applications find useful information and pass more focused context to language models.

Surface the information that matters

The quality of an AI response depends in part on the information retrieved to support it. Rerank V5 reorders retrieved documents based on their relevance to a query, helping applications prioritize the evidence most useful for answering a user’s question.

Built for enterprise search, Rerank V5 is optimized for real-world relevance across domains such as finance, healthcare, manufacturing, and workplace productivity, with multilingual support for global organizations. Improved, calibrated relevance scores are stable across runs, helping developers set thresholds to filter out less relevant results before they reach the language model.

Reduce token usage with Context Focus

Context Focus identifies and returns the most relevant passages within the documents being reranked. Developers can pass those passages to a language model, reducing the amount of text it needs to process. This can lower token consumption and latency while helping improve the quality of downstream responses.

For example, an employee asking about a specific expense policy may need just a few passages from a lengthy handbook. Context Focus helps applications extract that relevant context for the answer.

Choose Fast or Pro for your workload

Rerank V5 Fast is optimized for low latency and high throughput, making it a fit for high-volume search and agents that perform multiple searches per task. Rerank V5 Pro prioritizes retrieval quality for complex queries and long or specialized documents. The two options let teams choose the balance of quality and performance that fits their application.

Get started in Microsoft Foundry

Explore Cohere Rerank V5 in the Cohere-rerank-v5-pro | Model Catalog | Microsoft Foundry. Evaluate Fast and Pro with your own queries and documents, and assess how Context Focus affects answer quality, token usage, and latency in your search and RAG workflows.

From Science to Storytelling: Chantal Bossé’s MVP Journey

BetsyWeber — Wed, 21 Oct 2026 16:24:56 GMT

The Early Challenge That Shaped Chantal’s Career

Long before Chantal Bossé became a Microsoft Most Valuable Professional (MVP), she was a biochemistry student trying not to forget her words during a 20-minute seminar. She redrew scientific illustrations onto transparencies, using visuals as a path through the material. That early response to presentation anxiety would eventually shape a career spanning telecommunications, instructional design, presentation coaching, and visual communication. Today, Chantal is an author, trainer, consultant, and long-time MVP whose story shows how curiosity - and the challenges we learn to solve for ourselves - can grow into expertise that helps an entire community.

Chantal Bossé (MVP) recording a training course on PowerPoint for LinkedIn Learning

From Biochemistry to Visual Storytelling

After earning her degree in biochemistry, Chantal entered a difficult job market and returned to telecommunications, where an unexpected opportunity led her from customer service into training and instructional design. Later, when a pharmaceutical workplace environment affected her health, she stepped away and reconsidered what should come next. The answer was still taking shape, but one constant kept pulling her forward: her fascination with PowerPoint and the possibilities of visual communication.

Those early instincts became a professional philosophy: a presentation should help an audience follow an idea - not force them to read a wall of text. As Chantal’s career evolved, visual communication became the thread connecting her scientific training, instructional design work, and growing expertise with PowerPoint.

That philosophy shaped a practical “plan, create, deliver” approach to Chantal’s work as a coach and learning designer. The method begins before PowerPoint opens: define the audience, clarify the central message, understand what is at stake, and identify the three ideas people should remember. Those decisions then guide how the presentation is created and delivered.

Community amplified the reach of Chantal’s work. Through coaching, speaking, writing, and volunteering - including service with the Presentation Guild - she turned her own lessons into practical guidance that helped others communicate with greater clarity and confidence. That habit of sharing what she learned became central to her path toward the MVP Award.

“If people are not clear, they cannot produce something that will be clear.”
- Chantal Bossé

Chantal Bossé (MVP) on stage at TEDxQuébec.

Clarity, Trust, and the Ripple Effect

Chantal’s coaching starts with listening. New speakers may believe they need more text on their slides, when what they often need is confidence and a clearer structure. Experienced speakers may need something different: the openness to reconsider a familiar approach. In both cases, Chantal helps people align their message with what the audience should understand, remember, and do next.

One of her most meaningful coaching experiences involved two TEDx speakers at opposite ends of the experience spectrum - one stepping onto a stage for the first time and one already highly accomplished. Both trusted the process, adapted their stories, and received standing ovations. For Chantal, the lesson was not that one formula fits everyone. It was that thoughtful questions, audience awareness, and trust can help every speaker grow.

That same commitment to listening, trust, and shared learning shapes Chantal’s experience as an MVP. The relationships she has built through the program extend the ripple effect of her work - connecting her with people who exchange ideas generously and are equally invested in helping others succeed.

“Being an MVP means having a smart group of people I can rely on.”

- Chantal Bossé

The MVP Award: A Community Chantal Can Rely On

For Chantal, being an MVP is rooted in relationships. The award has connected her with what she calls “a smart group of people I can rely on” - peers who share ideas openly, challenge one another, and bring different experiences to the same goal of helping others. That sense of belonging matters as much as the recognition itself.

It has also given Chantal opportunities to build trusted relationships with Microsoft product teams. She values the candid exchange: hearing what teams are working on, asking questions, sharing practical feedback, and bringing an end-user perspective into the conversation. In turn, she can help customers and community members understand what is coming, why it matters, and how they can put new capabilities to use.

The PowerPoint MVP community holds a special place in that experience. Chantal describes the group as close-knit, spirited, and sometimes a little rowdy - but always committed to making things better. Their collective knowledge, honest feedback, and willingness to support one another extend the impact of any single MVP. For Chantal, the award is meaningful because it places her inside that trusted circle: a community that learns together, contributes together, and keeps the people using the technology at the center.

AI as a Smart Start, Not the Final Destination

Chantal brings the same principles of clarity, trust, and thoughtful preparation to her work with AI. She sees Copilot as a powerful collaborator for organizing information and developing first drafts. Across Word, PowerPoint, Excel, and chat, it can summarize source material, assemble content, suggest visuals, and flag typos or inconsistencies in long decks. Delegating those time-consuming first passes allows Chantal to move several parts of a project forward while reserving her attention for the human judgment, refinement, and validation that only she can provide.

But efficiency does not remove responsibility. Chantal stresses that presenters must first understand their audience, purpose, and message. Prompt quality matters: Copilot needs a role, context, precise instructions, source material, and guardrails. Its output must then be challenged, refined, and validated - especially for factual accuracy, visual quality, readability, and fit for the moment. A useful draft for a training backup may not meet the standard for a conference keynote.

“Copilot is not a magic wand. It won’t give you a stellar, stage-ready presentation just because you prompted it.”
- Chantal Bossé

Her practical advice is to treat Copilot like a junior intern: provide strong direction, let it work, and review the result with experienced human judgment. AI can accelerate content generation, summarization, slide building, and quality checks. The presenter remains accountable for the story, the evidence, and the audience experience.

Chantal Bossé (MVP) recording a presentation

From Personal Challenge to Community Impact

Chantal’s journey is a reminder that expertise is not always a straight line. It grows when people stay curious, turn challenges into useful lessons, and share those lessons generously. Her path - from a nervous biochemistry student using visuals as memory cues to a trusted coach, author, and MVP - shows how one person’s solution can become knowledge that strengthens an entire community. In her words, “Being an MVP means having a smart group of people I can rely on.” Learn more through Chantal’s MVP profile, explore the Presentation Guild, and discover the Microsoft MVP Program. You can also connect with Chantal on LinkedIn.

Want to Learn More About the MVP Program?

To find an MVP and learn more about the Microsoft MVP Program, visit the MVP Communities website and follow program updates on LinkedIn or through #MVPBuzz.

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. 

Partner Blog | Accelerating partner growth through Microsoft Marketplace

JillArmourMicrosoft — Wed, 21 Oct 2026 16:00:00 GMT

AI transformation succeeds when customers can move seamlessly from discovering the right solution to realizing business value. Trusted partners make that possible by bringing together software, implementation, and ongoing services to guide customers from ambition to impact.

This is a significant growth opportunity for our partner ecosystem—and we are investing to help partners capture it. Our ambition is clear: make Microsoft Marketplace the destination where software development companies and channel partners build, sell, and scale together. This fiscal year, we increased our investment in the Microsoft Marketplace business by 200%,¹ while expanding the offerings, tools, and capabilities partners need to reach more customers and grow.

Get to market faster with connected resources

We are investing across the full Marketplace growth journey from Azure sponsorship and technical guidance to skilling and go-to-market resources. The goal is simple: help partners bring solutions to market faster, accelerate customer adoption, and scale their business.

We recently announced Frontier Accelerate for Marketplace, a Microsoft AI Cloud Partner Program offering that builds on existing investments to accelerate business growth through Marketplace. Technical guidance enables you to bring cloud and AI solutions to market, while Marketplace-focused skilling strengthens your team’s readiness to publish and sell. As you go to market, earn more marketing benefits and Azure sponsorship benefits to help you sell more.

Eligible partners can choose a no-cost experience with self-service resources and milestone-based benefits, or a paid premium experience with deeper Microsoft engagement and additional investment.

We are making it faster and easier for partners to bring solutions to market and creating more ways to monetize their innovation. With the new ingestion MCP server, software companies can use agents to create, confirm, publish, and manage Marketplace listings. We’re also expanding the solutions partners can sell through Marketplace, including apps and agents embedded directly into industry workflows. Microsoft Dragon Copilot listings are one example of how software companies are bringing AI apps and agents into clinical workflows at the point of care, tailored to the needs of physicians.

Expand globally through channel-led selling

For many customers, the path to AI adoption begins with a partner who understands their business. Expanding channel-led selling capabilities makes it easier for software companies and channel partners to sell together through Marketplace in more markets. Multiparty private offers are now available in more than 35 markets, including the recent release to Hong Kong, with more markets coming soon.

Our expansion into Hong Kong marks a major step in bringing these channel-led opportunities to more markets across Asia. Software companies can now reach customers through their preferred channel partner—often managed service providers, resellers, and systems integrators that have established relationships and local expertise.

Channel-led sales capabilities across resale enabled offers and multiparty private offers open gateways into new markets for software companies without rebuilding their sales teams country by country. Channel partners take a larger role in each opportunity, bringing software together with implementation, managed services, and local market expertise. The result: software companies gain reach, channel partners gain opportunity, and customers maintain their trusted partners to support their Frontier Transformation.

Simplify the path from discovery to purchase

Reaching more customers also means making it easier for them to find, evaluate, and buy the right solutions. Intelligent discovery in Microsoft Marketplace connects customers with relevant listings, creating more opportunities for partners to engage buyers pursuing their Frontier Transformation.

Once customers find the right solution, enhanced trial capabilities make the next step more accessible. New trial badges and dedicated filters make it easier for customers to identify solutions they can evaluate. For partners, trial insights provide a clearer view of customer engagement to help convert interest into sales.

As that relationship grows, Marketplace now offers more ways to start negotiations for larger deals sooner. With the ability to request a private offer, customers who need custom pricing or terms can start that conversation directly from an eligible public listing. Each request is captured as a Marketplace lead, so partners can respond quickly to the customer's requirements. The request private offer option is enabled by default for eligible new public offers; for existing eligible offers, partners can turn it on and republish.

Once terms are agreed, the focus shifts to completing the purchase. Coming soon for select offer types, private offer enhancements will give partners greater flexibility over customer subscriptions with auto-activation and future-dated agreements, while also providing customers a simpler experience that combines acceptance and purchase into one step.

Finally, Marketplace is extending the ways customers can manage and govern their cloud investments. With purchase order mapping now generally available, customers can allocate Azure and Marketplace spend against existing purchase orders across departments, budgets, software companies, and products. This gives buying offices and emerging FinOps teams the visibility and control they need to optimize cloud costs.

Continue reading here

What’s New in Cowork: Expanded plugins and role-based skills

Pratyusha_Avadh — Wed, 21 Oct 2026 16:00:00 GMT

Work today doesn’t happen in one app, and every role has repeatable tasks that take more than a quick prompt to complete. Cowork is built for that reality. With expanded connections to the systems you use every day, and role-based skills that capture recurring workflows, you can keep work moving without jumping between apps or repeating instructions each time.

Expanding plugins for Cowork

Last month, we introduced the plugin registry as the one place to discover and govern plugins across Microsoft Copilot experiences. If you already use plugins in Cowork, then nothing changes: you find them, turn them on, and use them the same way you do today. What changes is how much you can choose from. Cowork now draws on an expanded set of plugins, skills, and connectors, including:

Power Platform connectors: Cowork can work with the business apps and services your organization already connects through Power Platform. Power Platform connectors are rolling out over the coming weeks, and you can see the full list of Power Platform connectors here.

Federated Copilot connectors: Bring live data from external systems into Cowork with Model Context Protocol (MCP), using your own permissions in those systems. Learn more in the federated connectors overview.

Role-based plugins: Bring tailored skills for Sales, Service, Education, and Legal into Cowork, built specifically for the workflows your team does every day. Find these in the new Roles & Industry section of the plugin library and learn more about role-based plugins for Cowork here.

Your admin decides which plugins and connectors are available in your organization. Admins can learn more about managing plugins for Cowork.

Role-based plugins

Sellers, service teams, educators, and legal professionals all have work that repeats every week: prepping for the next customer meeting, working through a queue of cases, getting a course ready for a new term, or reviewing a contract against an approved playbook. New Sales, Service, Education, and Legal plugins for Cowork package the business processes these teams rely on into skills, so Cowork starts with pre-built workflows for those roles instead of a blank prompt. These plugins are available today in the new Roles & Industry section of the Customize page.

Roles & Industry plugins section in the Copilot app

Sales

Walk into every customer conversation prepared and leave with the next step already moving. The Sales plugin helps you research accounts, prepare for meetings, map the buying group, follow up, and decide which deals to work next. It grounds its work with your email, meetings, and files, with CRM data optional.

Sales for Cowork description page in the Copilot app

Examples of skills include:

Post-meeting follow-up: Captures decisions, commitments, owners and dates, and then drafts a customer follow-up for review.
Pipeline prioritization: Ranks open opportunities by value, urgency, risk, and momentum with reasons for what to work next.
Deal catch-up: Shows what changed across deals since a stated baseline, separating customer movement from record updates.
Competitive strategy: Tailors positioning and objection responses to the deal using approved competitor evidence and honest tradeoffs.
Business case composer: Builds a decision-ready case from the customer’s evidence and flags missing inputs.
Engagement risk insights: Flags deals or accounts that are going quiet, single-threaded or stalling.

Tasks to try in Cowork:

/post-meeting-follow-up "After today’s Northwind meeting, reconcile the notes with prior commitments. Capture decisions, owners and dates, propose supported record changes, and draft a customer follow-up for my review."
/pipeline-prioritizer "Review my open opportunities for this week. Weigh value, urgency, risk, momentum, and where I can change the outcome; return a ranked worklist with the evidence, unknowns, and next action for each."
/deal-catchup "Show what has changed across my active deals since last week. Separate customer movement from CRM housekeeping, source each material change, and propose any record updates for my review."

Where to find it: Customize > Roles & Industry library > Sales for Cowork. Dynamics 365 Sales users can also add the Dynamics 365 Sales plugin.

Service

Spend less time sorting cases and more time solving them. The Service plugin helps service teams triage a queue, prepare for the next customer interaction, research a source-backed answer, draft a reply and turn what they learned into reusable knowledge. It grounds its work with your email, meetings, and files, with CRM data optional.

Service for Cowork description page in the Copilot app

Examples of skills include:

Case triage: Orders open cases by deadlines, customer impact, commitments, and unanswered contact with the rationale visible.
Case preparation brief: Summarizes one case’s status, chronology, attempted fixes, and open commitments before the next interaction.
Answer research: Researches a source-backed answer to a support or policy question and flags conflicting or incomplete evidence.
Draft customer reply: Drafts a customer response from verified facts and applicable policy, leaving it for review before sending.
Knowledge harvest: Turns a verified resolution or workaround into draft guidance without customer-identifying details.

Tasks to try in Cowork:

/case-triage “Review my open escalations and build a prioritized worklist. Weigh deadlines, customer impact, prior commitments, and unanswered messages; show the evidence and unknowns behind the order.”
/draft-customer-reply “Use the customer’s question, verified case facts and applicable policy to draft a reply for my review. Separate confirmed outcomes from proposed remedies, cite the policy, and flag anything I must verify before sending.”
/knowledge-harvest “Use the verified resolution from this case to draft reusable guidance. Separate symptoms, cause, workaround and tested fix, remove customer-identifying details, and check for overlap with existing articles.”

Where to find it: Customize > Roles & Industry library > Service for Cowork. Dynamics 365 Customer Service users can also add the Dynamics 365 Customer Service plugin.

Using Dynamics 365?

Last week, we introduced 30 new CRM skills for Cowork across Dynamics 365 Sales, Customer Service, and Customer Insights.

Education

Give education leaders time back for their highest-priority work. The Education plugin helps leaders and educators move faster on the recurring work that keeps institutions running: assembling accreditation evidence, making learning more accessible, maintaining instructional continuity, identifying patterns in learner feedback, and governing AI responsibly, so more time goes to students and strategy. Read more in the Education blog.

Education for Cowork description page in the Copilot app

Examples of skills include:

Evidence package for accreditation and review: Maps accreditation or review requirements to evidence and flags thin, stale, or missing coverage.
Governance review: Reviews an AI tool’s technical, data, security, accessibility, policy, and support evidence before recommending next steps.
AI rollout for education: Plans phased AI adoption across institutional roles, governance requirements, prerequisites, and the academic calendar.
Discussion insights: Identifies group-level patterns in de-identified learning discussions, feedback, and questions.
Accessible learning materials: Audits course and learning materials for accessibility and creates revised versions while preserving learning objectives.
Instructional continuity: Creates a source-checked continuity package containing plans, schedules, procedures, and materials.

Tasks to try in Cowork:

/evidence-package-for-education “Map our accreditation requirements to the available institutional evidence. Build an evidence index, assess coverage, flag stale or missing support, and produce a prioritized gap list for the review team.”
/accessible-learning-materials “Review these course materials for accessibility and learner usability. Check structure, reading order, link text, image descriptions, captions, and document navigation; provide a prioritized issue list and draft revisions for review.”
/instructional-continuity “Build a continuity package for next term’s program. Gather the current curriculum, prior plans, academic-calendar milestones, and institutional guidance; create a readiness checklist, resource inventory, key dates, and first-phase plan. Flag decisions still needed.”

Where to find it: Customize > Roles & Industry library > Education for Cowork.

Legal

The Legal plugin brings 20 legal skills to Cowork, built on the same skills also available in Word. Review and redline in Word, then take a matter further in Cowork across agreements, emails, meetings and files. Read the full announcement introducing Microsoft Copilot for legal.

Legal for Cowork description page in the Copilot app

Examples of skills include:

Review contracts: Checks a contract against the applicable playbook and identifies terms that need attention.
Summarize redlines: Explains redline changes, their impact, and which party benefits.
Identify legal obligations: Extracts obligations, key dates, and deadlines across legal documents.
Compare key terms: Highlights similarities and differences in key terms across documents.
Check execution readiness: Flags issues to address before a legal document is ready for signature.
Build case chronology: Organizes key events, dates, and facts from case materials into a chronology.

Tasks to try in Cowork:

/compare-key-terms “Extract and compare key terms across these agreements and create an Excel portfolio tracker, with each result linked to its source. Highlight material differences and anything requiring my review. Once I confirm the material issues, draft a red-flag summary for the deal team.”
/create-playbook “Build an NDA playbook from these precedents, capturing our standard positions, accepted fallbacks, and rejected positions. Surface any inconsistencies or gaps for my review. Once I approve the proposed positions, update the playbook and draft an approval request for the senior lawyer.”

Where to find it: Customize > Roles & Industry library > Legal for Cowork.

Don't see a plugin? Your admin may need to make it available first, or you may need to request access.

For the full list of skills in each plugin, see the available plugins for Cowork.

Start easily with the task catalog

Not sure where to begin? The updated task catalog rolling out in Cowork now includes task ideas for Customer Service, Executives, Finance, Marketing, and Sales roles. Each one is a starting point for real work, like prepping for a customer meeting, triaging a case queue, or summarizing close status. Pick a task, fill in the details, and Cowork takes it from there. Pair a catalog task with the matching skills for even better results.

Where to find it: Open Cowork and browse the task catalog from “Show more” below the prompt box. The updated task catalog will roll out by the end of October.

Kick tasks off from the apps you already use

Event-driven tasks already let Cowork pick up work when an email or Teams message arrives. Through plugins and Power Platform connectors, Cowork can now watch for a change in the systems your team relies on, like a new case or a deal that moves stages, and start the work when an event occurs.

Describe what to watch for and the task you want to start in plain language, and Cowork proposes the automation in a card that shows the event, what Cowork will do, and the permissions it needs. Review it, approve it, and the task runs on its own from then on. You'll find it with your other automations on the Automations page, where you can pause, edit or check its run history.

Try:

"When a new high-priority case is opened in [ERP], prepare a case brief with the customer's history and draft a first reply for my review."
"Whenever an opportunity in [CRM] moves to Negotiation, build a one-page deal brief, and flag any open risks."
"When a new contract lands in our [document system] legal intake folder, review it against our playbook, and send me a summary of the deviations."

Where to find it: Automations > Add > Create with Cowork.

Event-driven tasks keep you in control. They run with your permissions and see only what you can see. When a task sends a message or changes a record in another system, Cowork prepares the action and waits for your approval.

Learn more about setting up event-driven tasks. Supported triggers are defined by partners and can be found within the documentation for each plugin or connector.

Get started

Open the Roles & Industry library, add the relevant plugin for your role, and try one of the prompts above or start from a suggested task in the task catalog. Pair it with event-driven triggers from the tools your team already uses to delegate your entire workflow with Cowork.

SQL Server on Azure VMs makes history with the first audited SQL Server TPC-H result in the cloud!

PamLahoud — Wed, 21 Oct 2026 16:00:00 GMT

I am thrilled to share that SQL Server 2025 running on an Azure F64amds_v7 virtual machine, an AMD EPYC-based offering, has achieved an audited TPC-H result of 1,667,428 QphH@1000GB¹. This is the first official, audited TPC-H result for SQL Server on cloud infrastructure! This is currently the top performing result for SQL Server on the TPC-H 1,000 GB benchmark.

Why this TPC-H benchmark is different

We do a lot of performance testing here at Microsoft. If you've read our previous blogs, you've seen us use various tools like HammerDB to run TPC style workloads against different VM sizes and storage configurations, and you've probably noticed the footnote at the bottom explaining that those results aren't comparable to published TPC benchmarks. Those studies are super useful for comparing VM series and storage options, but they don't carry the same weight as an audited, industry-standard benchmark.

That's what makes this result different. The TPC (Transaction Processing Performance Council) defines a strict set of rules for how a benchmark must be run, priced, and documented so that results from different vendors and platforms can be fairly compared. Every published result must be reviewed by an independent TPC auditor, and the full disclosure report is made available to anyone who wants to dig into the details. SQL Server has been a fixture on the TPC results lists for decades because of the way it can push a system to its limits, and SQL Server TPC-H results have historically been published on physical hardware.

Getting an audited TPC-H benchmark on a cloud VM was not a small undertaking. The TPC specifications were written with on-premises, OEM hardware in mind, so it took years of work with the auditor to determine how to run and price a benchmark on a cloud VM while still adhering to every standard. One important part of that work was proving that cloud infrastructure could meet the same durability expectations as traditional hardware. The TPC benchmark includes tests for ACID compliance to guarantee that the system is durable as well as fast. For SQL Server, that means an acknowledged write must remain durable not just at the database layer, but across every layer involved in the write path: Windows, the Azure platform, and the underlying storage devices. The audit forced us to explain that end-to-end durability chain, including how the platform protects committed data through failure and recovery scenarios. In that sense, the benchmark was not only a performance proof point, but also an externally audited validation that Azure’s storage architecture can support the reliability expectations of enterprise SQL Server workloads.

The results for the TPC-H benchmark

We started planning this more than three years ago, and it's so cool to finally see it posted on the TPC website!

Here's a look at the system configuration and results¹:

	Azure F64amds_v7 VM
Processor	1x AMD EPYC 9V45 @ 2.60 GHz
Cores / Threads	64 / 64
Memory	512 GiB
Storage	Premium SSD v2 managed disks + local ephemeral NVMe
Database	SQL Server 2025 Enterprise Edition
Operating system	Windows Server 2025 Datacenter
Database size	1 TB (scale factor 1,000)
QphH@1000GB	1,667,428
Price/Performance	$558.17 USD per kQphH@1000GB

Check that out! That's a single virtual machine in the cloud chewing through a 1 TB decision-support workload at more than 1.6 million queries per hour on the composite TPC-H performance metric. So, what’s special about Azure F64amds_v7? Featuring the AMD EPYC CPUs, with 64 full physical cores, SQL Server workloads get the much-needed platform capabilities to power through even the most complicated, compute-hungry queries. It's a great demonstration of just how far SQL Server on Azure VMs has come. You can find every last detail in the Executive Summary and Full Disclosure Report on the TPC website.

What this means for you

For years, we've been telling customers that moving SQL Server to Azure doesn't mean giving up performance. Many of you have some of your most demanding, mission-critical SQL Server workloads still running on-premises, often because of a lingering worry that the cloud just can't keep up with a big, beefy on-prem server. Now we have an independently audited, industry-standard benchmark showing that it absolutely can!

If you've been holding back on modernizing your largest SQL Server workloads because of performance concerns, this is a great time to take another look. SQL Server on Azure VMs gives you the same SQL Server engine you know and love, full control over the OS and instance, and the performance to handle your heaviest workloads, plus all the value-add capabilities of the SQL IaaS Agent extension and the flexibility to scale as your needs change. For workloads that need deep OS control, instance-level compatibility, or a straightforward migration path, Azure VMs continue to be a great option.

A word about SQL Server price-performance

You may have noticed the price-performance number in the table above and thought "wait a minute, I thought Azure had the best price-performance for SQL Server?!" That's a fair question, and since price-performance is a topic near and dear to my heart, I want to address it head on.

To keep results comparable, TPC has strict rules about how a benchmarked system is priced, and some of those rules don't map neatly to how customers actually pay for SQL Server in Azure:

Pricing must be publicly available list pricing. That means we couldn't take advantage of Azure Hybrid Benefit, which many of you use to bring your existing Windows Server and SQL Server licenses with Software Assurance to Azure.
SQL Server licensing was priced as three years of pay-as-you-go. Traditional on-premises benchmark results typically price license-only SQL Server, amortized over three years. In this result, SQL Server licensing accounts for roughly two-thirds of the total three-year system cost of $930,701. The VM compute itself is only about 7%.
The storage was provisioned for the maximum capability of the VM. The Premium SSD v2 disks were configured with more IOPS than the TPC-H workload needed, and with Premium SSD v2, you pay for the IOPS and throughput you provision.

In the real world, you have a lot more flexibility: Azure Hybrid Benefit, reservations or savings plans, right-sizing your Premium SSD v2 storage for the IOPS and throughput your workload actually needs (and scaling it up or down on the fly!), and choosing the right VM series and size for your workload. Also keep in mind that Azure costs account for things like electricity, datacenter space, infrastructure management etc. – things you need to worry about on-premises that aren’t accounted for in the benchmark pricing.

So, while the published TPC price-performance number is important for benchmark comparability, it isn't a recipe for what a customer's optimized Azure deployment should cost.

As with any SQL Server question, the answer to "what will it cost me?" is "it depends," and we'll be digging into exactly that in an upcoming blog on how to optimize the price-performance of high-performance SQL Server workloads on Azure VMs. Stay tuned!

What's next

This is just the beginning! Be sure to check out the full result on the TPC website, and keep an eye out for an upcoming episode of Data Exposed where we'll dig deeper into the benchmark and what it means for your SQL Server workloads. And as always, stay tuned as we continue to deliver innovations that make Azure the best place to run SQL Server!

¹ Result referenced is current as of October 12, 2026. Azure F64amds_v7 Virtual Machine: 1,667,428 QphH@1000GB, $558.17 USD/kQphH@1000GB, available 10/06/26. TPC Benchmark™, TPC-H™, and QphH™ are trademarks of the Transaction Processing Performance Council. For more information, visit www.tpc.org.

AMD is the high performance and adaptive computing leader, powering the products and services that help solve the world’s most important challenges. Our technologies advance the future of the data center, embedded, gaming and PC markets. Founded in 1969 as a Silicon Valley start-up, the AMD journey began with dozens of employees who were passionate about creating leading-edge semiconductor products. AMD has grown into a global company setting the standard for modern computing, with many important industry firsts and major technological achievements along the way.

Your guide to Intune at Microsoft Ignite 2026

euburrag — Wed, 21 Oct 2026 16:00:00 GMT

If you manage and secure endpoints, you are already on the front line of your organization’s AI transformation. Trusted, cloud native endpoint management and protection across Windows, macOS, and mobile devices are essential to preparing for AI, securing data and AI, and using AI to strengthen defense. This guide makes it easy to find the Microsoft Ignite 2026 sessions featuring the latest Microsoft Intune management and security innovations, no AI required.

Use this guide to find Ignite sessions and labs, meet the teams behind each, and start thinking about the organizational questions you want to bring to the conference. Bookmark this post at aka.ms/IntuneAtIgnite so you can find it again.

Featured sessions

Start with these three sessions for the clearest view of what’s new in Intune and what's coming next.

AI ready endpoints: secure, manage and scale (BRK404)

Don’t miss the Intune strategy session for the week. See how Intune turns insights across your digital estate into policy and action—and verifies that each change keeps devices healthy and secure. Learn how IT can gain fleet-wide visibility and control, reduce exposure, and use AI-powered tools to scale its impact.

Speakers: Jason Roszak, VP, Product Management, Microsoft Intune and Eugenie Burrage, Director, Product Marketing, Microsoft Intune

Build a trusted device and app foundation for AI at scale (BRK328)

IT’s endpoint estate continues to expand, and deploying a new device is only the beginning. Once deployed, the device must stay configured, patched, and recoverable while apps, policies, and threats change. This session follows a device lifecycle: provisioning, security baselines, app governance, updates, safe deployment of change, and fast recovery when something breaks. See how IT can prevent drift and verify that every change did what it was meant to do in a cloud native environment.

Speaker: Sangeetha Visweswaran, VP of Engineering, Microsoft Intune

Stay ahead of endpoint risk with AI-powered discovery and remediation (BRK322)

Three questions shape every remediation plan: Where are we exposed? What matters most? How do we fix it without disrupting the business? See how Microsoft helps IT move from finding to fixing beyond the SOC by using AI-powered threat and business context to assess misconfigurations and prioritize risk. Intune and Windows then apply the response, with approvals and staged deployment, and verification keep changes governed and confirm that risk decreased.

Speakers: Alemeshet Alemu, Partner Director of Engineering, Microsoft Intune and Ankur Goyal, Principal Product Manager, Microsoft Intune

Start a day early with the pre-day session

Get Your Endpoint Estate Ready for AI with Microsoft Entra, Intune, and Windows

Get hands-on with the latest Intune innovations as product experts guide you through a cloud-native endpoint management journey—from provisioning and app delivery to modern policy, updates, and recovery. Bring a demo tenant if you have one, get practical guidance, and take new skills and insights home to fortify your organization’s environment and drive better outcomes.

Experts: Rob York, David Guyer, and Heena Macwan, Principal Product Managers, Microsoft Intune; Jessica Yang, Senior Product Manager, Microsoft Intune; and Ahmed Ghaddah, Product Manager, Windows.

Intune sessions at a glance

Code	Session	Session type
PREL44	Get Your Endpoint Estate Ready for AI with Microsoft Entra, Intune, and Windows	Pre-day
BRK404	AI ready endpoints: secure, manage and scale	Breakout
BRK328	Build a trusted device and app foundation for AI at scale	Breakout
BRK322	Stay ahead of endpoint risk with AI-powered discovery and remediation	Breakout
BRK391	Manage and Govern AI Agents on Windows as Your Trusted Execution Layer	Breakout
LAB712	Strengthen endpoint protection from onboarding to offboarding	Lab
LAB711	Build an AI-Ready Secure Foundation with Zero Trust	Lab

Go deeper

The featured sessions set the direction. The following session and two hands-on labs go further into the work behind them.

Manage and Govern AI Agents on Windows as Your Trusted Execution Layer (BRK391)

As agents move into production, IT needs to know which ones are running, what each can reach, and who approves a change to what it does. See how Windows provides the environment agents run in, while Intune, Microsoft Entra, Microsoft Defender, and Microsoft Purview discover, secure, and audit those agents at scale.

Speakers: Daniel Ballard, Principal Product Manager, Windows, Jessica Yang, Senior Product Manager, Microsoft Intune

Strengthen endpoint protection from onboarding to offboarding (LAB712)

Configure endpoint security policies, target managed and Defender-connected devices, and check device posture. Then investigate an endpoint security issue, use Defender insights to prioritize the risk, and remediate the affected devices through Intune.

Speakers: Swapna Medi, Principal Software Engineering Manager, Microsoft Intune, Lorena Mora, Senior Product Manager, Microsoft Security

Build an AI-Ready Secure Foundation with Zero Trust (LAB711)

Assess your organization's security posture and apply Zero Trust principles across identities, devices, threats, and data. Work through strengthening access, reducing exposure, protecting sensitive information, and responding as conditions change.

Speakers: Jon Callahan, Senior Product Manager, Microsoft Security, Lorena Mora, Senior Product Manager, Microsoft Security

Related Windows and Microsoft Security sessions

Endpoint management delivers value across IT and security teams. These related sessions show how Intune connects with Windows and Microsoft Security to strengthen outcomes across the digital estate.

Breakout Code	Title
BRK405	Trust, Enforced: How Windows delivers security for the AI era
BRK407	What's new in Windows Management
BRK398	From Prevention to Recovery: Building a More Resilient Windows Estate
BRK339	Local agents are here. Can you find and secure them?
BRK327	See and reduce exposure across your digital estate
BRK323	Project Perception Roadmap: New Capabilities, Use Cases & What's Next

What ties these sessions together?

AI agents run on devices IT manages, use apps IT deploys, and act with access IT governs. That puts the endpoint at the center of moving AI from pilot to practice and connects this year’s Intune sessions: preparing the digital estate ready, governing agents that run on it, and turning security findings into verified change.

Questions that can't wait until November? Catch up on recent releases in our monthly “What's new in Microsoft Intune” posts on the Microsoft Intune Blog.

We'll share the Ignite news on the Microsoft Intune Blog during the event. Bookmark it and follow us on LinkedIn or @MSIntune on X to continue the conversation. We look forward to seeing you in San Francisco and online.

Session details are subject to change. Check the catalog for scheduling and attendance options.

New blog articles in Microsoft Community Hub

Built by experience: The journey to Azure Linux 4.0

A distribution is more than a collection of packages

Stay close to upstream - and make differences clear

Balance stability with a modern cloud platform

Built for cloud workloads

From Microsoft’s workloads to yours

The next chapter

Wolters Kluwer scales tax and accounting software with PostgreSQL on Azure

Looking for a more sustainable way to scale

Finding a path to horizontal scale

What we learned as an early adopter

Leaving weekly database troubleshooting behind

Preparing for the next doubling

SWOOP Analytics Festival 2026 | Viva Engage Edition

Choose the regional session that works for you

APAC | 12:00 PM–2:30 PM AEDT

EMEA | 9:00 AM–11:30 AM GMT / 10:00 AM–12:30 PM CET

AMER | 9:00 AM–11:30 AM PT / 12:00 PM–2:30 PM ET

Come ready to learn, ask questions, and swap ideas

Optimize selective analytics reads in Azure Data Lake Storage with ABFS Vectored Read

Why selective reads need coordinated I/O

How ABFS Vectored Read works

What this means for your workloads

Get started

Availability and resources

Build AI-powered apps without creating a vector database

Build enterprise apps without creating a document platform

Ground Copilot and agent experiences on enterprise content

How the Retrieval API works

Use natural language to build and manage apps with the Model Context Protocol server – now in public preview

Start building

What happens when attackers get AI too?

How might attackers use AI

How might AI affect familiar attacker behavior

What does an AI-powered attack actually look like

Bring us the hard questions

The fundamentals still matter

Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations

Written in collaboration with yuvalpery​ and Gunjan Jain​

Introduction

About the vulnerabilities:

Azure WAF protection

Azure Front Door WAF: managed rule

Application Gateway WAF: interim mitigation

Application Gateway for Containers (AGC):

For PHP workloads behind AGC, upgrading PHP is the recommended remediation. A WAF managed rule for AGC is expected to roll out at a later date.

Summary

Conclusion

Using PostgreSQL to reflect on its own history and code: introducing pghacker-mcp.dev

Ask PostgreSQL why

How it works

PostgreSQL turned out to be a great code search engine

A knowledge graph from the mailing list to the code

MCP is growing up fast

Skills: a server that teaches agents

Elicitation: a server that can talk to the user

Why I built it on Azure HorizonDB

In conclusion

Azure Content Understanding

Why this matters

The safe default: Content Understanding 1.0 GA

What the preview adds

A practical pipeline pattern

Production considerations

Decision guidance

Decision guide

Production checklist

Conclusion

Open-Weight Models in Microsoft Foundry

Why this matters

Use precise language

Four adoption paths

Decision criteria

Data residency and availability

Responsible AI and safety

Lifecycle and procurement risk

Recommended operating pattern

Decision guide

Production checklist

Written in collaboration with yuvalpery and Gunjan Jain