rss.livelink.threads-in-node

Production Cutover in Cloud-Native Migrations

dhruti — Thu, 16 Apr 2026 00:05:46 GMT

Migration Planning vs Runtime Reality

Migration to container orchestration platforms such as Azure Kubernetes Service (AKS) typically involves:

Containerizing application workloads
Configuring cluster networking
Migrating data to managed storage services
Updating application integrations
Validating deployment pipelines

Even with these practices in place, runtime validation often reveals issues that are not directly related to deployment or application code.

For example, it is common to encounter scenarios where:

Services deploy successfully but terminate under production memory allocation thresholds
Configuration repositories do not reflect region‑specific runtime parameters
Messaging consumers fail to bind to cloud‑based ingestion pipelines
External integrations continue referencing legacy endpoint mappings

These runtime discrepancies typically surface only after traffic routing begins — highlighting the distinction between deployment success and operational readiness.

Dependency Transition in Distributed Architectures

Modern enterprise workloads operate across multiple runtime layers:

Compute – Container orchestration policies
Networking – Firewall and endpoint routing
Messaging – Event stream synchronization
Storage – Listener configuration
Analytics – Workspace connectivity
Batch Processing – Scheduled ingestion continuity

In practice, this requires ensuring that all runtime dependencies transition in a coordinated manner.

For instance, a service deployment may succeed in production environments but fail to initialize if:

Storage listeners still reference legacy infrastructure
Analytics workspaces are restricted by updated networking policies
Configuration endpoints are not aligned with Disaster Recovery runtime

As system complexity increases, production cutover becomes less of a deployment task and more of a runtime orchestration challenge.

Disaster Recovery in Migration Execution

Production cutover workflows frequently include:

Regional database switchover
Storage endpoint failover
DNS routing updates
Suspension of compute resources in primary regions
Replica alignment in containerized workloads

Additionally, failback procedures must ensure that:

Primary workloads restart in the correct configuration state
Listener registries are reassigned without duplication
DNS routing reflects restored endpoints
RTO and RPO parameters are met
Smoke testing validates runtime stability

Batch Workloads and Background Processing

Batch pipelines often support:

Historical transactional ingestion
Scheduled synchronization tasks
Downstream analytics processing

Migrating these workloads without phased prioritization can result in:

Delayed ingestion cycles
Messaging queue desynchronization
Reporting inconsistencies

Ensuring continuity of background processing therefore becomes an essential component of production cutover planning.

Treating Cutover as an Orchestration Event

Production cutover must now be approached as a coordinated transition of system state across:

Compute
Data
Networking
Integration
Messaging
Batch execution
Security policies

This ensures that infrastructure provisioning is complemented by runtime alignment across all dependent system layers.

Section	What the Link Reinforces	Recommended Microsoft Learn Link
Production Cutover Definition	Establishes cutover as a distinct operational phase involving traffic redirection, validation, smoke testing, and post‑cutover checks—not just deployment completion.	How to cut over a cloud workload
End‑to‑End Migration Context	Positions cutover within the full migration lifecycle (plan → migrate → operate → govern), reinforcing that success continues post‑go‑live.	Microsoft Azure Migration Hub
AKS Migration Patterns	Shows that AKS migration success depends on runtime behavior, HA/BCDR planning, and workload characteristics—not just container deployment.	Migrate to Azure Kubernetes Service (AKS) Azure Kubernetes Service documentation

Conclusion

Cloud migration success is no longer determined solely by where applications are deployed, but by how effectively runtime dependencies are aligned during production cutover.

Databricks Delta Sharing: Enabling Cost Efficient Cross Cloud Data Access

kirankumar_manchiwar04 — Thu, 16 Apr 2026 00:00:42 GMT

What Is Delta Sharing?

Delta sharing is an open protocol for secure data sharing that allows organizations to share live data stored in Delta Lake with external consumers—across cloud providers such as Azure, AWS, and Google Cloud—while keeping the data in its original location. Consumers access the same up‑to‑date data without the provider having to copy or move it to another cloud.

Why Delta Sharing Matters in Multi‑Cloud Architectures

In multi‑cloud environments, data sharing typically leads to increased storage duplication and cross‑cloud data transfer charges. Delta Sharing changes this model by exposing data in place, enabling access rather than replication.

Key architectural benefits include:

Cross‑cloud data availability without replication
Data producers share tables directly from their existing data lake, eliminating the need for extract‑and‑load pipelines.
Reduced egress costs compared to copy‑based approaches
Since data is not duplicated by default, Delta Sharing avoids large-scale data movement that typically drives cloud egress charges. Egress occurs only when data is queried across clouds.
Secure and governed access
Access is managed using fine‑grained permissions, auditability, and centralized governance through Unity Catalog, ensuring shared data remains secure and compliant.
Vendor‑neutral and open
Consumers do not need to run Databricks. Delta Sharing supports multiple clients such as Spark, Pandas, and BI tools, making it suitable for heterogeneous analytics ecosystems.

Delta Sharing vs. Data Replication

A common misconception is that cross‑cloud analytics always require data replication. With Delta Sharing:

Live access is used for shared analytics and reporting use cases
Replication (deep clone) becomes an explicit design choice only when local copy or offline processing is required—rather than a default requirement

This gives architects the flexibility to optimize for cost, performance, or isolation depending on the workload, instead of paying replication costs upfront.

Figure: Databricks Delta Sharing Architecture:

Delta Sharing enables secure, real‑time data access across public clouds without replicating data. Consumers query data in place through a secure control plane, ensuring governance, reduced operational overhead, and optimized egress costs.

This diagram visually represents Databricks Delta Sharing architecture with a clear left‑to‑right flow that works well for blogs and technical readers:

Left – Data Producer (Azure Databricks + Unity Catalog + Delta Lake Storage)
Center – Delta Sharing Service (secure control plane, metadata & access control)
Right – Data Consumers (AWS / GCP / Spark / BI tools / Pandas)
Bottom flow – Read‑only, on‑demand access with no data replication and egress only on read

Architecture Diagram Explanation: Databricks Delta Sharing

Overview

The diagram illustrates how Databricks Delta Sharing enables secure, real‑time data access across public clouds (Azure, AWS, GCP) without replicating data, helping reduce operational overhead and data‑egress costs.

At a high level, data remains in the producer’s cloud storage, while consumers in other clouds access it securely on demand using the Delta Sharing protocol

1️⃣ Data Producer (Azure Databricks)

The Data Provider hosts curated datasets in a Delta Lake (for example, on Azure Data Lake Storage Gen2).
Data is governed using Unity Catalog, which controls:

Which tables are shared
Who can access them
What operations are allowed (read‑only access)

No data is copied or exported during sharing—datasets remain in the producer’s storage account.

2️⃣ Delta Sharing Service (Control Plane)

Delta Sharing acts as the secure control layer, not a data storage layer.
It manages:

Authentication and authorization of consumers
Metadata exchange (schemas, table versions)
Auditing and access tracking

The control plane ensures that only authorized consumers can discover and query shared datasets.

3️⃣ Secure Network Access

Consumers connect to the producer’s storage using HTTPS-based secure endpoints.
Depending on architecture:

Access may be public endpoint–based
Or secured further using private networking patterns (VPN, private endpoints, or controlled IP ranges)

All access occurs under the governance policies defined by the data producer.

4️⃣ Data Consumers (AWS / GCP / Azure)

Consumers may run:

Databricks on another cloud
Spark clusters
Python (Pandas)
BI and analytics tools that support Delta Sharing

Consumers query the data in place, directly from the producer’s Delta tables

Importantly, consumers do not need to copy or store the data locally unless they explicitly choose to.

5️⃣ Data Flow (Read‑Only, On‑Demand)

When a consumer runs a query:

Metadata is resolved via Delta Sharing
Data blocks are read directly from the producer’s cloud storage
Results are returned to the consumer

This “access‑instead‑of‑replicate” model avoids continuous data synchronization pipelines and minimizes unnecessary data movement.

6️⃣ Cost Optimization and Egress Considerations

No default data replication means:

No extra storage costs
No background sync jobs

Data egress charges occur only when data is actually read across clouds, not upfront or continuously.

Compared to traditional copy‑based sharing, this significantly reduces overall egress exposure for many analytics workloads

7️⃣ Optional: Local Replication (Explicit Choice)

If required, consumers can perform a deep clone to bring a local copy into their own cloud.
This is an explicit architectural decision, used only when:

Low‑latency local access is required
Data isolation is mandatory

Replication is optional — not a prerequisite for sharing.

Common Use Cases

Delta Sharing is particularly effective for:

Sharing curated datasets across cloud platforms
Enabling partner or third‑party analytics without data duplication
Supporting centralized data platforms while allowing decentralized consumption
Reducing operational overhead in cross‑cloud data ecosystems

Key Takeaway

Databricks Delta Sharing enables organizations to provide secure, real‑time cross‑cloud data access without data duplication—helping reduce operational complexity and egress costs in multi‑cloud architectures.

Upcoming changes to driver metadata and publishing validations in Hardware Dev Center

Cymoki — Wed, 15 Apr 2026 23:56:34 GMT

We're making improvements to how the Windows Hardware Dev Center (HDC) handles driver OS compatibility. These changes will help reduce driver installation failures caused by drivers being offered to Windows versions outside their supported range.

This post explains what's changing, what you need to know, and what — if any — action you may need to take.

What's changing

New field in HardwareDriverMetadata: CeilingOSCode

We are adding a new nullable string property, CeilingOSCode, to the per-PnP entries in the HardwareDriverMetadata asset (documented at Driver package metadata ). This field represents the maximum OS version that a given hardware ID (PnP) supports, as determined by the INF file's OS version decorators.

Note: The CeilingOsCode field will only be populated for packages submitted after the feature rollout date. Packages submitted before this date will not have this field in their metadata — it will not be backfilled for existing submissions.

If you use the Hardware Dev Center API to retrieve driver metadata — via Get a submission  (the driverMetadata link) or Create Publisher Metadata  — the OSPnPInfoMap entries in the response will now include this additional property.

Example — before:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null

}

Example — after:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null,

"CeilingOsCode": "WINDOWS_v100_X64_20H1_FULL"

}

Do I need to take action?

In most cases, no. This is an additive change. The new property is nullable — it will be null when no OS ceiling is detected for a hardware ID. Standard JSON parsers (including Newtonsoft.Json and System.Text.Json) handle new, unknown properties gracefully by ignoring them.

If your tooling uses strict JSON validation that rejects unknown properties, you may need to update your deserialization logic to allow the new CeilingOSCode field.

⚠️ Important: Avoid strict JSON parsing

The Hardware Dev Center API may add new properties to responses at any time as part of non-breaking, additive changes. Your client must not use strict JSON deserialization that rejects unknown properties.

- System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
- Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
- General — If you use schema validation or strict contracts, ensure they allow additional properties.

This applies to all Hardware Dev Center API responses, not just this change.

What CeilingOSCode means

When your INF file contains multiple OS-decorated [Manufacturer] sections, each hardware ID is only applicable within a specific OS range. The CeilingOSCode reflects the upper bound of that range — the first OS version where the hardware ID is no longer listed in the INF.

CeilingOsCode value	Meaning
"WINDOWS_v100_X64_20H1_FULL"	This hardware ID is supported up to but not including Windows 10 20H1 (build 19041) for x64
null	No upper bound detected — the hardware ID is supported on all OS versions from its floor onward
(field absent)	The package was submitted before the feature rollout and metadata has not been regenerated

Example

Consider an INF with two OS-decorated manufacturer sections:

[Manufacturer]

%MfgName% = Models, NTamd64.10.0...17763, NTamd64.10.0...25952

[Models.NTamd64.10.0...17763]

%DevDesc% = Install, PCI\VEN_8086&DEV_1234 ; present from build 17763

[Models.NTamd64.10.0...25952]

; PCI\VEN_8086&DEV_1234 is NOT listed here ; absent from build 25952 onward

In this case, PCI\VEN_8086&DEV_1234 is only applicable for OS builds in the range [17763, 25952). The CeilingOsCode for this hardware ID would reflect the upper bound of that range.

Rollout plan

Starting May 8, 2026, the HardwareDriverMetadata response will include the new CeilingOsCode field on each PnP entry in OSPnPInfoMap for packages submitted on or after that date. This field will not be backfilled — metadata for packages submitted before this date will remain unchanged and will not include CeilingOsCode.

Note: We plan to use this ceiling data to improve driver targeting accuracy on Windows Update. We will communicate those changes separately as they approach rollout.

What you should do now

Review your JSON parsing logic. If you consume HardwareDriverMetadata via the Hardware Dev Center API (as described in Driver package metadata ) and use strict schema validation, update your parser to accept the new CeilingOSCode property in OSPnPInfoMap entries.
No changes are required to your driver packages, INF files, or shipping labels at this time.
No resubmission is required, but if you want your existing packages to take advantage of the improved OS ceiling targeting, you should resubmit them after the rollout date. The CeilingOsCode field will only be populated for packages submitted on or after that date — metadata for previously submitted packages will not change unless resubmitted.

Questions or feedback?

If you have questions about these changes or encounter issues, please reach out through the support channel Support for Partner Center Dashboard - Windows drivers | Microsoft Learn.

Announcing Log Monitor v2.2.0 Release Candidate

Bob_Sira — Wed, 15 Apr 2026 23:50:34 GMT

We are excited to announce the release candidate for Log Monitor v2.2.0, now available on GitHub: LogMonitor v2.2.0

Log Monitor is an open-source tool that enables Windows containers to surface logs from multiple sources, Event Log, ETW providers, and log files, directly to the container's stdout, making them visible to container orchestrators like Kubernetes and Azure Container Apps.

What's New in v2.2.0

Replaced Boost.JSON with nlohmann/json

The most significant change in this release is the replacement of the Boost.JSON library with nlohmann/json, a lightweight, header-only C++ JSON library. This change:

Removes the heavy Boost dependency, reducing build complexity
Simplifies the vcpkg dependency management
Maintains full backward compatibility with existing configuration files

New AKS + IIS Example

We've added a complete end-to-end example for running Log Monitor with IIS on Azure Kubernetes Service (AKS), including deployment manifests and step-by-step documentation. This makes it easier to get started with log monitoring in production Kubernetes environments.

Bug Fixes

This release also includes a number of important bug fixes to the configuration file parser:

eventFormatMultiLine now correctly defaults to true when not specified in the config
waitInSeconds for File log sources is now correctly parsed (previously always used the 300s default)
Optional channel level now correctly defaults to Error when omitted, instead of causing a parse failure
Invalid log sources in a config file are now skipped gracefully — valid sources in the same file continue to be processed
Fixed a path traversal vulnerability in the /Config command-line argument
Reduced unnecessary error log noise for ERROR_NOT_SUPPORTED cases

Upgrading from v2.1.x

Upgrading to v2.2.0 is a drop-in replacement — no changes to your configuration files are required. The config file format is identical to v2.1.x.

To upgrade:

Replace LogMonitor.exe with the v2.2.0 binary in your container image
Run your existing LogMonitorConfig.json as-is — no edits needed
Test your container to confirm logs are still flowing as expected

If you were building from source, see the updated build instructions below — the build system has changed and the output path is different from v2.1.x.

Building from Source

The build system has been updated from a standalone Visual Studio solution to a CMake + vcpkg workflow. A single script handles everything:

.\build.cmd

This will automatically:

Clone vcpkg into the repo root
Bootstrap vcpkg and install nlohmann-json (downloaded on first run)
Configure the project with CMake using Visual Studio 2022
Build LogMonitor.exe and LogMonitorTests.dll in Release configuration

Prerequisites: Visual Studio 2022 with the C++ workload and Git must be on your PATH. No other dependencies need to be installed manually.

Output locations

Artifact	Path
LogMonitor.exe	LogMonitor\build\Release\LogMonitor.exe
LogMonitorTests.dll	LogMonitor\build\Release\LogMonitorTests.dll

Note for upgraders: In v2.1.x the binary was placed at LogMonitor\x64\Release\LogMonitor.exe. If you have a Dockerfile or CI script that copies the binary by path, update it to the new location above.

Example Configuration

Here is a basic LogMonitorConfig.json that monitors Windows Event Log, an ETW provider, and a log file — covering the three source types Log Monitor supports:

{
  "LogConfig": {
    "sources": [
      {
        "type": "EventLog",
        "startAtOldestRecord": false,
        "eventFormatMultiLine": false,
        "channels": [
          { "name": "System", "level": "Error" },
          { "name": "Application", "level": "Warning" }
        ]
      },
      {
        "type": "File",
        "directory": "C:\\inetpub\\logs\\LogFiles",
        "filter": "*.log",
        "includeSubdirectories": true,
        "waitInSeconds": 5
      },
      {
        "type": "ETW",
        "eventFormatMultiLine": false,
        "providers": [
          {
            "providerName": "IIS: WWW Server",
            "providerGuid": "{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}",
            "level": "5"
          }
        ]
      }
    ]
  }
}

This config is a great starting point. Drop it alongside LogMonitor.exe in your container image and adjust the channels, file paths, and ETW providers to match your application.

Improvements to CI/CD Pipelines

We've updated both the Azure DevOps and GitHub Actions SDL compliance pipelines to correctly install nlohmann/json via vcpkg before building, ensuring reliable builds across all CI environments.

Getting Started

You can download the release binaries in the repository.

To get started with Log Monitor, check out the documentation and the new IIS + AKS example.

Feedback

We'd love to hear from you! If you run into any issues or have suggestions, please open an issue on GitHub.

Guidance for Building Agents on the Microsoft Sentinel Platform

MitchellGulledge — Wed, 15 Apr 2026 23:29:13 GMT

As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Microsoft Sentinel data lake for the first time. I’ve written this article to walk you through one possible approach for agent development – the process I use when building sample agents internally at Microsoft. If you have questions about this, or other methods for building your agent, App Assure offers guidance through our Sentinel Advisory Service.

Throughout this post, I include screenshots and examples from Gigamon’s Security Posture Insight Agent.

This article assumes you have:

An existing SaaS or security product with accessible telemetry.
A small ISV team (2–3 engineers + 1 PM).
Focus on a single high value scenario for the first agent.

The Composite Application Model (What You Are Building)

When I begin designing an agent, I think end-to-end, from data ingestion requirements through agentic logic, following the Composite application model.

The Composite Application Model consists of five layers:

Data Sources – Your product’s raw security, audit, or operational data.
Ingestion – Getting that data into Microsoft Sentinel.
Sentinel data lake & Microsoft Graph – Normalization, storage, and correlation.
Agent – Reasoning logic that queries data and produces outcomes.
End User – Security Copilot or SaaS experiences that invoke the agent.

This separation allows for evolving data ingestion and agent logic simultaneously. It also helps avoid downstream surprises that require going back and rearchitecting the entire solution.

Read the full announcement here: Accelerate Agent Development: Hacks for Building with Microsoft Sentinel data lake

Original Publication: Microsoft Sentinel Blog, April 2nd, 2026

Exploring Agentic Uses Cases for Microsoft Sentinel

Sai_Marapareddy — Wed, 15 Apr 2026 23:21:24 GMT

Interested in building an agent with Sentinel platform solutions but not sure where to start? This blog will help you understand some common use cases for agent development that we’ve seen across our partner ecosystem.

SOC teams don’t need more alerts - they need fast, repeatable investigation and response workflows. Security Copilot agents can help orchestrate the steps analysts perform by correlating across the Sentinel data lake, executing targeted KQL queries, fetching related entities, enriching with context, and producing an evidence-backed decision without forcing analysts to switch tools.

Microsoft Sentinel platform is a strong foundation for agentic experiences because it exposes a normalized security data layer, an investigation surface based on incidents and entities, and extensive automation capabilities. An agent can use these primitives to correlate identity, endpoint, cloud, and network telemetry; traverse entity relationships; and recommend remediation actions.

Read the full announcement here: Agentic Use Cases for Developers on the Microsoft Sentinel Platform

Original Publication: Microsoft Sentinel Blog, March 20th, 2026

RSAC 2026: New Sentinel Connectors Announcement

JesseKopavi — Wed, 15 Apr 2026 23:13:52 GMT

Microsoft Sentinel helps organizations detect, investigate, and respond to security threats across increasingly complex environments. With the rollout of the Microsoft Sentinel data lake in the fall, and the App Assure-backed Sentinel promise that supports it, customers now have access to long-term, cost-effective storage for security telemetry, creating a solid foundation for emerging Agentic AI experiences.

Since our last announcement at Ignite 2025, the Microsoft Sentinel connector ecosystem has expanded rapidly, reflecting continued investment from software development partners building for our shared customers. These connectors bring diverse security signals together, enabling correlation at scale and delivering richer investigation context across the Sentinel platform.

Below is a snapshot of Microsoft Sentinel connectors newly available or recently enhanced since our last announcement, highlighting the breadth of partner solutions contributing data into, and extending the value of, the Microsoft Sentinel ecosystem...

Read the full announcement here: RSAC 2026: New Microsoft Sentinel Connectors Announcement

Original Publication: Microsoft Sentinel Blog, March 20th, 2026

Announcing the Sentinel Advisory Service

MikeAdams — Wed, 15 Apr 2026 23:12:01 GMT

At RSAC last year, we introduced the Microsoft Sentinel Promise with a straightforward commitment to our customers: that third-party data ingestion for Sentinel is reliable, predictable, and scalable without the need for complex custom coding and architecting. In other words, your connectors for Sentinel will just work. That promise has guided App Assure’s work ever since, enabling customers to bring data from across their various security solutions into Sentinel to drive clearer insights and stronger protection.

Over the past year, that foundation has proven critical. As organizations move from legacy SIEM platforms to Sentinel, consistent access to high-quality third-party data remains essential, not only for detection and response, but increasingly for advanced analytics and AI-driven security experiences. With the introduction of Microsoft Sentinel data lake, customers and partners can now reason over security data cost-effectively and at greater scale. But as many teams are discovering, unlocking those outcomes requires more than simply getting data in the door.

At App Assure, we’ve seen a clear pattern emerge. Software companies often revisit connector design and data modeling multiple times as they help our mutual customers move from ingestion to analytics, and then again as they begin building agentic AI solutions, whether through Security Copilot, MCP server integrations, or custom workflows. Each iteration brings new requirements and new questions, often upstream of where teams initially started.

That’s why, as an extension of our Sentinel Promise, we’re excited to announce the Sentinel Advisory Service from App Assure.

Read the full announcement here: Extending App Assure’s Sentinel Promise through the Sentinel Advisory Service

Original Publication: Microsoft Sentinel Blog, March 20th, 2026

Debugging the future of work: Microsoft 365 Community Conference 2026

JonJones_MSFT — Wed, 15 Apr 2026 22:48:47 GMT

Building in the era of AI can get very challenging. That’s exactly why we’re here to help you debug, refactor, and level up at the Microsoft 365 Community Conference, happening April 21–23, 2026 in Orlando, FL. Whether you’re a developer ready to scale your skillset or a power user looking to upgrade your formatting skills, walk away with practical tools you can use immediately. We've lined up hands-on sessions and interactive workshops to help you build intelligent, adaptable agents and solutions across the Microsoft ecosystem, and supercharge your Copilot journey.

Here’s what you’ll learn by attending the sessions:

Create custom agents for your company in Microsoft 365 Copilot

Custom agents are how you turn Copilot into your Copilot. The conference will cover how to design, secure, and deploy company-specific agents using Microsoft technologies like Copilot Studio, Microsoft Graph connectors, Entra ID, and Azure, and how to integrate them into Microsoft 365 experiences (Teams, SharePoint, and Outlook) with the Agent Toolkit and extensibility patterns. Expect practical guidance on grounding agents in enterprise data, enforcing permissions, and shipping them through your existing dev and governance processes.

Build smarter with SPFx

Want to build once and run everywhere across Microsoft 365? This is your blueprint. In the demo-driven sessions, you’ll build and ship a production-ready SPFx solution across SharePoint, Teams, Outlook, and Copilot, complete with theming, graph integration, and Entra-backed authentication. You’ll also pick up practical guidance on performance, accessibility, Application Lifecycle Management, and scaling from prototype to production. You’ll leave convinced and equipped that SPFx is the best path to building modern, scalable applications across the entire Microsoft 365 stack.

Hook into Azure DevOps

AI in Azure DevOps is a workflow upgrade. Learn how built-in capabilities ADO AI Chat and the Work Item Assistant help you automate repetitive tasks, improve backlog quality, and accelerate sprint velocity. reclaim engineering time, strengthen downstream effectiveness of code-centric tools like GitHub Enterprise and GitHub Copilot, and create a more efficient, AI-powered DevOps loop.

Adopt open-source tooling where suitable

Open-source and community tooling can help teams adopt established patterns and reduce custom implementation effort. The conference will cover how to evaluate and adopt community libraries, templates, and accelerators (for example, PnP tooling in the Microsoft 365 ecosystem) to reduce boilerplate, standardize common API and authentication approaches, and deliver solutions faster, while maintaining appropriate standards for security, maintenance, licensing, and long-term ownership.

Ready to put it into practice?

Branch out by attending hands-on workshops at the Microsoft 365 Community Conference to help you get out of your tech debt. Here’s a sneak peek at what you’ll build in the workshops:

SPFx Supercharged: Hands-on Bootcamp for Building SharePoint Solutions – 2026 edition with Beau Cameron, Chris Kent, David Warner, and Hugo Bernier
Develop Declarative Agents to Extend Microsoft 365 Copilot to Get the Most out of your Investment with Andrew Connell
Mission UX: Decoding the Science of User Experience in Microsoft 365 and Power Platform with David Warner and Hugo Bernier

Sessions:

Advanced List Formatting with Chris Kent
Bring Your Own Intelligence: Extending Microsoft 365 Copilot Agents with Azure AI and Microsoft Graph with Reshmee Auckloo
Building AI-Powered SharePoint Experiences with SPFx, Azure, and Your Own MCP Server with David Opdendries
Extending Microsoft 365 Copilot with Declarative Agents with Paolo Pialorsi and Vesa Juvonen
From Data to Decisions: How Copilot in VS Code Empowers Research and Enterprise Teams with Olesya Sarajlic and Semir Sarajlic
Getting Started with PnPjs with Julie Turner and Beau Cameron
How to Fake being an AI Expert: An Evil Consultant’s Guide to AI with Hugo Bernier
Inside Microsoft: Reclaiming Engineering Time with AI in Azure DevOps with Gopal Panigrahy and Apoorv Gupta
Manage your Microsoft 365 Tenant and Assets with Azure Runbooks and PnP PowerShell with Rodrigo Pinto
Navigating SharePoint Framework: Best Practices and Hidden Gems with Andrew Connell
Powerful Things: Defeating the Demogorgon of Power Apps Inconsistency with David Warner
Roundtable on the Next Wave of SPFx Investments on the Era of AI with Vesa Juvonen and Alex Terentiev
SPFx Unleashed: One Codebase for Enterprise, Host-Aware apps Across Microsoft 365 with Fabio Franzini
SharePoint knowledge Retrieval and Actions for your Apps with Copilot Studio + Microsoft Foundry with Patrick Rodgers and Yogesh Ratnaparkhi
Supercharge Copilot with Every Enterprise Document with Steve Pucelik and Shreyas Saravanan
The Power of App Builder’s Guide for Choosing the Right Path with April Dunnam
Understanding Copilot Agents: What to Use When with Paolo Pialorsi and Vesa Juvonen
Understanding Work IQ for Developers with Paolo Pialorsi

Join us at the Microsoft 365 Community Conference, happening April 21–23, 2026 in Orlando, FL.

Dissecting LLM Container Cold-Start: Where the Time Actually Goes

robcronin — Wed, 15 Apr 2026 22:38:11 GMT

Cold-start latency determines whether GPU clusters can scale to zero, how fast they can autoscale, and whether bursty or low-QPS workloads are economically viable. Most optimization effort targets the container pull path – faster registries, lazy-pull snapshotters, different compression formats. But “cold-start” is actually a composite of pull, runtime startup, and model initialization, and the dominant phase varies dramatically by inference engine. An optimization that cuts time-to-first-token for one engine can be irrelevant for another, even on identical infrastructure.

What we measured

We decomposed cold-start for two architecturally different engines – vLLM (Python/CUDA, heavy JIT compilation) and llama.cpp (C++, minimal runtime) – running Llama 3.1 8B on A100 GPUs. Every run starts from a completely clean slate: containerd stopped, all state wiped, kernel page caches dropped. No warm starts, no pre-pulling, no caching.

We break TTFT into three phases: pull (download + decompression + snapshot creation), startup (container start → server ready), and first inference (first API response, including model weight loading for engines that defer it). We tested across three snapshotters (overlayfs, EROFS, Nydus) with gzip and uncompressed images, pulling from same-region Azure Container Registry.

Setup

All experiments ran on an NVIDIA A100 80GB (Azure NC24ads_A100_v4), pulling from same-region Azure Container Registry. Images were built with AIKit, which produces ModelPack-compliant OCI artifacts with uncompressed model weight layers, Cosign signatures, SBOMs, and provenance attestations. These are supply chain properties you lose when model weights live on a shared drive.

vLLM: startup dominates, pull barely matters

vLLM loads model weights, runs torch.compile, captures CUDA graphs for multiple batch shapes, allocates KV cache, and warms up, all before serving the first request. This takes ~176 seconds regardless of how fast the image arrived.

The breakdown makes the bottleneck obvious: the green bar (startup) is nearly constant across all four variants, swamping any pull-time differences.

Figure 1: vLLM cold-start breakdown. Startup (green, ~176s) dominates regardless of snapshotter.

Method	Pull	Startup	1st Inference	TTFT
overlayfs (gzip)	140.8s ±5.5	176.0s ±3.2	0.16s	317.2s ±2.2
overlayfs (uncomp.)	129.9s ±3.3	180.8s ±12.2	0.16s	310.9s ±8.9
EROFS (gzip)	158.9s ±8.8	175.3s ±0.8	0.16s	334.4s ±8.7
EROFS (uncomp.)	166.3s ±21.1	177.3s ±12.8	0.16s	343.8s ±8.2

Llama 3.1 8B Q4_K_M, ~14 GB image, n=2–3 per variant. ± = sample standard deviation. Three of twelve runs hit intermittent NVIDIA container runtime crashes (exit code 120, unrelated to snapshotters) and were excluded. We excluded Nydus because FUSE-streaming the 14 GB Python/CUDA stack caused startup to exceed 900s. Steady-state inference: ~0.134s across all snapshotters.

44% pull, 56% startup. Dropping gzip saves 11 seconds on a 317-second cold start (1.02x). If your engine is vLLM, optimizing the pull pipeline is the wrong lever.

llama.cpp: pull dominates, compression is the bottleneck

llama.cpp has the opposite profile. Its C++ runtime starts in 2–5 seconds, so the pull becomes the majority of cold-start. This is where filesystem and compression choices actually matter.

Here the picture flips. Pull (blue) is the widest bar, and the gzip-to-uncompressed difference is visible at a glance:

Figure 2: llama.cpp cold-start breakdown. Pull time (blue) dominates for gzip variants.

Method	Pull	Startup	1st Inference	TTFT
overlayfs (gzip)	88.3s ±0.2	5.3s ±0.5	45.1s ±1.4	138.8s ±0.8
overlayfs (uncomp.)	56.3s ±3.1	2.0s ±0.0	44.2s ±0.1	102.4s ±3.1
EROFS (gzip)	92.0s ±2.3	6.1s ±0.5	44.0s ±0.2	142.3s ±1.9
EROFS (uncomp.)	58.8s ±0.6	2.0s ±0.0	44.0s ±0.1	104.8s ±0.5

Llama 3.1 8B Q4_K_M, ~8 GB image, n=3 per variant, 12/12 runs succeeded. First inference includes model weight loading into GPU VRAM (~43s) plus token generation (~1.5s). Steady-state inference: ~1.5s across all snapshotters.

64% pull, 4% startup, 33% model loading. Dropping gzip saves 32 seconds (1.35x) with zero infrastructure changes.

Engine comparison

Placed side by side, the two engines tell opposite stories about the same infrastructure:

Figure 3: Where cold-start time goes. vLLM is compute-bound; llama.cpp is pull-bound.

	vLLM	llama.cpp
Time saved by dropping gzip	11s (3% of TTFT)	32s (23% of TTFT)
Startup time	176–181s	2–5s
Speedup from dropping gzip	1.02x	1.35x

Same optimization, completely different impact. Before investing in pull optimization (compression changes, lazy-pull infrastructure, registry tuning), profile your engine’s startup. If startup dominates, the pull isn’t where the time goes.

Why gzip hurts: model weights are incompressible

The AIKit image is 8.7 GB uncompressed, 6.6 GB with gzip (a modest 0.76x ratio). But this ratio hides what’s really happening:

Layer type	Size	% of image	Gzip ratio
Model weights (GGUF)	4.9 GB	56%	~1.00x (quantized binary, no redundancy)
CUDA + system layers	~3.8 GB	44%	~0.46x (compresses well)

The GGUF file is already quantized to 4-bit precision. Gzip reads every byte, burns CPU, and produces output the same size as the input. You’re paying full decompression cost on 56% of the image for zero size reduction.

Bottom line: gzip is doing real work on less than half your image and producing zero savings on the rest. Dropping it costs nothing and removes a bottleneck from every cold start.

The Nydus prefetch finding

If decompression is the bottleneck, what about skipping the full pull entirely?

Nydus lazy-pull takes a fundamentally different approach: it fetches only manifest metadata during “pull” (~0.7s), then streams model data on-demand via FUSE as the container reads it. Nydus TTFT isn’t directly comparable to the full-pull methods above because the download cost shifts from the pull column to the inference column.

With prefetch enabled, Nydus achieved 77.8s TTFT for llama.cpp vs 139.1s for overlayfs gzip. The critical detail is the prefetch_all flag:

Figure 4: Nydus prefetch ON vs OFF. One config flag, 2.87x difference. Overlayfs gzip shown as baseline.

Configuration	1st Inference	TTFT
Nydus, prefetch ON	72.4s ±0.6	77.8s ±0.5
Nydus, prefetch OFF	218.6s ±2.9	223.4s ±2.9
overlayfs gzip (baseline)	44.0s ±0.4	139.1s ±1.9

n=3 per config, 9/9 runs succeeded. Data: 03-prefetch-config-20260401-030725.csv

One flag in nydusd-config.json, 2.87x difference. Without prefetch, every model weight page fault fires an individual HTTP range request to the registry. With prefetch_all=true, Nydus streams the full blob in the background while the container starts, so chunks arrive ahead of the GPU’s read pattern.

Even with prefetch, Nydus first inference is ~28s slower than overlayfs (72s vs 44s) due to FUSE kernel-user roundtrips during model mmap. Nydus wins on total TTFT because it eliminates the blocking pull, but this overhead means its advantage shrinks on faster networks.

Bottom line: Nydus lazy-pull can halve cold-start for pull-bound engines, but only if prefetch is on. Treat prefetch_all=true as a hard requirement, not a tuning knob.

How to apply these findings

Pick your optimization by engine type

The right optimization depends on where your engine spends its cold-start time. This table summarizes the tradeoffs:

Engine type	Dominant phase	Speedup from dropping gzip	Nydus viable?	Best optimization	What NOT to optimize
vLLM / TensorRT-LLM	Startup (56%)	1.02x — negligible	No — FUSE + Python/CUDA stack exceeded 900s in our tests	Cache torch.compile artifacts and CUDA graphs	Pull pipeline (it’s <44% of TTFT and already fast enough)
llama.cpp / ONNX Runtime	Pull (64%)	1.35x — 32s saved	Yes, with prefetch_all=true (77.8s TTFT vs 139s gzip baseline)	Drop gzip on weight layers; consider lazy-pull on slow links	Startup (already 2–5s; no room to improve)
Large dense models (70B+)	Pull (projected)	>1.35x — scales with image size	Yes, strongest case for lazy-pull	Uncompressed or zstd; Nydus prefetch on bandwidth-constrained links	—

Recommendations

Profile your engine’s startup before touching the pull pipeline. If CUDA compilation dominates (vLLM, TensorRT-LLM), no amount of pull optimization will help. Cache torch.compile artifacts and CUDA graphs instead — production clusters that do this reduce vLLM restarts to ~45–60s.
Drop gzip on model weight layers. For pull-bound engines (llama.cpp, ONNX Runtime), this is the single highest-ROI change: build with --output=type=image,compression=uncompressed, or use AIKit, which defaults to uncompressed weight layers. Quantized model weights (GGUF, safetensors) are already dense binary — gzip burns CPU for a ~1.00x compression ratio on 56% of the image.
If using Nydus, set prefetch_all=true. Without it, every weight page fault triggers an individual HTTP range request and cold-start is 2.87x slower. This is a single flag in nydusd-config.json.
Package models as signed OCI artifacts, not volume mounts. Three CNCF projects implement this pipeline end-to-end: ModelPack defines the OCI artifact spec (model metadata, architecture, quantization format). AIKit builds ModelPack-compliant images with Cosign signatures, SBOMs, and provenance attestations — supply chain guarantees you lose when weights live on a shared drive. KAITO handles the Kubernetes deployment: GPU node provisioning, inference engine setup, and API exposure. Together they cover packaging → build → deploy, and they produce the exact image layout these benchmarks measured.

Why this matters: the cost of cold-start

On an A100 node (~$3–4/hr on major clouds), a 5-minute vLLM cold start burns ~$0.30 in idle GPU time per pod. That sounds small until you multiply it: a cluster that scales 50 pods to zero overnight and restarts them each morning wastes ~$15/day — over $5,000/year — on GPUs sitting idle during pull and CUDA compilation. More critically, cold-start latency determines whether scale-to-zero is feasible at all. If cold-start exceeds your SLO (say, 30s for an interactive app), you’re forced to keep warm replicas running 24/7, which can 2–3x your GPU spend. Cutting llama.cpp cold-start from 139s to 103s by dropping gzip doesn’t just save 36 seconds — it moves the needle on whether autoscaling is viable for your workload.

What this doesn’t cover

zstd compression: decompresses 5–10x faster than gzip; containerd supports it natively. The most obvious gap in this analysis.
Pre-pulling and caching: production clusters pre-pull images and cache CUDA graphs, reducing vLLM restarts to ~45–60s. We measure the cold case: scale-from-zero events and first-time deployments.
Volume-mounted weights: skips the pull entirely, but loses supply chain properties (signing, scanning, provenance).
Larger models (70B+): pull would dominate more, increasing the gzip penalty.
Sample size: n=3 per AIKit variant, n=2–3 per vLLM variant. The gzip finding for llama.cpp is statistically significant (Welch’s t-test, p=0.0014, Cohen’s d=16.3; verification script). Other comparisons are directional.

Reproduce it

Scripts and raw data: erofs-repro-repo. Data for this post: 02-aikit-five-way-20260401-004716.csv and 01-vllm-four-way-20260331-113848.csv. Full analysis: technical report.

Weekly Roundup for Skilling Rooms (Groups)

AmyCloud — Wed, 15 Apr 2026 22:20:03 GMT

Hello Skills Hub Community! Below is a summary of what is happening within our Skilling Rooms (Groups) so that you can stay in the loop and discover something new. To get frequent updates of their content, make sure to follow/join the group that interests you.

Find the full list of our Skilling Rooms (Groups) here: Skilling Room Directory

Skilling Room	Details	Date/Time	Link to post
Azure Cloud Commanders	Event: Global Azure ANZ	Friday, Apr 17, 2026, 02:00 PM PDT	Global Azure ANZ 2026 \| Microsoft Community Hub
The Fabric Café	Event: FabCon + SQLCon 2026 Recap: What's New in Microsoft Fabric	Wednesday, Apr 22, 2026, 06:00 PM PDT	FabCon + SQLCon 2026 Recap: What’s New in Microsoft Fabric \| Microsoft Community Hub
Azure Cantonese Hub 粵語台	Discussion: AI Agents 時代正式開始 — 你準備好未？		AI Agents 時代正式開始 — 你準備好未？ \| Microsoft Community Hub
Copilot & Power Platform with Rishona	Discussion: Agent Builder: Build an agent that follows your communication guidelines		https://techcommunity.microsoft.com/discussions/6435049c-3220-41f1-b619-8e0440cd562b/agent-builder-build-an-agent-that-follows-your-communication-guidelines/4506594
The Fabric Café	Weekly #FabricCoffee sessions at Microsoft Fabric Cafe		https://www.youtube.com/@MicrosoftFabricCafe

Simplified controls for managing external collaboration in Teams admin center

angelamsft — Wed, 15 Apr 2026 21:48:31 GMT

We know that collaboration with customers, vendors, and partners outside of your small or medium business is critical to your success. We also know that many SMBs have limited IT admin resources, and setup can be a challenge.

To make external collaboration setup in Microsoft Teams easier for your SMB, we have introduced a new overview page in Teams admin center that consolidates settings into a single view and have simplified how we describe the settings you can apply.

From the new settings, you can select from pre-configured modes that quickly set smart defaults that are right for your business.

If your business is open to external collab across chats, calls, meetings, and teams and channels, you can select Open mode to quickly get setup
If your business is more conservative, you can select Controlled to align to pre-existing external collab defaults
If you want full control of what is enabled and disabled for your business, you can always select Custom as well

We're looking forward to hearing your feedback about the new settings experience.

Learn more about how you can use these settings, Unified external collab settings management

Save the date for Agent 365 live AMA

Nichole_Peterson — Wed, 15 Apr 2026 21:34:06 GMT

Microsoft Agent 365--generally available May 1, 2026--is a control plane that empowers IT admins, Security Operations analysts, Identity and Network Security admins, and Data Security & Compliance admins to observe, govern, and secure all agents for their organization.

We’ll demonstrate how to get started and answer your questions about licensing and functionality in this live 'Ask Microsoft Anything' with product and engineering team experts!

How to Participate

Register for the Microsoft Tech Community using your email if you haven’t already. This allows you to post comments and ask questions.
Visit the event page now to add the AMA to your calendar, RSVP, and submit questions via the comment area.
Watch the session live or catch the recording on demand after the event.

Hope to see you there! Come ready to learn and ask our experts all of your burning questions!

Best regards,

Nichole

Enforce Cost Limits on KQL Queries and Notebooks in the Microsoft Sentinel Data Lake

shubh_khandhadia — Wed, 15 Apr 2026 20:26:56 GMT

Security teams face a constant tension: run the advanced analytics you need to stay ahead of threats, or hold back to keep costs predictable. Until now, Microsoft Sentinel let you set alerts to get notified when data lake usage approached a threshold — useful for awareness, but not enough to prevent budget overruns.

Today, we're excited to announce threshold enforcement for KQL queries and notebooks in the Microsoft Sentinel data lake. With this release, you can go beyond notifications and automatically block new queries and jobs when your configured usage limits are exceeded. Your analysts keep working confidently, and your budgets stay protected.

What's new

Previously, the Configure Policies experience in Microsoft Sentinel let you set threshold-based alerts for data lake usage. You'd receive an email notification when consumption approached a limit — but nothing stopped usage from continuing past that point.

Now, you can enable enforcement on those same policies. When enforcement is turned on and a threshold is exceeded, Microsoft Sentinel blocks new queries, jobs, and notebook sessions with a clear "Limit exceeded" error. No more surprise cost spikes from runaway queries or analysts who mistakenly run heavy workloads against data lake data.

Enforcement is supported for two data lake capability categories:

Data Lake Query — interactive KQL queries and KQL jobs (scheduled and ad hoc)
Advanced Data Insights — notebook runs and notebook jobs

How it works

Consistent controls across KQL queries and notebooks

Cost controls are enforced consistently across Sentinel data lake workloads, regardless of how analysts access the data. The same policy applies whether someone is running a quick investigation or executing a long-running job.

Controls apply to:

Interactive KQL queries in the data lake explorer in the Defender portal
KQL jobs, including scheduled and ad-hoc jobs
Notebook queries run through the Microsoft Sentinel VS Code extension
Notebook jobs running as background or scheduled workloads

This ensures advanced analytics remain powerful — but predictable and governed.

Clear enforcement without disruption

Enforcement is applied at execution and validation boundaries — not retroactively. This means:

Queries or jobs already running are not interrupted. In-flight work completes normally.
New queries, jobs, or notebook sessions are blocked once limits are exceeded.
Failures occur early (for example, during validation), avoiding wasted compute.

From an analyst's perspective, enforcement is explicit and consistent. Clear messaging appears in query editors, job validation responses, and notebooks when limits are reached — so your team always understands what happened and what to do next.

How to set it up

Prerequisites

To configure enforcement policies, ensure you have the necessary permissions that are outlined here: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn.

Where to access

Navigate to Microsoft Sentinel > Cost management > Configure Policies in the Microsoft Defender portal (https://security.microsoft.com).

Step-by-step configuration

In Microsoft Sentinel > Cost management, select Configure Policies.
Select the policy you want to edit (Data Lake Query or Advanced Data Insights).
Enter the total threshold value for the policy.
Enter an alert percentage to receive email notifications before the threshold is reached.
Enable the Enforcement toggle to block usage after the threshold is exceeded.
Review your settings and select Submit.

Once enforcement is active, administrators receive advance notifications as usage approaches the threshold. If circumstances change — for example, during an active breach — you can adjust the threshold, disable enforcement temporarily, or modify the policy to give your SOC the room it needs to respond without being blocked.

Real-world scenario: Preventing unexpected cost spikes

Consider a large SOC that ingests roughly 6 TB of data per day, with 1 TB going to the Sentinel Analytics tier and the remaining 5 TB going to the Sentinel data lake. Analysts are proactively hunting for threats, performing investigations, and running automation. Tier 3 analysts are also running Jupyter Notebooks against the Sentinel data lake to build graphs, execute queries, and automate incident investigation and remediation with code.

Last month, the SOC experienced a cost spike after a newly hired analyst ran large, frequent queries against data lake data — mistakenly thinking it was Analytics tier. The SOC manager needs to prevent this from happening again.

With enforcement now available, the SOC manager can navigate to Microsoft Sentinel > Cost management > Configure Policies in the Defender portal and set up two policies:

A Data Lake Query policy to cap data processing for KQL queries

An Advanced Data Insights policy to cap notebook compute consumption

With these policies in place, the SOC manager gets notified in advance when consumption approaches the threshold while having confidence that the thresholds set will be enforced to prevent unexpected consumption and cost. Analysts can continue their day-to-day work without worrying about accidental overages. Should a breach scenario demand more capacity, the SOC manager can quickly adjust or temporarily disable the policies — keeping the team unblocked while maintaining overall budget governance. Outside of a breach scenario, should the same SOC analyst generate large amounts of data scanned, the threshold will take action and prevent queries from being performed.

Learn more

With enforceable KQL and notebook guardrails, Microsoft Sentinel data lake helps security teams scale advanced analytics with confidence. You can control usage in production and keep investigations moving — without tradeoffs between visibility, analytics, and budget.

To get started, visit the documentation: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn

We'd love to hear your feedback. Share your thoughts in the comments below or reach out through your usual Microsoft support channels.

Outlook for Android no longer grouping contact info...

Userzero — Wed, 15 Apr 2026 20:25:01 GMT

I just started having an odd issue with all the contacts in the Outlook app on my Android phone...

For contacts that have multiple contact information (ie: a mobile number, house number, and or email address) listed, the app is breaking out the contacts as separate contacts.

Example: If I have James Kirk listed in my phone with a number of 555-111-1701 and an email address as jkirk@fakedomain, he no longer shows up on my phone as James Kirk; instead there are two contacts - one called 555-111-1701 and the other jkirk@fakedomain.

Contacts show up correctly in the Outlook desktop app and on the Outlook website.

If I modify or add contacts on the desktop app, the change is almost immediately reflected on the Outlook website.

Some of the troubleshooting I've done already:

Cleared the app cache from the Phone's settings
Reset the account from within the app
disabled/re-enabled contact synchronization
Modified a contact on the desktop app to see if they'd re-sync correctly - had no effect
Deleted the account (the contacts disappear when deleted, but come back janky when it's re-added)
Uninstalled and re-installed the app
Rebooted the phone (for good measure)

uninstalling and re-installing the app seemed to fix the problem initially. Right when i setup the app again all the contacts came back looking correct. It's been several hours since I did this and i just took a look at my contact list and it's all janky again.

It's not just a visual issue on the phone - it's affecting Contact synchronization with the phone's contact app, and everything else on the phone that relies on contacts.

Any idea what's going on and how to fix it for good?

TIA

March 2026 Recap: Azure Database for PostgreSQL

gauri-kasar — Wed, 15 Apr 2026 18:58:45 GMT

Hello Azure community,

March was packed with major feature announcements for Azure Database for PostgreSQL. From the general availability of SSDv2, cascading read replicas, to online migration and new monitoring capabilities for logical replication slots to help ensure slots are preserved, this update brings a range of improvements to performance, scale, and reliability.

Features

SSDv2 - Generally Available
Cascading Read replica - Generally Available
Online migration using PgOutput plugin - Generally Available
Google AlloyDB as a migration source - Generally Available
EDB Extended Server as a migration source - Generally Available
Logical replication slot synchronization metrics - Preview
Defender Security Assessments - Preview
New enhancements in the PostgreSQL VS Code Extension
Latest PostgreSQL minor versions: 18.3, 17.9, 16.13, 15.17, 14.22
New extension support for PostgreSQL 18 on Azure Database for PostgreSQL
Guide on PostgreSQL Buffer Cache Analysis, query rewriting and elastic clusters

SSDv2 - Generally Available

Premium SSD v2 is now generally available for Azure Database for PostgreSQL Flexible Server, delivering significant performance and cost-efficiency improvements for I/O‑intensive workloads. It offers up to 4× higher IOPS, lower latency, and improved price‑performance.

With independent scaling of storage and performance, you only pay for what you need. Premium SSD v2 supports storage scaling up to 64 TiB, with performance reaching 80,000 IOPS and 1,200 MiB/s throughput, without tying performance to disk size. IOPS and throughput can be adjusted instantly, with no downtime.

Additionally, built‑in baseline performance at no additional cost ensures consistent performance even for smaller deployments, making Premium SSD v2 a strong choice for modern, high‑demand PostgreSQL applications.

For details about the Premium SSD v2 release, see the GA Announcement Blog and documentation

Cascading read replica - Generally available

Cascading read replicas are now generally available, giving customers greater flexibility to create read replicas from existing read replicas. This capability supports up to two levels of replication and up to 30 read replicas in total, with each read replica able to host up to five cascading replicas.

With cascading read replicas, you can more effectively distribute read traffic across multiple replicas, deploy regional or hierarchical read replicas closer to end users, reduce read latency, and improve overall query performance for read‑heavy workloads. In addition, we’ve rolled out switchover support for both intermediate and cascading read replicas, making it easier to manage replica topologies. Learn more about cascading read replicas through our documentation and a detailed blog walkthrough.

Online migration using PgOutput plugin - Generally Available

The new addition of the PgOutput plugin helps make your Online migration to Azure more robust and seamless. The native "Out-of-the-Box" support that PgOutout offers is more suited for Online Production migrations compared to other logical decoding plugins. PgOutput offers higher throughput and superior performance compared to other logical decoding plugins ensuring your Online migration has very limited downtime. PgOutput also offers fine-grained filtering using Publications where you can migrate specific tables and filter by specific operations.

For more details about this update, see the documentation.

Google AlloyDB as a migration source - Generally Available

Google AlloyDB is now supported as a source in Azure Database for PostgreSQL Migration Service. You can use this capability to migrate your AlloyDB workloads directly to Azure Database for PostgreSQL, using either offline or online migration options. This support helps you move your PostgreSQL databases to Azure with confidence, while taking advantage of Azure’s flexibility and scalability.

To know more about this feature, visit our documentation.

EDB Extended Server as a migration source - Generally Available

Azure Database for PostgreSQL Migration Service now supports EDB Extended Server as a migration source. This enables you to migrate EDB Extended Server workloads to Azure Database for PostgreSQL using both offline and online migration methods. With this addition, you can transition PostgreSQL databases to Azure smoothly and benefit from the scale and flexibility of the Azure platform.

For more details about this update, see the documentation.

Logical replication slot sync status metric - Preview

You can now monitor whether your logical replication slots are failover‑ready using the new logical_replication_slot_sync_status metric, now in preview. This metric provides a simple binary signal indicating whether logical replication slots are synchronized across High availability (HA) primary and standby nodes. It helps you quickly assess failover readiness without digging into replication internals especially valuable for CDC pipelines such as Debezium and Kafka, where data continuity during failover is critical.

Learn more about logical replication metrics in the documentation.

Defender Security Assessments - Preview

In March, we introduced two new Microsoft Defender for Cloud CSPM security recommendations for Azure Database for PostgreSQL Flexible Server, now available in public preview:

Geo-redundant backups should be enabled for PostgreSQL Servers
require_secure_transport should be set to "on" for PostgreSQL Servers

These integrated assessments continuously evaluate database configuration settings against security best practices, helping customers proactively identify and manage security posture risks for their Azure PostgreSQL servers while maintaining alignment with internal and industry standards.

Additional security posture assessments for Azure PostgreSQL will be introduced as they become available.

To learn more, refer to the reference table for all data security recommendations in Microsoft Defender for Cloud.

New enhancements in the PostgreSQL VS Code Extension

The March release (v1.20) of the PostgreSQL VS Code extension delivers new server management capabilities, enhanced query plan analysis, visual improvements, and a batch of bug fixes.

Clone Server: You can now clone an Azure PostgreSQL Flexible Server directly from within the extension. The clone operation is available from the server management UI, allowing you to duplicate a server configuration including region, SKU, and settings without leaving VS Code.
Entra ID Authentication for AI-Powered Schema Conversion: The Oracle-to-PostgreSQL migration experience now supports Microsoft Entra ID authentication for Azure OpenAI connectivity, replacing API key–based authentication. This enables enterprise-grade identity management and access control for AI-powered schema conversion workflows.
Query Plan Visualization Improvements: The Copilot-powered “Analyze with Copilot” feature for query plans has been improved with more relevant optimization recommendations and smoother SQL attachment handling during plan analysis.
Apache AGE Graph Visualizer Enhancements: The graph visualizer received a visual refresh with modernized edge rendering, a color-coded legend, and a new properties pane for exploring element details.
Object Explorer Deep Refresh: The Object Explorer now supports refreshing expanded nodes in place, so newly created tables and objects appear immediately without needing to disconnect and reconnect.
Settings Management: The extension now supports both global user settings and local .vscode/settings.json, providing more robust connection settings management across configuration sources.
Bug Fixes: This release includes numerous bug fixes across script generation (DDL for triggers, materialized views, and functions), IntelliSense (foreign table support), JSON data export, query execution, and server connectivity.

Latest PostgreSQL minor versions: 18.3, 17.9, 16.13, 15.17, 14.22

Azure PostgreSQL now supports the latest PostgreSQL minor versions: 18.3, 17.9, 16.13, 15.17, and 14.22. These updates are applied automatically during planned maintenance windows, ensuring your databases stay up to date with critical fixes and reliability improvements, with no manual action required. This is an out-of-cycle release that addresses regressions identified in the previous update. The release includes fixes across replication, JSON functions, query correctness, indexing, and extensions like pg_trgm, improving overall stability and correctness of database operations.

For details about the minor release, see the PostgreSQL announcement.

New extension support for PostgreSQL 18 on Azure Database for PostgreSQL

Azure Database for PostgreSQL running PostgreSQL 18 now supports extensions that enable graph querying, in‑database AI integration, external storage access, and scalable vector similarity search, expanding the types of workloads that can be handled directly within PostgreSQL.

Newly supported extensions include:

AGE (Apache AGE v1.7.0): Adds native graph data modeling and querying capabilities to PostgreSQL using openCypher, enabling hybrid relational–graph workloads within the same database.
azure_ai: Enables direct invocation of Microsoft Foundry models from PostgreSQL using SQL, allowing AI inference and embedding generation to be integrated into database workflows.
azure_storage: Provides native integration with Azure Blob Storage, enabling PostgreSQL to read from and write to external storage for data ingestion, export, and hybrid data architectures.
pg_diskann: Introduces disk‑based approximate nearest neighbor (ANN) indexing for high-performance vector similarity search at scale, optimized for large vector datasets with constrained memory.

Together, these extensions allow PostgreSQL on Azure to support multi-model, AI‑assisted, and data‑intensive workloads while preserving compatibility with the open‑source PostgreSQL ecosystem.

Guide on PostgreSQL buffer cache analysis, query rewriting

We have rolled out two new blogs on PostgreSQL buffer cache analysis and PostgreSQL query rewriting and subqueries. These blogs help you better understand how PostgreSQL behaves under the hood and how to apply practical performance optimizations whether you’re diagnosing memory usage, reducing unnecessary disk I/O, or reshaping queries to get more efficient execution plans as your workloads scale.

PostgreSQL Buffer Cache Analysis

This blog focuses on understanding PostgreSQL memory behavior through shared_buffers, the database’s primary buffer cache. Using native statistics and the pg_buffercache extension, it provides a data‑driven approach to evaluate cache efficiency, identify when critical tables and indexes are served from memory, and detect cases where disk I/O may be limiting performance. The guide offers a repeatable methodology to support informed tuning decisions as workloads scale.

PostgreSQL Query Rewriting and Subqueries

This blog explores how query structure directly impacts PostgreSQL execution plans and performance. It walks through common anti‑patterns and practical rewrites such as replacing correlated subqueries with set‑based joins, using semi‑joins, and pre‑aggregating large tables to reduce unnecessary work and enable more efficient execution paths. Each scenario includes clear explanations, example rewrites, and self‑contained test scripts you can run.

Azure Postgres Learning Bytes 🎓

How to create and store vector embeddings in Azure Database for PostgreSQL

Vector embeddings sit at the core of many modern AI applications from semantic search and recommendations to RAG‑based experiences. But once you generate embeddings, an important question follows: how do you generate and store them in your existing database server?

With Azure Database for PostgreSQL, you can generate and store vector embeddings directly alongside your application data. By using the `azure_ai` extension, PostgreSQL can seamlessly integrate with Azure OpenAI to create embeddings and store them in your database. This learning byte walks you through a step‑by‑step guide to generating and storing vector embeddings in Azure Database for PostgreSQL.

Step 1: Enable the Azure AI extension

Azure Database for PostgreSQL supports the azure_ai extension, which allows you to call Azure OpenAI service.

Connect to your database and run:

CREATE EXTENSION IF NOT EXISTS azure_ai;

Step 2: Create (or use existing) Azure OpenAI resource

You need an Azure OpenAI resource in your subscription with an embedding model deployed.

In the Azure portal, create an Azure OpenAI resource.
Deploy an embedding model (for example, text-embedding-3-small).

Azure OpenAI provides the endpoint URL and API key

Step 3: Get endpoint and API key

Go to your Azure OpenAI resource in the Azure portal.
Select Keys and Endpoint.
Copy:
- Endpoint
- API Key (Key 1 or Key 2)

Step 4: Configure Azure AI extension with OpenAI details

Store the endpoint and key securely inside PostgreSQL

SELECT azure_ai.set_setting( 'azure_openai.endpoint', 'https://<your-endpoint>.openai.azure.com' ); SELECT azure_ai.set_setting( 'azure_openai.subscription_key', '<your-api-key>' );

Step 5: Generate an embedding

SELECT LEFT( azure_openai.create_embeddings( 'text-embedding-3-small', 'Sample text for PostgreSQL Lab' ):: text, 100 ) AS vector_preview;

Step 6: Add a vector column

Add a vector column to store embeddings (example uses 1536‑dimensional vectors):

ALTER TABLE < table - name > ADD COLUMN embedding VECTOR(1536);

Step 7: Store the embedding

Update your table with the generated embedding:

UPDATE < table - name > SET embedding = azure_openai.create_embeddings( 'text-embedding-3-small', content );

Conclusion

That’s a wrap for our March 2026 recap. This month brought a set of meaningful updates focused on making Azure Database for PostgreSQL more performant, reliable, and scalable whether you’re modernizing workloads, scaling globally, or strengthening your security posture.

We’ll be back soon with more exciting announcements and key feature enhancements for Azure Database for PostgreSQL, so stay tuned! Your feedback is important to us, have suggestions, ideas, or questions? We’d love to hear from you: https://aka.ms/pgfeedback.

Phase 2 of Kerberos RC4 hardening begins with the April 2026 Windows security update

ChrisWright — Wed, 15 Apr 2026 18:42:48 GMT

Windows updates released in April 2026 and later begin the second deployment phase of protections designed to address a Kerberos information disclosure vulnerability (CVE‑2026‑20833). This second phase continues the shift away from legacy encryption types such as RC4 by moving toward stronger default ticket behavior. After installing the April 2026 update, domain controllers default to supporting Advanced Encryption Standard (AES‑SHA1) encrypted tickets for accounts that do not have an explicit Kerberos encryption type configuration.

If your organization relies on service accounts or applications that depend on RC4-based Kerberos service tickets, now is the time to address those dependencies to avoid authentication issues before the Enforcement phase begins in July 2026. Microsoft recommends continuing to monitor the System event log for Kerberos-related audit events and identify and address misconfigurations or remaining dependencies, then enabling enforcement when warning, blocking, or policy events are no longer logged.

See How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 and CVE‑2026‑20833 to learn more about the vulnerability, timelines, recommended preparation steps, and configuration options to ensure compliance before Enforcement mode begins in July 2026.

When the shield becomes the sword: How misconfigured PAM bridges the tiering model

UgurTGudekli — Wed, 15 Apr 2026 18:34:46 GMT

In the world of identity security, few tools promise as much peace of mind as Privileged Access Management (PAM). It is often referred to as the "vault" that locks away your kingdom's keys. However, in Microsoft Incident Response – the Detection and Response Team (DART) engagements, we frequently encounter a paradox: the tool used to secure Tier 0 often becomes a quick path for threat actors to compromise it.

In a recent DART engagement, a threat actor moved from a compromised helpdesk workstation to full domain compromise in under four hours. They didn't use a zero-day. They used the organization's PAM server.

We have seen this story play out in real-time. An organization invests heavily in Active Directory (AD) Tiering and a premium PAM solution. They feel secure. Yet, during an incident, we trace the threat actor’s path and find they didn't burn a zero-day or crack a complex algorithm. They simply walked across a bridge the organization built themselves: a PAM server positioned in Tier 1 that held the keys to Tier 0.

This isn't a failure of the product; it's a failure of positioning. This post shares what DART sees on the front lines, why "intermediaries" are the most critical link in your chain, and how to deploy PAM without rolling out a red carpet for threat actors.

The foundation: A quick refresher on tiering model and PAM, PIM, and PAW concepts

Before we dive into the threat actor’s tactics and techniques, let’s revisit the ground rules and define a few key concepts. The Active Directory Tiering Model is built on a simple premise: prevent credential theft propagation; ensuring that credentials with administrative access to higher-tier systems are never exposed on lower-tier systems where a threat actor may already have a foothold.

Tier 0 is your control plane: Domain Controllers, PKI, and the identities that manage your authentication plane.

Tier 1 houses your application servers and data.

Tier 2 is the high-risk environment: user workstations and devices exposed to the internet.

The golden rule of tiering is strictly one-way: higher tier admins must never expose their credentials to lower tier systems, and lower tiers must never have management access to higher tiers. The core purpose of this separation is to ensure that a compromised workstation cannot yield Domain Admin credentials. However, operational tools that bridge these tiers often inadvertently break this definitional boundary.

PAM (Privileged Access Management): Solutions designed to securely vault credentials and broker administrative sessions, ensuring access to critical systems is monitored and controlled.

PIM (Privileged Identity Management): Tools that manage the lifecycle of elevated roles, typically by enforcing time-bound, Just-In-Time (JIT) access to eliminate standing privileges.

PAW (Privileged Access Workstation): Highly hardened, dedicated devices used exclusively for sensitive administrative tasks, physically or logically isolating tier admins from high-risk activities like email and web browsing.

Figure 1: Administration with dedicated tiered accounts

The front-line reality: the shared intermediary trap

Imagine this scenario: A threat actor compromises a standard workstation (Tier 2) through a phishing email. Their goal is the Domain Controller (Tier 0). In a properly tiered environment, this path is blocked; there are no credentials on the workstation to steal, and no direct privilege escalation route to the Domain Controller.

But then the threat actor finds an intermediary system.

In many environments, we see a single PAM session host used by everyone. The Tier 1 admins use it to manage application servers, and the Tier 0 admins use it to manage Domain Controllers. This convergence creates a "Shared" or "Dirty" Intermediary.

The attack path

The foothold: The threat actor compromises a standard Tier 2 workstation.
The escalation: The threat actor moves laterally and escalates privileges by exploiting common lower-tier misconfigurations (such as Helpdesk scenarios or exposed privileged service accounts) to compromise a Tier 1 administrator account who has full control over the Tier 1 PAM Host.
The pivot: Because the PAM Session Host resides in Tier 1, the threat actor uses those compromised Tier 1 admin rights to seamlessly gain full control of the underlying operating system of the PAM host itself.
The compromise: The threat actor simply waits for a Tier 0 admin to initiate a session. Because the threat actor already has full administrative control over the underlying server, it is a given that they can extract the Tier 0 credentials the moment that session begins.
Note: A threat actor at this stage does not need to exploit any weakness in the PAM software itself. Because the session host logically resides within the Tier 1 boundary, any identity or system with administrative rights over that tier holds ultimate authority over the host. This administrative control provides the means to modify the host's configuration, bypass security agents, and disable runtime protections before a privileged session ever begins. Once this foundational control is established, credential material processed by the operating system for outbound privileged sessions becomes accessible. This is not a PAM product failure; it is an architectural placement failure
Game over: The threat actor replays those credentials to take over the Domain Controller.

Here is how that compromise looks architecturally:

Figure 2: Single PAM host architecture

The core concept: PAM is an intermediary

To understand why the scenario above happens, we have to look at how Microsoft defines Privileged Access Intermediaries.

As detailed in our Privileged access intermediaries guidance, an intermediary is any system that stands between a user and a target resource. This includes VPNs, Jump Servers, and PAM solutions.

The Golden Rule of intermediaries

The security assurance of the target is only as good as the security assurance of the intermediary.

If you manage a Tier 0 asset (like a Domain Controller) through a PAM server, that PAM server becomes a Tier 0 asset. If that PAM server allows logins from Tier 1 users or is reachable from Tier 2 workstations, you have effectively downgraded your Domain Controllers to the security level of a workstation.

You cannot have a "Tier 1" server managing "Tier 0" assets. The math simply doesn't work. Each type of intermediary serves a different role, so the security controls won’t be identical. However, some basics apply to all of them, like quickly patching appliances, firmware, operating systems, and applications.

Figure 3: Security impact of different PAM approaches

Third-party PIM/PAM solutions are often deployed on-premises or as a Virtual Machine (VM) in an Infrastructure as a Service (IaaS) environment and are usually reachable only from internal (intranet) systems. Even if they aren’t exposed to the internet, one stolen credential could let a threat actor reach them through VPN or other remote access methods.

The hidden risk: the "master key" service account

The attack path above assumes a threat actor waits for a human administrator to arrive. But there is a second, more direct risk and it doesn’t require patience at all. It’s not just about where users log in; it’s about the power the software holds.

Consider the Password Reset scenario. A key feature of PAM is automatically rotating Domain Admin passwords, so human admins never need to know them; credentials are simply injected into the session. However, to perform this action, the PAM Service Account itself requires massive privileges (typically Domain Admin or equivalent) to reset those target passwords.

Here is the trap: If your PAM Core or Vault resides in Tier 1 (or is treated as such) but manages Tier 0 credentials, you have effectively granted Domain Admin rights to a Tier 1 asset.

A threat actor doesn't even need to wait for a human administrator to log in. If they compromise the underlying server where the PAM service runs, they can extract the Service Account’s credentials. Since this account has the power to reset Domain Admin passwords, the threat actor instantly elevates to Tier 0; no session required, no waiting, no noise.

This reinforces the golden rule: If a Service Account manages Tier 0, the system it runs on is Tier 0. The two attack vectors: hijacking a session and stealing the service account. Both stem from the same root cause: architectural misplacement. Fix the placement, and you eliminate both.

Practical checklist: are you exposed?

In DART engagements, we use this checklist to rapidly assess if a PAM deployment is a security asset or a liability. Use this to validate your own environment:

The intermediary check: Does any server used to manage Domain Controllers allow inbound RDP, SMB or other management connections from standard workstations or Tier 1 servers? (If yes, you are bridged).
The identity check: Do you use the same "Admin" account to log into the PAM portal for both Tier 0 and Tier 1 tasks? (If yes, you are exposing credentials).
The reachability check: Can your PAM Vault/Core be reached from the general user network? (It should only be reachable from management zones).
The isolation check: Are your Tier 0 Session Hosts logically and technically treated as Tier 0 assets?

What good looks like: The tiered PAM architecture

How do we fix this? We don't throw away PAM; we align it with the Enterprise Access Model.

In DART, we advocate for a tiered PAM deployment. This doesn't necessarily mean buying three different PAM vaults. It means strictly segregating the session hosts and the control plane.

The architecture of isolation

Tier 0 Control Plane: The core of your PAM (the Vault, the Policy Manager) holds the keys to the kingdom. Therefore, it must be treated as Tier 0. It should only be manageable by Tier 0 admins from Tier 0 workstations.
Segregated Session Hosts: You must have separate session host infrastructure for each tier.

- Tier 1 Session Host: Accessible from Tier 1, manages Tier 1. Blocked from talking to Domain Controllers.
- Tier 0 Session Host: Accessible only from Tier 0 PAWs, manages Tier 0. Totally isolated from the rest of the network.

This diagram illustrates a PAM deployment that respects the tiering model:

Figure 4: Separate PAM host architecture

For a deeper dive into reconciling these paradigms, review Intermediaries in Securing Privileged Administration and Microsoft's guide on Partitioning Administrative Privileges.

FAQ: Clearing the confusion

Q: Does PAM always belong in Tier 0?

A: If the PAM system manages Tier 0 credentials or provides access to Tier 0 assets, yes. The components that touch Tier 0 (Vault, Brokers, Session Hosts) must be secured at Tier 0 standards.

Q: Can we use a single "hardened" session host for all tiers to save costs?

A: In DART's experience, no. "Hardening" is often a configuration state that drifts or is bypassed by zero-days. Architecture beats configuration. If you bridge the network tiers, a compromised Tier 1 admin account is all a threat actor needs to gain OS-level control of that host and from there, access to Tier 0 sessions is a matter of patience, not sophistication.

Q: If we have PAM, do we still need the Tiering Model?

A: Absolutely. PAM doesn’t replace Tiering; when implemented correctly, it adds another layer of security and/or governance. Tiering keeps credentials and admin access separated, so threat actors can’t easily move sideways or reuse stolen hashes. PAM provides workflow, rotation, and audit trails.

Q: What is the most common mistake you see?

A: We frequently see organizations approach PAM as a "magic stick", believing it secures everything about credential hygiene. Yet, because they assume the tool secures itself, they treat this critical infrastructure as just another Tier-1 asset. It gets patched like a standard file server and monitored like a print server, rather than being hardened and isolated as a Tier-0 component. This mindset doesn't secure the environment; it creates a fragile bridge that threat actors can easily cross.

Q: Our PAM vendor says their session host is hardened out of the box. Why is this still a risk?

A: PAM vendors are right that a well-configured session host with Credential Guard enabled, application control enforced, and remote management restricted is considerably harder to exploit than a stock Windows Server. Some vendors use Kerberos constrained delegation with S4U2Proxy, meaning the machine account rather than the Domain Admin’s actual credentials authenticates to the target, which limits direct credential exposure. These are meaningful controls and we don’t dismiss them. However, application-layer hardening is defeated by OS-layer control. If the PAM host is domain-joined and sits in a Tier 1 OU, a Tier 1 Domain Admin has Group Policy, software deployment rights, and Active Directory machine account control over that host. They can push a GPO to disable Credential Guard, deploy a driver via software distribution, or alter the machine’s configuration before the next reboot, all using entirely legitimate AD administration tools. The vendor’s hardening is irrelevant once the threat actor controls the tier the machine lives in. This is precisely why tier placement is not a PAM configuration decision; it is an Active Directory architecture decision.

Q: We’re cloud-first and use Entra ID. Does AD Tiering still apply to us?

A: The specific tier labels change, but the principle does not. Microsoft’s Enterprise Access Model is the cloud-era evolution of AD Tiering, built around the same core concept: Control Plane (equivalent to Tier 0), Management Plane (Tier 1), and User Access / Data Plane (Tier 2). In an Entra ID environment, your Control Plane includes Global Administrators, Privileged Role Administrators, and the Conditional Access policies that govern them. A PAM or PIM solution managing those identities must be treated with the same isolation discipline. Hybrid environments, where on-premises AD and Entra ID are synchronized, carry the additional risk that a compromise of either plane can propagate to the other through synchronization. If anything, hybrid environments make strict intermediary placement more critical, not less.

Conclusion

PAM is a powerful tool in the defender’s arsenal; but like any powerful tool, its effectiveness depends entirely on how it is positioned. The threat actors we encounter in DART engagements don’t look for the most sophisticated path to Domain Admin. They look for the most trusted one. A PAM server in the wrong tier isn’t a hardened barrier; it’s a trusted bridge with a gold-plated sign.

By aligning your PAM deployment with the principles of Privileged Access Administration, treating session hosts and service accounts as the tier of the assets they manage, not the zone they physically sit in, you close the bridge before a threat actor finds it.

Build your architecture like a threat actor will find it. Because they will.

Stay secure, stay tiered.

Live AMA: Microsoft Agent 365

Emily_Perina — Wed, 15 Apr 2026 18:34:36 GMT

Agent 365--generally available May 1, 2026--is a control plane that empowers IT admins, Security Operations analysts, Identity and Network Security admins, and Data Security & Compliance admins to observe, govern, and secure all agents for their organization. We’ll demonstrate how to get started and answer your questions about licensing and functionality in this live 'Ask Microsoft Anything' with product and engineering team experts!

How to Participate

Register for the Microsoft Tech Community using your email if you haven’t already. This allows you to post comments and ask questions.
Visit this page during its scheduled time to join the conversation. You can post your questions in the comments, and product team members will respond live during the AMA.
Watch the session live or catch the recording on demand after the event.
Keep the conversation going in the Agent 365 discussion space after the sessions conclude. It’s a great place to follow up, share what’s working, and connect with others exploring similar topics.

Hope to see you there! Come ready to learn and ask our experts all of your burning questions!

Evolving the Microsoft Certified: Azure AI Fundamentals Certification

LibertyMunson — Thu, 16 Apr 2026 00:55:08 GMT

As AI cloud solution adoption accelerates, demonstrate your readiness to build modern, responsible Azure AI solutions using Microsoft Foundry and Python with the new Exam AI‑901 (beta).

AI is no longer a distant, abstract idea. Organizations around the world are adopting it right now to streamline workflows and strengthen operational efficiency. As a result, the demand for AI solution developers is accelerating.

To support this shift, we’re evolving the Microsoft Certified: Azure AI Fundamentals Certification. The updated Microsoft Certification validates your knowledge of AI concepts and capabilities and your ability to implement AI solutions by using Azure and Microsoft Foundry. After June 30, 2026, to earn this Certification, you’ll need to pass Exam AI-901: Azure AI Fundamentals, currently in beta.

The Microsoft Certified: Azure AI Fundamentals Certification is designed for people who are beginning their journey in AI solution development, and it validates that you can apply responsible AI principles in real‑world scenarios. It also provides a strong foundation for pursuing more advanced role‑based Certifications in Azure AI and machine learning.

Is this the right Certification for you?

The Microsoft Certified: Azure AI Fundamentals Certification focuses on the practical skills needed to build modern AI apps and agents by using Foundry. By preparing to earn the Certification, you build practical, job‑relevant skills. Exam AI-901 validates your ability to:

Describe AI concepts and capabilities, including principles of responsible AI, along with AI workloads, model components, and configurations.
Implement AI solutions with Foundry, including generative AI apps and agents, in addition to AI solutions for text and speech, computer vision and image-generation capabilities, and information extraction.

As a candidate for this Certification, you should have conceptual knowledge of AI solutions in Azure and the foundational technical skills to work with them. You also need knowledge of Python coding syntax and programming techniques, and you should be familiar with provisioning Azure resources.

With its expanded focus, Exam AI-901 replaces Exam AI-900, which is being retired on June 30, 2026. The new exam addresses:

Generative AI and agents, with updated coverage of the Foundry portal, tools, and models.
AI workloads, responsible AI principles, and solution patterns.
Simple approaches to implementing AI solutions using Foundry.

Area	Exam AI‑900 (old)	Exam AI‑901 (new)
Audience	Nontechnical or technical beginners	Technical beginners planning to build AI solutions
Skills tested	Understanding AI and machine learning concepts; identifying when to use Azure AI services	Understanding AI concepts; implementing AI solutions with Microsoft Foundry
Required coding knowledge	None	Basic Python syntax and programming concepts
Knowledge level	Introductory, conceptual understanding of Azure AI services (classic approach)	Foundational understanding of Azure resources, plus implementation with Foundry, provisioning Azure resources, and modern AI development tooling
Focus	What is AI?	How do I build an AI app by using Foundry?

NOTE: We’re not retiring the Azure AI Fundamentals Certification; we’re refreshing the requirements to earn it, with a new exam that better reflects modern AI solution development skills. If you already hold this Certification, no action is required; however, you may take the new Exam AI-901 if you would like to showcase your ability with a wider skill set. For more details on the retirement of Exam AI-900 and the latest cloud and AI Certification updates, read our recent blog post, The AI job boom is here. Are you ready to showcase your skills?

Ready to prove your Azure AI skills?

Take advantage of the discounted beta exam offer. The first 300 people who take Exam AI-901 (beta) on or before May 6, 2026, can get 80% off.

To receive the discount, when you register for the exam and are prompted for payment, use code AI901Medford. This is not a private access code. The seats are offered on a first-come, first-served basis. As noted, you must take the exam on or before May 6, 2026. Please note that this discount is not available in Turkey, Pakistan, India, or China.

How to prepare

Get ready to take Exam AI-901 (beta):

Review the Exam AI-901 (beta) exam page for details.
The Exam AI-901 study guide explores key topics covered in the exam.
Work through the self-paced Course AI-901: Introduction to AI in Azure.
Connect with Microsoft Training Services Partners in your area for in-person offerings.
Need other preparation ideas? Check out Just How Does One Prepare for Beta Exams?

Ready to get started?

You can take Certification exams online, from your home or office. Get the details in Online proctored exams: What to expect and how to prepare.

Remember, only the first 300 candidates can get 80% off Exam AI-901 (beta) with code AI901Medford on or before May 6, 2026.

Beta exam rescoring begins when the exam goes live, with final results released approximately 10 days later. For more details, read Creating high-quality exams: The path from beta to live.

Stay tuned for general availability of this Certification in June 2026.

Additional information

For more cloud and AI Certification updates, read our recent blog post, The AI job boom is here. Are you ready to showcase your skills?

Follow our credentials news on The Skills Hub blog as we roll out additional new Certifications in April, May, and June 2026.

Join our Microsoft Worldwide Learning SME Group for Credentials on LinkedIn for beta exam alerts and opportunities to help shape future Microsoft learning and assessments.

Explore Microsoft Credentials on AI Skills Navigator.