Core Infrastructure and Security Blog articles

Customer Offerings: Solution Optimization for GitHub Copilot

wernerrall — Wed, 15 Jul 2026 13:41:27 GMT

Introduction

As Microsoft Cloud Solution Architects, we are increasingly asked by engineering leaders, platform teams, finance stakeholders, and GitHub administrators how they can scale GitHub Copilot while keeping usage visible and costs predictable. The question is no longer simply how many licenses have been assigned. Agentic experiences, model choice, context size, reasoning level, and task complexity can all influence consumption.

To address this challenge, Microsoft customers can engage their account team to request a Solution Optimization for GitHub Copilot engagement. The engagement is designed to help customers create visibility, establish practical cost guardrails, and improve the quality and efficiency of GitHub Copilot usage. The objective is not to minimize every token; it is to help each interaction produce useful outcomes with the right level of capability and control.

What changed with GitHub Copilot billing?

As of June 1, 2026, GitHub Copilot moved from premium request units to usage-based billing with GitHub AI Credits. When a user interacts with an AI-powered Copilot feature, the interaction can consume input tokens, output tokens, and cached tokens. The model used and the number of tokens processed determine the AI credit consumption, where one AI credit represents $0.01 USD.

Area	What customers should know
Included usage	Copilot Business includes 1,900 AI credits per licensed user per month, while Copilot Enterprise includes 3,900. These credits are pooled at the billing entity level.
Promotional period	At the time of writing, existing Business and Enterprise customers receive higher promotional allowances through August 2026. Validate the current allowance before publishing or making financial decisions.
Included experiences	Code completions and next edit suggestions remain included on paid plans and do not consume AI credits.
Metered experiences	AI-powered features such as Copilot Chat, Copilot CLI, Copilot cloud agent, Copilot Spaces, Spark, and supported third-party coding agents consume AI credits.
Additional consumption	Some agentic experiences, including Copilot code review and cloud agent scenarios, can also consume GitHub Actions minutes in addition to AI credits.

Important:
Pricing, allowances, supported models, and product behavior can change. The official GitHub documentation and the customer’s commercial agreement remain the source of truth.

Why optimization is more than cost reduction

Token consumption is only the visible part of the problem. A poorly scoped task, unnecessary context, or the wrong model can cause an agent to misunderstand the request, make excessive changes, or require repeated attempts. In that situation, reducing the price of an individual request does not solve the underlying quality problem.

A better optimization strategy starts with agent quality. The right model, clear instructions, focused context, good repository guidance, and deterministic validation can help Copilot complete work in fewer attempts. Better outcomes and lower consumption frequently reinforce each other.

Introducing Solution Optimization for GitHub Copilot

The Solution Optimization for GitHub Copilot engagement provides customers with an opportunity to work with a Microsoft Cloud Solution Architect to review how GitHub Copilot is being adopted, consumed, governed, and measured. The final scope should be agreed with the Microsoft account team and may vary according to the customer’s licensing model, environment, maturity, and priorities.

A typical engagement can focus on the following areas:

Usage visibility: Establish a current-state view of adoption, AI credit consumption, model activity, license allocation, and the users or workflows driving demand.
Billing readiness: Review exported usage data, compare scenarios, and identify where the move to usage-based billing changes planning assumptions.
Cost guardrails: Design user-level, cost-center, organization, and enterprise budget controls that protect the shared pool without unnecessarily blocking productive users.
Agent quality and token optimization: Identify improvements to model selection, prompt structure, context management, reasoning levels, repository instructions, and validation steps.
Operating model: Define ownership, review cadence, escalation paths, reporting responsibilities, and a prioritized backlog of recommended actions.

Potential customer outcomes

Depending on the agreed scope, the engagement can help the customer develop:

A baseline of GitHub Copilot adoption, AI credit consumption, and cost drivers.
A view of heavy users, underused licenses, high-consumption models, and agentic workflows that need closer review.
A budget and guardrail design that balances shared-pool flexibility with predictable financial control.
Practical recommendations for improving agent quality and reducing avoidable retries or context overhead.
A prioritized optimization plan with owners, next actions, and measurable follow-up points.

A practical engagement approach

Discover: Review the customer’s goals, GitHub billing entity, Copilot plans, license assignment model, existing policies, cost centers, and available usage data.
Analyze: Use native GitHub reporting and approved accelerators to examine adoption, AI credit usage, model activity, user patterns, and potential cost drivers.
Optimize: Map the right model and reasoning level to each task, improve prompts and context, reduce unnecessary tool or repository context, preserve reusable cache, and plan before executing complex changes.
Govern: Define user-level budgets, power-user overrides, cost-center or organization controls, enterprise spending limits, alerts, and ownership responsibilities.
Measure: Document the baseline, agree on key indicators, and establish a regular review cycle to measure adoption, value, quality, and consumption over time.

Tools and accelerators

GitHub AI usage, billing exports, and budget controls

GitHub’s native AI usage pages and billing reports should be the starting point for understanding consumption. They provide the information required to identify model usage, users, features, and cost patterns. Native budget controls can then be applied at the appropriate user, cost-center, organization, or enterprise scope.

GitHub AI usage dashboard, exported usage report, and budget controls

GitHub Copilot Billing Preview

The GitHub Copilot Billing Preview is an open-source web application for analyzing Copilot billing CSV reports, comparing request-based and usage-based billing signals, and exploring usage and cost trends by user, organization, model, product, and cost center. CSV processing occurs locally in the browser. The application is a preview and planning tool, not the billing source of record.

GitHub Copilot Billing Preview showing usage and cost trends

Copilot Insights dashboard

The community-developed Copilot Insights dashboard provides centralized views of adoption, license allocation, AI credit consumption, model activity, productivity indicators, and team-level reporting. It can complement native GitHub data when a customer needs richer visualization or executive reporting. Customers should review the project’s security, deployment, support, and governance model before production use.

Copilot Insights adoption, license, and AI credit views

Agent quality and token optimization principles

GitHub’s guidance emphasizes that the most sustainable way to reduce AI credit consumption is to improve the quality and efficiency of each interaction. The following principles provide a useful starting point:

Choose the right model for the task. Reserve powerful reasoning models for complex architecture, debugging, and design work. Use mid-tier or lighter models for well-scoped implementation, documentation, formatting, and routine refactoring.
Provide clear guidance. State the goal, constraints, expected output, relevant files, and validation criteria. Ambiguous prompts often lead to exploration and rework.
Keep context lean. Supply the information needed for the task and avoid loading unrelated repositories, files, tools, or instructions into the context window.
Preserve reusable context. Stable instructions and cached context can reduce repeated processing, provided they remain relevant and accurate.
Research and plan before implementation. For complex work, separate discovery and planning from execution so the agent does not repeatedly rediscover the same information.
Add deterministic guardrails. Tests, linting, build validation, explicit stop conditions, and session limits help prevent long-running or low-quality loops.
Measure value, not only consumption. AI credit data should be considered together with adoption, developer experience, quality, delivery outcomes, and business impact.

Overview video

The on-demand session GitHub Copilot - Token Optimization [AMER/EMEA] explains the relationship between token usage and agent quality. The session covers how large language models, agent harnesses, context windows, and available controls influence agent behavior, quality, consumption, and cost.

https://www.youtube.com/live/LeALSSsbzHU?si=4RgxflItkQFAs9Qk

Helpful inputs before the engagement

The following inputs can help the Microsoft team and customer make the best use of the engagement:

A GitHub enterprise or organization owner, billing manager, and relevant engineering or platform stakeholders.
Current Copilot plan and license counts, including the billing entity and cost-center structure.
A representative GitHub AI usage or billing export, handled according to the customer’s data policies.
Existing budgets, spending policies, model policies, and reporting processes.
Examples of high-volume agent sessions, code review workflows, or teams reporting unexpected consumption.
The business outcomes the customer wants to improve, such as adoption, developer experience, delivery speed, quality, or cost predictability.

Conclusion

GitHub Copilot usage-based billing changes the conversation from license assignment alone to the broader discipline of operating AI-assisted software development. Customers need visibility into how AI credits are consumed, controls that prevent unexpected spend, and engineering practices that help agents complete work accurately and efficiently.

The Solution Optimization for GitHub Copilot engagement can help customers connect usage data to practical decisions, improve agent quality, establish appropriate financial guardrails, and create a repeatable approach for measuring and optimizing GitHub Copilot over time.

How do I book this engagement?

Microsoft Unified Support customers can contact their Customer Success Account Manager (CSAM) or Microsoft account team and ask about Solution Optimization for GitHub Copilot. The Microsoft team can confirm availability, eligibility, scope, prerequisites, and scheduling for the customer’s environment.

Resources

Disclaimer

Pricing, plan entitlements, AI credit allowances, supported models, and product behavior are subject to change. Always verify current information in the official GitHub documentation and the customer’s commercial agreement before making purchasing, budgeting, or technical decisions.

The sample applications, dashboards, and scripts referenced in this article are provided AS IS without warranty of any kind and may not be supported under a Microsoft or GitHub standard support program unless explicitly stated. Customers are responsible for reviewing security, privacy, compliance, deployment, and operational requirements before using community or open-source solutions in production. This blog post was drafted with the assistance of generative AI and should be reviewed and approved by the author and relevant Microsoft stakeholders before publication.

Hunting Local AI Tools on macOS with Microsoft Defender for Endpoint

Vytas_Boyev — Tue, 14 Jul 2026 16:42:42 GMT

AI tooling is moving fast. Developers are running models locally, agents are spinning up local servers, and frameworks are adding new ways to extend the endpoint with skills, tools, and memory. That creates a useful productivity surface, but it also presents new challenges for security and governance teams.

A set of AI focused detection and protective Defender for Endpoint features are now in preview – Local AI Agent and MCP detection and inventory as well as AI Agent security posture– both announced in detail here on the Microsoft Defender XDR blog .

Those capabilities are emerging, but defenders still need practical visibility now. The power of Microsoft’s XDR platform provides the capability to look at our endpoint telemetry and gather data from your existing environment today…. MDE already captures enough process, file, and network telemetry to start hunting for this activity with Advanced Hunting KQL.

Why Focus on macOS?

Many organizations have developers that have adopted macOS clients as development machines.

Developers are a population that are positioned to take advantage of and use AI in the course of developing Frontier and next generation apps, agents, and capabilities. Which increases their attack surface while maintaining their attractiveness for targeted supply chain attacks.

The capability to detect and have visibility on local AI tool usage, MCP server usage, malicious skill files, or AI-specific abuse patterns such as prompt injection are top of mind topics that I encounter routinely with my customers that I support.

This post walks through how I’d approach that problem: inventory first, then detect local AI servers, monitor skill/configuration files, and finally look for suspicious behavior that may indicate abuse. Keep in mind that though I am specifically addressing macOS in this post, the techniques can be shifted to Linux and other supported platforms through the power and flexibility of KQL and Advanced Hunting.

Why local AI on macOS matters

Most endpoint detection content has historically focused on malware, persistence, credential theft, and command execution. Local AI agents blur those lines.

An AI agent running on a developer workstation may legitimately:

Spawn shell commands.

Read source files and configuration files.

Write scripts.

Start a local server.

Pull packages or model files.

Maintain memory or context in local markdown files.

That same behavior can also become risky if the agent is compromised, misconfigured, or influenced by malicious instructions.

For macOS, two local AI frameworks stand out in the telemetry patterns I reviewed:

Ollama — a local LLM runtime that exposes a local API, commonly on port 11434.

OpenClaw — an autonomous AI agent platform that uses a local gateway, commonly on port 18789.

Both leave process, filesystem, and network artifacts that MDE can see.

Start with inventory, not alerts

Before turning anything into a detection rule, start by understanding where local AI tools already exist.

The first useful question is simple: Which macOS devices are running AI tooling?

A reporting query against DeviceProcessEvents can identify known AI-related processes such as ollama, openclaw, node, npx, codex, or claude-code. The important detail is that macOS platform filtering needs to come from DeviceInfo, as it is not present in the other KQL tables we will be using.

A practical inventory pattern looks like this:

KQL — macOS AI tool inventory

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId | join DeviceProcessEvents on DeviceId | where Timestamp > ago(30d) | where ( FileName in~ ( "ollama", "openclaw", "ollama_llama_server", "ollama-runner", "mcp-server", "codex", "codex-cli", "claude-code", "npx", "node", "deno" ) or ProcessCommandLine has_any ( "ollama", "openclaw", "ollama_llama_server", "ollama-runner", "mcp-server", "codex", "codex-cli", "claude-code", "npx", "node", "deno" ) ) | summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), ExecutionCount = count(), DistinctUsers = dcount(AccountName) by DeviceName, FileName, FolderPath | sort by LastSeen desc

This gives you a baseline. Once you know what normal looks like, you can start asking more interesting questions:

Which devices are running AI tools for the first time?

Which users are adopting them?

Which tools are approved?

Which tools appeared without a change request or expected rollout?

That baseline becomes the foundation for alerting.

Detect first-time AI tool usage

A good first alert is “new AI tool on a macOS device.”

The key is to compare recent activity against historical activity by both device and tool name. If a Mac has already run OpenClaw but suddenly starts running Ollama, that should still be considered a new tool introduction.

KQL — first-time AI tool usage on macOS

DeviceProcessEvents | where Timestamp > ago(1d) | where FileName in~ ("ollama", "openclaw")     or ProcessCommandLine has_any ("ollama", "openclaw", "openclaw.mjs") | join kind=leftanti (     DeviceProcessEvents     | where Timestamp between (ago(30d)..ago(1d))     | where FileName in~ ("ollama", "openclaw")         or ProcessCommandLine has_any ("ollama", "openclaw", "openclaw.mjs")     | distinct DeviceId, FileName, ProcessCommandLine ) on DeviceId, FileName, ProcessCommandLine | summarize     FirstSeen = min(Timestamp),     LastSeen = max(Timestamp),     Count = count()     by DeviceName, FileName, ProcessCommandLine, AccountName | sort by LastSeen desc

This may be a good daily custom detection candidate, especially in environments where AI tooling needs to be explicitly approved.

Watch for local AI servers

Local AI frameworks often expose services on localhost. That makes network telemetry useful even when the tool is only listening locally.

Known ports worth watching:

Tool	Port	Purpose
Ollama	11434	Local HTTP API
OpenClaw	18789	Local WebSocket gateway

A targeted detection for those ports is straightforward:

KQL — local AI server listener detection

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceNetworkEvents on DeviceId | where Timestamp > ago(1d) | where ActionType == "ListeningConnectionCreated" | where LocalPort in (18789, 11434) | project     Timestamp,     DeviceName,     LocalIP,     Port = LocalPort,     ProcessName = InitiatingProcessFileName,     CommandLine = InitiatingProcessCommandLine,     User = InitiatingProcessAccountName | sort by Timestamp desc

For broader hunting, enumerate localhost listeners and exclude known system services. This helps find new or less common MCP servers before they show up in a curated indicator list.

Monitor AI skill and context files

The next detection surface is the filesystem.

AI agent frameworks increasingly use markdown-based instruction and context files. Examples include:

SKILL.md

SKILLS.md

SOUL.md

MEMORY.md

AGENTS.md

These files are powerful because they influence how the agent behaves. A malicious skill file can embed instructions, reference scripts, deliver payloads, or create persistence.

A weekly reporting query can monitor creation and modification of these files:

KQL — AI skill and context file monitoring

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceFileEvents on DeviceId | where Timestamp > ago(7d) | where ActionType in ("FileCreated", "FileModified") | where tolower(FileName) in (     "skill.md",     "skills.md",     "soul.md",     "memory.md",     "agents.md" ) | project     Timestamp,     DeviceName,     FileName,     FolderPath,     ActionType,

For alerting, I would focus on suspicious creators: curl, wget, python, bash, scp, or browser-downloaded files with FileOriginUrl populated.

DeviceInfo | where OSPlatform == "macOS" |distinct DeviceId |join DeviceFileEvents on DeviceId | where Timestamp > ago(1d) | where ActionType == "FileCreated" | where tolower(FileName) in ("skill.md", "skills.md", "soul.md") | where InitiatingProcessFileName in ("curl", "wget", "python", "python3","bash", "sh", "zsh", "nscurl", "scp") or isnotempty(FileOriginUrl) | project Timestamp, DeviceName, FileName, FolderPath,FileOriginUrl, FileSize, InitiatingProcessFileName, InitiatingProcessCommandLine

The signal is not “a skill file exists.” The signal is “a skill file appeared or modified in an unusual way.”

Look for prompt injection side effects

Prompt injection is hard to detect directly from endpoint telemetry because MDE does not see the prompt content inside encrypted sessions or local model interactions.

But endpoint telemetry can show the downstream effects.

If an AI agent is manipulated into doing something unsafe, you may see it:

Spawn a shell.

Run osascript.

Invoke launchctl.

Access the macOS Keychain via security.

Use curl, wget, or scp.

Read sensitive paths such as .ssh, .env, or credential files.

Make unexpected external network connections.

A useful behavioral detection is AI-related parent processes spawning sensitive child commands:

KQL — AI parent process spawning sensitive child commands

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceProcessEvents on DeviceId | where Timestamp > ago(1d) | where tolower(InitiatingProcessFileName) in ("ollama", "openclaw", "node", "npx", "deno")     or InitiatingProcessCommandLine has_any ("openclaw", "ollama", "openclaw.mjs") | where FileName in~ (     "sh",     "bash",     "zsh",     "python",     "python3",     "curl",     "wget",     "scp",     "osascript",     "launchctl",     "security",     "dscl" ) | project     Timestamp,     DeviceName,     ParentProcess = InitiatingProcessFileName,     ParentCmdLine = InitiatingProcessCommandLine,     ChildProcess = FileName,     ChildCmdLine = ProcessCommandLine,     User = AccountName | sort by Timestamp desc

This may not be suitable for use as an alert, as developers using AI coding assistants will legitimately run shell commands. The goal is not to block all shell execution. The goal is to identify suspicious combinations: encoded payloads, persistence commands, credential access, unexpected network transfer, or sensitive file access.

Don’t skip external network checks

Local inference should mostly stay local. Ollama may contact external services for model downloads or registry activity, and agents may call approved cloud AI APIs depending on configuration. But unexpected public destinations from local AI processes are worth reviewing.

Start with a narrow allowlist and expand based on your environment:

KQL — external network connections from local AI processes

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceNetworkEvents on DeviceId | where Timestamp > ago(1d) | where ActionType in ("ConnectionSuccess", "ConnectionAttempt") | where InitiatingProcessFileName in~ ("ollama", "openclaw", "node")     or InitiatingProcessCommandLine has_any ("openclaw", "ollama") | where RemoteIPType == "Public" | where RemoteUrl !endswith "ollama.com"     and RemoteUrl !endswith "openclaw.ai"     and RemoteUrl !endswith "anthropic.com"     and RemoteUrl !endswith "openai.com" | project     Timestamp,     DeviceName,     RemoteIP,     RemoteUrl,     RemotePort,     ProcessName = InitiatingProcessFileName,     CommandLine = InitiatingProcessCommandLine | sort by Timestamp desc

For alerting, consider thresholding on multiple distinct remote URLs from the same AI process over 24 hours. That helps separate one-off legitimate activity from suspicious multi-destination behavior.

KQL — OpenClaw LaunchAgent Plist Creation (Last 24 Hours)

This catches plist files appearing in ~/Library/LaunchAgents (or /Library/LaunchAgents) that reference OpenClaw by name or were created by an OpenClaw-related process. A matching result indicates that a persistent auto-start configuration has been installed for the AI gateway — which should be validated against approved deployment records.

DeviceFileEvents | where Timestamp > ago(1d) | where ActionType in ("FileCreated", "FileModified") | where FolderPath has "LaunchAgents" and FileName endswith ".plist" | where FileName has "openclaw"     or InitiatingProcessFileName in~ ("openclaw", "node")     or InitiatingProcessCommandLine has "openclaw" | where DeviceId in (     DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId ) | project     Timestamp,     DeviceName,     FileName,     FolderPath,     InitiatingProcessFileName,     InitiatingProcessCommandLine,     User = InitiatingProcessAccountName

Recommended deployment model

I would not deploy every query as an alert on day one. A better operational model is:

Use case	Cadence	Deployment
AI process inventory	Weekly	Reporting dashboard
First-time AI tool per device	Daily	Custom detection
Known AI server ports	Daily	Custom detection
OpenClaw LaunchAgent persistence	Daily	Custom detection
Skill/context file monitoring	Weekly	Reporting dashboard
Suspicious skill creation	Daily	Custom detection
AI process spawning system commands	Daily	Custom detection after tuning
AI external network connections	Daily	Custom detection after tuning
Broad localhost listener discovery	Weekly	Threat hunt

The most reliable detections are inventory deltas, known listening ports, persistence artifacts, and suspicious skill creation. The highest-noise detections are behavioral heuristics, especially shell execution and external network activity.

Practical limitations

A few MDE/macOS realities matter:

MDE does not decrypt TLS traffic.

DeviceProcessEvents does not include OSPlatform, so use DeviceInfo to scope macOS devices. These queries can be used as a base to expand hunting into other OS platforms with minimal modification of the KQL.

A positive SKILL.md hit still requires content review.

DeviceFileEvents shows file metadata, not file contents.

That means these queries should be part of a broader defense-in-depth strategy, not the entire program.

Pair them with:

MDM and other controls restricting unsigned or unapproved AI apps- which may be problematic in a developer centric environment.

Network monitoring for known local AI ports.

Review processes for third-party skills.

Proxy/firewall correlation for suspicious external traffic.

Version-controlled detection content so query changes can be audited and rolled back.

Final thought

Local AI tools are becoming part of the endpoint reality. You can get a head start on understanding your org’s AI usage with KQL and Advanced hunting, especially on developer-heavy macOS fleets. Agent visibility in the XDR portal is in flight and arriving soon.

In the interim can start now with the telemetry we already have: processes, files, ports, and network connections. Build a baseline. Alert on meaningful change. Tune the noisy heuristics. Review skill files like executable content, because in practice that is what they can become.

Other artifacts that you can hunt for AI are the Defender for Cloud Apps leveraging the governance capability for monitoring or sanctioning and unsanctioning apps – which in this case - monitor the AI related apps.

This is not necessarily about blocking AI usage by default. It is about giving defenders enough visibility to distinguish normal local AI adoption from risky or compromised behavior.

Addendum:

I’ve created a Sentinel Workbook that incorporates these queries. Available at https://github.com/vboyev-MSFT/Microsoft-Sentinel-Workbooks

Check This Out! (CTO!) Guide (July 2026)

TysonPaul — Mon, 13 Jul 2026 20:50:04 GMT

Member: TysonPaul | Microsoft Community Hub

Triage vulnerabilities with the Vulnerability Remediation Agent, now in public preview

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 06/16/2026

Summary: Microsoft has launched the Vulnerability Remediation Agent for Security Copilot in Microsoft Intune, now in public preview. This agent automates the identification, prioritization, and remediation of vulnerabilities on Intune-managed Windows devices using data from Microsoft Defender. It provides prioritized recommendations, Copilot-assisted impact analysis, and step-by-step remediation guidance, all within the Intune admin center. The agent operates securely under a dedicated agentic identity, ensuring clear governance and accountability. The streamlined workflow helps IT teams quickly address critical threats, reduce exposure, and track progress, supporting a more proactive, AI-driven security posture.

Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned

Team Blog: Intune Customer Success

Author: MikeGriz

Published: 06/18/2026

Summary: The article details Microsoft’s internal deployment of Platform Single Sign-On (PSSO) for pre-macOS 26 devices using Intune. It highlights the benefits of Secure Enclave-backed authentication—phishing-resistant MFA, device-bound tokens, and improved Conditional Access—while outlining setup steps, user experience, troubleshooting, and best practices. Key challenges included password policy mismatches and users dismissing registration prompts. The authors recommend starting with Secure Enclave, deploying during enrollment, aligning password policies, and piloting thoroughly. PSSO enables passwordless, hardware-backed SSO across Microsoft 365 apps, improving security and user experience for Mac fleets.

Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support

Team Blog: Azure Arc

Author: LiranLyabock

Published: 06/02/2026

Summary: The article announces expanded capabilities for Foundry Local on Azure Local, including multi-node inference scheduling, vLLM runtime support, and a broader model catalog. These enhancements enable scalable, high-concurrency AI deployments fully on-premises—even in disconnected environments—using Kubernetes-native and OpenAI-compatible patterns. vLLM boosts throughput for large models and concurrent workloads, with automatic GPU tuning via vLLMplanner. Identity-based access is supported for multi-user scenarios. The platform now accommodates more models, including Mistral and Nemotron, and offers seamless integration and operation for regulated, sovereign, and edge environments.

Unlock On-Prem Productivity with Agentic Retrieval in Foundry Local

Team Blog: Azure Arc

Author: moran_assaf

Published: 06/02/2026

Summary: The article introduces Agentic Retrieval in Foundry Local, a new on-premises platform enabling advanced, context-rich AI interactions without relying on cloud connectivity. Powered by Azure Arc and Foundry models, it offers orchestration, governed knowledge management, and a production-ready chat UI for regulated, disconnected, and mission-critical environments. Key features include flexible deployment, auditable reasoning, multi-document synthesis, data sovereignty, and seamless user experience. This release supports Microsoft’s Adaptive Cloud vision, delivering resilient, intelligent GenAI solutions wherever customer data and operations reside, ensuring compliance and autonomy for enterprise and public sector users.

Microsoft 365 Copilot on mobile: What staged rollout plans can miss

Team Blog: FastTrack

Author: JulieHersum

Published: 06/02/2026

Summary: The article highlights that staged rollout plans for Microsoft 365 Copilot on mobile often miss how quickly real-world usage spreads. Mobile access accelerates adoption in “in-between” work moments, making usage less linear and more socially driven than planned. Desktop-focused governance and communication strategies may not apply to mobile-first behaviors, leading to early questions and confusion. IT teams should focus on rollout sequencing, setting user behavior expectations, governance/readiness, and clear communication to align planned deployment with actual adoption momentum. Early signals of mobile usage require proactive adjustments to maintain clarity and control.

Faster az login: introducing --skip-subscription-discovery and targeted --subscription

Team Blog: Azure Tools

Author: Alex-wdy

Published: 06/07/2026

Summary: The article introduces two new Azure CLI flags—`--skip-subscription-discovery` and targeted `--subscription`—which significantly speed up the `az login` process for users with many tenants and subscriptions. By skipping the post-authentication subscription enumeration, login times drop from minutes to seconds. These features, available from Azure CLI v2.86.0, are ideal for enterprise users or CI/CD scenarios needing quick access to specific subscriptions, but may not suit cases requiring access to multiple subscriptions or discovery.

Network security perimeter for Azure Service Bus & also now available in Azure Gov. Regions

Team Blog: Azure Networking

Author: shashankamalladi

Published: 06/08/2026

Summary: Network security perimeter support for Azure Service Bus is now generally available, including in Azure Government regions. This enables centralized security boundaries, perimeter-based governance, and secure PaaS-to-PaaS communication for messaging services. Customers can define explicit access controls, confine communications, and enhance audit/compliance visibility. The feature supports regulated and mission-critical workloads, ensuring consistent security across commercial and sovereign environments. Future plans include expanding onboarding to more PaaS services and improving access rule capabilities.

Migrating from MSEE Hairpin Routing to AVNM Mesh for Large-Scale VNet-to-VNet Connectivity

Team Blog: Azure Networking

Author: Jay-Li

Published: 06/18/2026

Summary: The article explains how large Azure deployments can migrate from MSEE hairpin routing to Azure Virtual Network Manager (AVNM) mesh for VNet-to-VNet connectivity. AVNM mesh enables direct, in-datacenter east-west traffic, eliminating MSEE as a single point of failure, reducing latency, and supporting up to 5,000 VNets and 20,000 Private Endpoints. Migration is incremental, reversible, and doesn’t disrupt existing network paths or security inspection, with AVNM centrally managing connectivity. The article details migration steps, scaling considerations, and validation processes, emphasizing operational simplicity and improved performance for large-scale Azure environments.

Azure Sets a New Performance Record for LLM Training Benchmark at Extreme Scale

Team Blog: Azure High Performance Computing (HPC)

Author: azinheidarshenas

Published: 06/16/2026

Summary: Azure set a new MLPerf Training benchmark record by training Llama 3.1 405B in just over seven minutes, scaling to 8,192 NVIDIA GB200 NVL72 GPUs across 128 racks. This was achieved through high operational efficiency, resilient networking, and topology-aware workload mapping. Azure’s Fairwater AI supercomputing infrastructure, with NVLink and MRC networking, minimized communication bottlenecks, enabling near-perfect scaling and stable step times. The result demonstrates Azure’s ability to handle massive, synchronous LLM training workloads efficiently, showcasing both hardware and system-level innovations for frontier-scale AI.

Scaling High-Performance CAD on Azure Virtual Desktop with NVIDIA RTX PRO 6000

Team Blog: Azure High Performance Computing (HPC)

Author: Sunita_AZ0708

Published: 06/17/2026

Summary: The study validates Siemens NX 2506 running on Azure Virtual Desktop with NVIDIA RTX PRO 6000 GPU, supporting up to 30 concurrent users with stable graphics and consistent performance. Single-host setups efficiently consolidate users, while multi-host configurations boost responsiveness and performance, especially for GPU-intensive tasks at higher user densities. All certification workloads passed successfully, confirming reliable GPU sharing and scalability. Azure AVD with RTX PRO 6000 proves suitable for enterprise CAD deployments, enabling centralized infrastructure, high user density, reduced hardware dependency, and scalable engineering workflows for real-world tasks and assemblies.

From Prompt to Provisioned: A Closer Look at the Azure Deployment Agent

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 06/23/2026

Summary: The article introduces the Azure Deployment Agent, showcased at the Microsoft Azure Infra Summit 2026. This AI-driven tool helps IT professionals design, review, and provision Azure workloads by conversing in natural language, grounding plans in the Well-Architected Framework, and generating production-ready infrastructure code. It enables consistent, efficient deployments, supports both Terraform and Bicep, integrates with Copilot and popular IDEs, and is open-source for customization. Currently focused on new workloads, the agent aims to simplify cloud architecture and standardize operations, with ongoing improvements for existing estates.

Deploy an Azure Landing Zone in About Twelve Minutes with the ALZ IaC Accelerator

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 06/24/2026

Summary: The article highlights the Azure Landing Zone (ALZ) Infrastructure as Code Accelerator, showcased at the Microsoft Azure Infra Summit 2026. The ALZ Accelerator drastically reduces deployment time for secure, governed Azure platforms from weeks to about twelve minutes using Bicep or Terraform modules. It automates setup, supports multiple scenarios and options, aligns with the Well-Architected Framework, and is open source. The accelerator enables rapid, production-grade deployments, saving IT pros from manual configurations, and supports both GitHub and Azure DevOps pipelines, making cloud adoption faster and easier.

Announcing the Path to Production for Agents Webinar Series

Team Blog: Azure Architecture

Author: brauerblogs

Published: 06/09/2026

Summary: The Path to Production for Agents Webinar Series, held July 27-28, helps organizations transition AI projects from prototypes to secure, scalable, production-ready systems. Sessions cover governance frameworks, production architecture, multi-agent design, operational best practices, security, observability, and optimization techniques. Attendees will learn practical, actionable patterns for deploying and managing AI agents at enterprise scale, with real-world examples and reference architectures. The series targets architects, engineers, and technical leaders seeking to operationalize AI, and offers follow-up engagements for Microsoft customers to implement these practices. Registration is available online.

Revolutionizing Document Intelligence: Scaling Construction Industries with AI-Driven Extraction

Team Blog: Azure Architecture

Author: gauravbhardwaj

Published: 06/18/2026

Summary: The article explores how Generative AI and Azure AI services are revolutionizing document extraction in the construction industry, addressing challenges like low productivity and high costs. By automating the analysis of design documents, AI increases accuracy, reduces manual labor, and improves coordination. The proposed hybrid architecture combines deterministic extraction with generative gap-filling for scalable, auditable workflows, resulting in cost savings, reduced errors, and faster project delivery. The solution emphasizes robust security and adaptability, offering a blueprint for AI-driven document intelligence across multiple sectors, including insurance, legal, healthcare, and finance.

Azure Availability Zone Mapping and VM Resilience Analysis Guidance using SRE.AZURE.COM Agent

Team Blog: FastTrack for Azure

Author: munieswar_avulapalli

Published: 06/08/2026

Summary: The article explains how SRE.Azure.com helps Azure engineers analyze Availability Zone mappings and VM resilience. Logical zone numbers (1, 2, 3) do not directly map to physical datacenter zones across subscriptions, impacting high availability and disaster recovery planning. The SRE agent enables discovery of zone mappings, VM distribution, resilience gaps, and generates reports. Understanding these mappings is essential for ensuring workload separation and compliance. The guidance includes suggested prompts for generating analysis and emphasizes that physical separation cannot be assumed based solely on logical zone numbers.

Azure Virtual Desktop supports greater application and identity functionality with latest updates

Team Blog: Azure Virtual Desktop

Author: Christian_Montoya

Published: 06/02/2026

Summary: Microsoft has announced new Azure Virtual Desktop updates, including general availability of FSLogix user profile management and Azure Role-based Access Control (RBAC) for external identities. SAML IdP can now be configured as domainless (public preview), easing integration for developers. External identity support is expanded to Android and macOS platforms in Azure public cloud and is generally available for US Government cloud. These enhancements streamline access for users outside organizations without needing new accounts and improve application and identity functionality. More technical details and resources are available on Microsoft’s Learn and Community pages.

A deep dive into Azure Bastion session recording

Team Blog: Azure Network Security

Author: juquint

Published: 06/11/2026

Summary: Azure Bastion Premium’s session recording feature captures RDP and SSH sessions for improved security, compliance, and forensic analysis. Recordings are stored in Azure Storage accounts, authenticated via either SAS URL or Managed Identity. While SAS URLs require manual token management and pose security risks, Managed Identity offers automated, secure authentication with no credentials to rotate, better RBAC integration, and improved compliance. The article details setup steps for both options and recommends Managed Identity for enterprise environments due to its simplicity and robust security. Session recordings are easily accessed within the Bastion resource’s Session recordings blade.

Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture

Team Blog: Azure Network Security

Author: AvanishYadav

Published: 06/03/2026

Summary: The article advocates for a security-driven, DMZ-first cloud landing zone architecture in Microsoft Azure, emphasizing defense-in-depth and clear trust boundaries for traffic flows. It recommends multi-hub designs to separate Internet-facing (DMZ) and internal (Core) traffic inspection, improving security, scalability, and operational clarity. Scenarios using third-party firewalls, Azure Firewall, and Azure Virtual WAN illustrate approaches for inbound, outbound, East-West, and hybrid connectivity. The distributed hub-and-DMZ model reduces complexity, supports regulatory compliance, and enhances resiliency, making it essential for large, regulated, and multi-region enterprise workloads.

Kubernetes Center: Security & LTS/Out-of-Support Version Insights Now Available

Team Blog: Azure Infrastructure

Author: Harsha_Nair

Published: 06/01/2026

Summary: Kubernetes Center now offers enhanced security and cluster version support insights in the Azure portal. The new Security page provides an overview of vulnerabilities, runtime alerts, misconfigurations, and regulatory compliance, with actionable recommendations, requiring Microsoft Defender for Containers. The Cluster Version Support Status panel displays Kubernetes version support across clusters, highlighting those expiring soon, out-of-support, or eligible for Long Term Support (LTS), and enables easy remediation. These features help platform teams monitor security posture, prevent version drift, address misconfigurations, and report compliance efficiently across all AKS clusters.

Ginkgo Bioworks and Microsoft Discovery: Bringing agentic AI to biological discovery

Team Blog: Azure Infrastructure

Author: NihitPokhrel

Published: 06/09/2026

Summary: Microsoft and Ginkgo Bioworks are collaborating to integrate Microsoft Discovery’s agentic AI platform with Ginkgo’s autonomous lab infrastructure, enabling researchers to design, execute, and analyze biological experiments seamlessly. This integration supports iterative, Design–Make–Test–Analyze workflows, streamlining experiment planning, execution, and data analysis. The partnership aims to accelerate biological discovery by increasing speed, scale, transparency, and reproducibility, reducing manual effort and connecting AI-driven reasoning directly to real-world lab validation. The approach is extensible, supporting broader scientific and engineering research needs.

New ways to learn and demonstrate skills

Team Blog: Microsoft Learn

Author: CameronPercy

Published: 06/02/2026

Summary: Microsoft announced new ways for developers to learn and demonstrate skills, including Microsoft Pro Badges—credentials that recognize real-world proficiency without separate tests, assessed via Verified Proficiency telemetry. Pro Badges launch in June 2026, starting with GitHub Copilot. Microsoft Applied Skills lab assessments will soon award Pro Badges. New co-authored AI skilling paths, beginning with Anthropic, are available in AI Skills Navigator. The Microsoft AI Skills Fest (June 8–12, 2026) offers practical sessions, a hackathon, and opportunities to earn certification vouchers, all aimed at advancing developers’ real-world capabilities.

Deep-reasoning agents for academic research: The right tool for the task

Team Blog: Microsoft Learn

Author: DarcyOgden

Published: 06/23/2026

Summary: The article discusses how deep-reasoning agents, like Researcher and Analyst in Microsoft 365 Copilot, enhance academic research by supporting source comparison, assumption testing, and data analysis. It compares these specialized tools to general-purpose AI, highlighting their alignment with academic standards. The Academic Researcher’s Guide to Deep-Reasoning Agents offers practical advice for selecting and using these tools effectively, managing limitations, and improving outputs. Researchers are encouraged to treat these AI agents as supportive tools, document their processes, and critically evaluate results to ensure rigorous research practices.

Public preview: Automatic OS Image Upgrades for VMSS Flex

Team Blog: Azure Compute

Author: BMahboob

Published: 06/01/2026

Summary: Azure has launched a public preview of Automatic OS Image Upgrades for Virtual Machine Scale Sets (VMSS) using Flexible Orchestration Mode. This feature streamlines OS updates across VMSS fleets, enhancing security, performance, and compliance while reducing manual effort and operational complexity. It provides consistent, fleet-wide orchestration with health-based safety measures. To use it, prerequisites include registering the feature, installing health extensions, and enabling the upgrade policy. Azure is now expanding onboarding and validating the experience across more workloads. Feedback is encouraged during the preview.

Announcing Preview of Guest RDMA for Azure Boost

Team Blog: Azure Compute

Author: MengxiWu

Published: 06/02/2026

Summary: Microsoft has launched a preview of Guest RDMA in Azure’s UK South region, enabling high-throughput, ultra-low latency networking within guest virtual machines via Azure Boost. This allows VMs to bypass the traditional networking stack, reducing CPU usage and improving performance for AI, storage, database, and HPC workloads. Guest RDMA supports various VM series and Linux distributions, but is currently limited to direct VM-to-VM connections within a VNET. Broader network scenarios will be supported at general availability. Interested users can sign up for the preview and provide feedback to Microsoft.

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

Team Blog: FinOps

Author: Dirk_Brinkmann

Published: 06/11/2026

Summary: The article explains how FinOps teams can use Azure's Benefit Recommendations API and a companion PowerShell script to extract hourly Pay-As-You-Go (PAYG) usage and alternative Savings Plan commitment levels. This approach enables more accurate, data-driven decisions instead of relying on a single recommended figure. The script produces analyst-friendly outputs for deeper analysis, allowing teams to visualize demand patterns, optimize savings, and minimize wastage. Full documentation and code are available on GitHub, encouraging users to improve their Azure savings strategies with transparent, defensible data.

Introducing GitHub Pre-Purchase Plans: A Simpler Way to Plan Your GitHub Spend

Team Blog: FinOps

Author: kyleikeda

Published: 06/17/2026

Summary: GitHub Pre-Purchase Plans offer organizations a way to simplify and save on GitHub spending by committing upfront to a prepaid amount, which can be used across eligible services over 12 months. Larger commitments unlock higher discounts, up to 15%. This approach enables predictable budgeting for variable, usage-based costs like Copilot and AI Credits, and aligns GitHub billing with Azure subscriptions. Two plan types are available via Azure Reservations, providing flexibility for platform-wide or AI-specific usage. Pre-Purchase Plans do not replace existing purchasing methods but offer an additional budgeting option for commercial customers.

Automating Daily MDE Compliance Monitoring Across Azure VMs

Team Blog: Core Infrastructure and Security

Author: SayanRoy

Published: 06/15/2026

Summary: The article details a Logic App solution for automating daily Microsoft Defender for Endpoint (MDE) compliance checks across Azure VMs. It addresses gaps where VMs may silently lose MDE coverage and provides automated owner notifications, daily IT summary reports with CSV attachments, and explicit handling of VMs lacking owner tags. The workflow queries all running Azure VMs, matches them to MDE device records, and sends compliance alerts. It requires a Logic App, managed identity, specific API permissions, and proper tagging. The approach streamlines compliance monitoring, reduces manual effort, and ensures prompt visibility of security gaps.

Security Copilot RBAC for Embedded Experience in Unified Security Platform

Team Blog: Core Infrastructure and Security

Author: SantoshPargi

Published: 06/17/2026

Summary: The article explains how Microsoft Security Copilot integrates AI-powered assistance directly within security platforms like Defender XDR and Sentinel, streamlining SOC operations. It details a three-layer Role-Based Access Control (RBAC) model—Security Copilot, Microsoft Entra, and service-specific roles—to ensure secure, least-privilege access. Copilot uses an On-Behalf-Of model, limiting data access to user permissions. Key use cases include summarization, guided response, script analysis, and reporting, all mapped to SOC processes. Proper RBAC alignment enables Copilot to accelerate investigations, enhance accuracy, and strengthen security while maintaining compliance and governance.

Simpler, scalable file share management in Azure - now generally available

Team Blog: Azure Storage

Author: VincentLiu

Published: 06/02/2026

Summary: Microsoft Azure has announced the general availability of a new, simplified file share management experience for premium SSD NFS file shares. This update enables independent provisioning, security, and billing for each file share, aligning management boundaries to workload needs. Key benefits include faster provisioning, enhanced scalability (up to 10,000 shares per region), share-level security and networking, improved cost tracking, and robust data protection with snapshots. The new experience supports Infrastructure-as-Code automation and is designed to reduce complexity, improve operational agility, and facilitate easier chargeback and resource management for Linux workloads in Azure.

From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API

Team Blog: Azure Storage

Author: GeertVanTeylingen

Published: 06/15/2026

Summary: The article explains how Azure NetApp Files, OneLake, Azure AI Search, and Azure OpenAI combine to create an AI-powered knowledge pipeline for enterprise file data. This pipeline indexes and semantically searches files in place, enabling retrieval-augmented generation (RAG) for accurate, traceable, and grounded AI responses without moving or duplicating data. The architecture ensures compliance, scalability, and seamless integration with existing workflows, transforming file data into a living, queryable resource. It prepares enterprises for AI-driven user experiences, like Copilot, by delivering controlled, authoritative answers with source citations.

Three lessons that make or break your AWS-to-Azure workload migration

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 06/19/2026

Summary: The article highlights three crucial lessons for successful AWS-to-Azure workload migration: (1) Ensure ongoing stakeholder alignment through readiness assessments and clear approvals; (2) migrate workloads like-for-like before optimizing to avoid complexity and build confidence; and (3) use a blue-green cutover strategy to minimize risk and downtime, enabling easy rollback. Avoid common pitfalls like overengineering, misaligned stakeholders, and believing in instant cutovers. The article recommends Microsoft’s structured migration process and resources for further guidance.

Generate at scale code insights in Azure Migrate using GitHub Copilot Modernize CLI (preview)

Team Blog: Azure Migration and Modernization

Author: Nikita_Bajaj

Published: 06/19/2026

Summary: Azure Migrate now integrates with GitHub Copilot Modernize CLI (preview) to provide scalable code insights for .NET and Java web apps. This collaboration enables migration teams to assess multiple applications simultaneously, reduce analysis time, and make informed refactor-versus-replatform decisions. Users receive actionable code-fix recommendations and effort estimates, improving modernization planning and adherence to security guidelines. Setup involves downloading a configuration file from Azure Migrate, mapping repositories, and running the CLI. Code assessments are automatically reported back to Azure Migrate for centralized review and remediation guidance.

DoH is now generally available on Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 06/11/2026

Summary: Microsoft has announced general availability of DNS over HTTPS (DoH) for Windows DNS Server on Windows Server 2025, enabling encrypted and authenticated DNS client-to-server traffic. This feature enhances privacy, reduces spoofing risks, and supports Zero Trust architectures without requiring new resolver infrastructure. Organizations can deploy DoH alongside traditional DNS, preserving compatibility and allowing incremental adoption. Built on IETF standards, DoH helps meet regulatory requirements and strengthens DNS security. Future updates will support encrypted server-to-resolver traffic, advancing fully secure DNS resolution. The release is production-ready, reflecting feedback from real-world enterprise deployments.

Announcing Windows CLAT Public Preview

Team Blog: Networking

Author: JimAlumbaugh

Published: 06/09/2026

Summary: Microsoft has announced the public preview of Windows CLAT, a feature designed to aid IPv6 adoption by enabling IPv4/IPv6 translation. Available in Windows Insider Canary build #29599-1000 and rolling out to other channels, it now supports Group Policy Object (GPO) configuration. The preview is for evaluation only, not production use, and feedback is encouraged. Notable limitations include lack of support for DHCPv6 Prefix Delegation and Windows Subsystem for Linux, with known issues in Wi-Fi roaming and diagnostics. Participant feedback from the private preview has shaped this release.

ARM MCP Server: A Catalog of 24 PoCs

Team Blog: Azure Governance and Management

Author: varghesejoji

Published: 06/19/2026

Summary: The article introduces the Azure Resource Manager MCP Server, a remote Model Context Protocol server enabling AI agents to perform Azure infrastructure operations using six core tools. It details the arm-mcp-poc-catalog, a public repository of 24 proof-of-concept agents covering governance, FinOps, platform engineering, and SRE scenarios. The catalog emphasizes deterministic, safe agent operations, with most PoCs focused on read-only tasks. Write-capable agents are carefully gated. The Reliability Posture Scorecard is highlighted as a reference implementation. The article encourages teams to explore and adapt these PoCs for practical cloud management needs.

When Arc Goes Silent: Turning Visibility Gaps into SOC Action

absharan — Fri, 10 Jul 2026 12:07:15 GMT

Hybrid blind spots rarely announce themselves. They appear when an Azure Arc-enabled server drops out, health signals go stale, and the SOC loses confidence in monitoring coverage. This playbook uses Microsoft Sentinel and Logic Apps to turn that noise into one clear daily signal the team can act on.

The problem: too much noise, not enough assurance

One unhealthy server, one alert, one more email—at scale, that does not help the SOC. What leaders need is assurance: where visibility is weakening, which systems matter, and when action is needed.

The use case: daily assurance for hybrid monitoring coverage

The use case is simple: identify Arc-enabled servers that stay unhealthy beyond a set threshold, such as 30 minutes, and send one consolidated summary each day. For a CISO, this improves assurance. For a SOC Manager, it cuts noise and helps teams prioritize faster.

Solution overview: simple automation, stronger operational signal

The workflow runs on a schedule, queries Log Analytics, filters Arc health issues, formats the results into a clean HTML report, and sends a single email through Office 365 Outlook. The outcome is not more telemetry—it is a better operational signal.

Prerequisites

One or more Azure Arc-enabled servers connected to Azure.
Azure Monitor Agent installed and sending heartbeat data to a Log Analytics workspace.
Microsoft Sentinel enabled on the target workspace if the playbook is being used as part of SOC operations.
A Logic App with permissions to run the query and send email through Office 365 Outlook.
A reviewed threshold, recipient list, and notification cadence aligned to your operating model.

How the workflow creates decision-ready visibility

In practice, this becomes a daily control: check Arc health, isolate persistent issues, and route one concise summary to the right teams. That gives the SOC a cleaner way to review monitoring gaps before they become bigger operational problems.

Why this matters to a CISO and SOC Manager

For security leadership, this is about confidence. If Arc health degrades on systems tied to monitoring, policy, or data collection, the risk is not just technical—it is a visibility gap. This playbook helps surface that gap early and in a form teams can act on quickly.

Three practical scenarios where this playbook delivers value

Reduce SOC noise.Replace scattered alerts with one daily summary.
Strengthen executive assurance.Highlight persistent blind spots before they turn into escalations.
Improve team coordination.Give security and infrastructure teams one shared view of the issue.

Sample KQL to identify persistent Arc monitoring gaps

This sample query uses the Heartbeat table to identify Azure Arc-connected machines whose latest heartbeat is older than the defined threshold. It is a practical starting point and can be tuned further based on the environment and data collection design.

let ThresholdTime = 30; AzureActivity | where TimeGenerated > ago(1d) | where CategoryValue == "ResourceHealth" | where parse_json(Properties).currentHealthStatus == "Unavailable" | where ActivityStatusValue == "Active" | extend ResourceType = Properties_d.resourceProviderValue | where ResourceType == "MICROSOFT.HYBRIDCOMPUTE" | extend StartTime = TimeGenerated | extend ServerName = Properties_d.resource | join kind=leftouter ( AzureActivity | where ActivityStatusValue == "Resolved" | extend ResourceType = Properties_d.resourceProviderValue | where ResourceType == "MICROSOFT.HYBRIDCOMPUTE" | extend EndTime = TimeGenerated ) on CorrelationId | extend Minutes_OfflineTillResolve = datetime_diff('minute', EndTime, StartTime) | project ServerName, StartTime, EndTime, CorrelationId, Minutes_OfflineTillResolve, Level, ActivityStatusValue1, ResourceGroup, OperationNameValue, SubscriptionId, ResourceProvider, Type, CategoryValue, ActivityStatusValue | extend TotalMinutes_Offline = datetime_diff('minute', now(), StartTime) | where TotalMinutes_Offline >= ThresholdTime and ActivityStatusValue1 !has "Resolved" | order by TotalMinutes_Offline desc

Operational flow

ARM Template: microsoft-security-operations-toolkit/Microsoft Sentinel/Automation/Playbooks/AzureArcServerMonitoring.playbook.json at 1e3aeff329e0d9b1d7caf2e4bfbc8476dfdb2ff2 · Abhishek-Sharan/microsoft-security-operations-toolkit

Customization Ideas:

Adjust the heartbeat threshold based on server criticality or business hours.
Route summaries to different teams based on subscription, resource group, or server tags.
Send notifications to Microsoft Teams in addition to, or instead of, email.
Enrich the output with owner, business service, or environment metadata.
Trigger incident creation only for high-priority or repeated visibility gaps.

Closing perspective

The best SOC automations do not just collect signals—they create clarity. This playbook helps security teams spot Arc-related monitoring gaps early, reduce noise, and act with more confidence.

Azure Database Security Newsletter - July 2026

PieterVanhove — Tue, 07 Jul 2026 11:47:08 GMT

AI agents are changing how applications interact with data, and database security needs to evolve with them. In this July 2026 edition of the Azure Database Platform Security Newsletter, we focus on what this shift means for identity, access, monitoring, and data protection, along with the latest security feature updates and practical resources to help teams strengthen their database security posture.

AI agents are quickly becoming a new layer in how applications interact with data. Unlike traditional applications that follow predictable workflows, agents operate with more autonomy. They can generate queries dynamically, explore data, and act on behalf of users or systems.

This shift changes the database security model.

Agents do not just introduce new risks, they amplify existing ones. Over-privileged access can scale quickly, identity boundaries can become harder to trace, and dynamically generated queries can increase the risk of unintended data exposure or manipulation.

In this new reality, every AI agent effectively becomes a database user with the ability to access, reason over, and act on sensitive data.

Securing data in an agentic world requires a shift in mindset:

Identity-first security: every agent should have a unique, traceable identity.
Least privilege by default: access should be tightly scoped to the task at hand.
Data-aware protection: only the data that is strictly required should be exposed.
Continuous monitoring: assume issues can occur and detect them early.

Azure SQL provides a broad set of security capabilities, from authentication and fine-grained access control to encryption, masking, auditing, and threat detection. Together, these capabilities enable a defense-in-depth approach for agent-driven scenarios.

Feature highlights 💡

Transparent Data Encryption in Azure SQL Database now supports AES keys (Preview)

Azure SQL Database now supports symmetric AES keys for Transparent Data Encryption (TDE) with customer-managed keys in public preview. This gives organizations another option for protecting data at rest while keeping control of key management.

For teams thinking about long-term cryptographic resilience, this preview is especially relevant. TDE with customer-managed keys has traditionally used asymmetric RSA-based key protectors, while broader industry guidance is increasingly focused on preparing for a post-quantum cryptographic future and adopting cryptographic approaches that are better aligned with that transition.

This update aligns with broader security guidance, including the NSA’s CNSA 2.0 recommendations, which emphasize modern cryptographic planning for a quantum-resistant future. For organizations building crypto agility into their platforms, AES support is a practical step in that direction.

Learn more: Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview)

General Availability: Microsoft Entra server principals for Azure SQL Database

Azure SQL Database has historically lacked support for server-level Microsoft Entra principals, requiring customers to manage identities separately in each database. This has been a migration blocker for enterprise customers coming from SQL Server, where centralized login and access management is standard.

With this release, Azure SQL Database now supports server-level Microsoft Entra principals. Customers can create identities once, apply them consistently across databases, and operate with a unified, enterprise-grade identity and access model aligned with SQL Server and Azure SQL Managed Instance.

Learn more: Generally Available: Microsoft Entra Server Principals and Server Roles for Azure SQL Database.

Cross-tenant customer-managed keys for Azure Database for PostgreSQL Flexible Server (Preview)

This preview allows customers to encrypt data at rest using an Azure Key Vault key that resides in a different Microsoft Entra tenant than the database service. It is especially relevant for ISVs and customers in regulated industries that need clear separation of duties between key ownership and service operation.

Customers retain control over key lifecycle management, including rotation and revocation, while authentication to the customer-owned Key Vault is handled through federated identity with Microsoft Entra ID for cross-tenant access.

Learn more: Data Encryption - Azure Database for PostgreSQL | Microsoft Learn

Defender security posture assessments for Azure Database for PostgreSQL Flexible Server (GA)

Microsoft Defender Cloud Security Posture Management (CSPM) assessments for Azure Database for PostgreSQL Flexible Server are now available in general availability. This capability introduces built-in security assessments that continuously evaluate PostgreSQL server configurations against best practices, helping identify vulnerabilities and misconfigurations with actionable remediation guidance. A core set of assessments is available at launch, with additional coverage planned for future releases. Assessments are automatically available for PostgreSQL servers where Microsoft Defender for Cloud is already enabled, requiring no additional setup or costs.

Learn more: Microsoft Defender for Cloud - Azure Database for PostgreSQL | Microsoft Learn

Best Practices Corner ⚖️

Move to secure-by-default configurations

Modern data platforms should reduce the need for manual hardening by enabling strong defaults out of the box.

Enforce encrypted connections by default.
Disable insecure or legacy options where possible.
Adopt platform defaults that align with compliance standards.

This shifts security from being configuration-driven to posture-driven, reducing the risk of misconfiguration, which remains one of the leading causes of data exposure.

Classify data first, protect it second

You cannot secure what you do not understand. Start by identifying where sensitive data lives, then use that understanding to apply the right protections.

Use Data Discovery & Classification to identify sensitive data.
Apply labels and information types consistently.
Use those labels to drive masking, encryption, and governance policies.

Why this matters: Security controls are only effective when they are data-aware. Classification provides the foundation for applying the right protection to the right data, especially for regulated workloads.

Continuously assess and remediate vulnerabilities

Security posture is not static. It requires continuous validation and timely remediation.

Run Vulnerability Assessment scans regularly.
Track deviations from baseline security policies.
Act on remediation guidance proactively.

Why this matters: Even well-configured systems drift over time. Continuous assessment helps detect misconfigurations early and maintain a strong, compliant security posture without relying on manual reviews.

Blogs and Video Spotlight 🅱️

Over the last three months, we published several posts covering major releases, platform updates, and practical security guidance. These resources provide deeper technical context and implementation guidance for teams working across Azure SQL, Azure Database for PostgreSQL, Azure Database for MySQL, and Azure Cosmos DB.

Azure SQL Retiring The No Minimum TLS Option

Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively | Microsoft Community Hub

TLS Certificate Pinning in PostgreSQL and MySQL: Risks, Rotations, and Best Practices

I'm Starting a New Cosmos DB App. What Security Do I Actually Need? - Azure Cosmos DB Blog

Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview) | Microsoft Community Hub

Which Azure Cosmos DB Role Does My App Need? - Azure Cosmos DB Blog

Generally Available: Microsoft Entra Server Principals and Server Roles for Azure SQL Database | Microsoft Community Hub

Community & Events 👥

The data platform security team will be present at several community and industry events. If you are attending, come and say hello.

Where to meet us next

Microsoft Fabric and SQL Conference, Barcelona, 28 September to 01 October 2026

dataMinds Connect, Mechelen, 12 to 14 October 2026

Techorama, Utrecht, 26 to 28 October 2026

Recent community highlights

SQLBits, Wales, 22 to 25 April 2026

Azure SQL Bangalore User Group Meeting, Bangalore, 13 June

Call to action 📢

As AI agents become a more active layer between applications, users, and data, now is the right time to review how they access your database platform. Treat every agent as a database user: confirm that each one has a unique identity, validate that permissions follow least privilege, and monitor agent-driven activity for unusual access patterns. A focused access review today can help reduce the risk of unintended data exposure as agentic workloads continue to grow.

Turning Azure Policy Signals into Actionable Governance Insights

absharan — Mon, 06 Jul 2026 12:40:50 GMT

Most Azure Policy reporting stops at compliance status. Useful, yes — but not enough. When a control fails, teams need to know what failed, why it matters, and who should act.

That gap becomes obvious at enterprise scale. A failed policy evaluation is only a signal. By itself, it does not tell you whether the issue affects recovery, auditability, telemetry, or another control leaders care about.

That is why joining PolicyStates with PolicyAssignments matters. One tells you the outcome. The other tells you which control was applied, where, and in what governance context. Together, they turn Azure Policy from a compliance feed into a control intelligence layer.

The problem: PolicyStates alone tells you what is non-compliant, but not always why it matters

Microsoft’s sample ARG queries quickly show which resources are non-compliant. Helpful, but still incomplete. They show the result, not the business meaning.

At enterprise scale, that distinction matters. A storage account without blob soft delete is a recovery risk. Missing Azure Activity logs creates an audit gap. A virtual machine without Azure Monitor Agent creates a telemetry blind spot. Azure Policy shows the state. The join to PolicyAssignments explains why it matters.

There is also a technical reason to care about assignments. The same PolicyDefinitionId can appear in multiple assignments across different scopes. That makes PolicyAssignmentId the operational key.

How Azure Policy compliance data flows

Azure Policy evaluates resources against JSON-based rules. Those rules are packaged as policy definitions and can be grouped into initiatives. Once assigned to a scope, the policy engine evaluates matching resources during creation, updates, assignment changes, and regular compliance cycles. The results are exposed through PolicyStates and PolicyEvents, and can also be queried through Azure Resource Graph.

This is the architecture flow for turning the ARG query into a scheduled governance report through Logic App:

The key shift is operational. A Logic App can run the ARG query on a schedule, format the results, and email them to stakeholders. That turns a manual check into a repeatable governance report.

The analytical pattern: enrich compliance with assignment context

The analytical flow is straightforward:

Configure a Recurrence trigger in Logic App so the report runs on the schedule you need.
Use an HTTP action with managed identity to run the ARG query against PolicyStates and join it to PolicyAssignments.
Filter on the control assignments that matter to your organisation and shape the response into a compact HTML table or CSV.
Send the output by email to governance, engineering, or audit stakeholders so the insight reaches people without requiring them to open the portal.

In practice, the query starts with non-compliant resources and enriches them with assignment details such as the assignment name and optional metadata like owner. That is the shift from raw signal to governance insight.

A simple implementation pattern is: schedule the Logic App, run the ARG query with managed identity, format the output, and send the report. HTML works well for leadership emails; CSV is better for downstream analysis.

ARM template for the Logic App

If you want to deploy this pattern instead of building it step by step, I have also published an ARM template for the Logic App in my GitHub repository. The template is intended to help you stand up the scheduled policy compliance workflow faster and then customise the query, email recipients, and formatting for your own environment.

This makes the architecture in this post directly reusable: schedule the Logic App, run the ARG query, shape the output, and send a control-focused report without having to assemble the workflow from scratch. See the repository for the template and related Microsoft Sentinel automation content.

Reference ARG query

policyResources | where type =~ 'microsoft.policyinsights/policystates' | where properties.complianceState == 'NonCompliant' | extend ResourceId = tostring(properties.resourceId), PolicyAssignmentId = tolower(trim(@" ", tostring(properties.policyAssignmentId))), SubscriptionId = tostring(subscriptionId), LastEvaluated = todatetime(properties.timestamp) | extend ResourceName = tostring(extract(@"[^/]+$", 0, ResourceId)) | extend ResourceProvider = tostring(extract(@"providers/([^/]+)/", 1, ResourceId)) | extend ResourceCategory = case( ResourceId has "Microsoft.Compute/virtualMachines", "VM", ResourceId has "Microsoft.Storage/storageAccounts", "Storage", ResourceId has "Microsoft.Network/virtualNetworks", "Network", ResourceId has "Microsoft.Sql/servers", "SQL", ResourceId has "Microsoft.KeyVault/vaults", "Key Vault", ResourceProvider =~ "Microsoft.Compute", "Compute", ResourceProvider =~ "Microsoft.Storage", "Storage", ResourceProvider =~ "Microsoft.Network", "Network", ResourceProvider =~ "Microsoft.KeyVault", "Key Vault", "Other" ) | project ResourceId, ResourceName, ResourceCategory, SubscriptionId, PolicyAssignmentId, LastEvaluated | join kind=inner ( policyResources | where type =~ 'microsoft.authorization/policyassignments' | extend AssignmentName = tostring(properties.displayName), AssignmentId = tolower(trim(@" ", tostring(id))), Scope = tostring(properties.scope), PolicyOwner = tostring(properties.metadata.owner) | where AssignmentName has "CSTM--Configure blob soft delete on a storage account" or AssignmentName has "Configure Azure Activity logs to stream to specified Log Analytics workspace" or AssignmentName has "Audit diagnostic setting for selected resource types" | project AssignmentId, AssignmentName, Scope, PolicyOwner ) on $left.PolicyAssignmentId == $right.AssignmentId | project SubscriptionId, ResourceId, ResourceName, ResourceCategory, AssignmentName, AssignmentId, Scope, ['LastEvaluated[UTC]'] = LastEvaluated

What this query is doing — in plain English

This query finds Azure resources that are currently NonCompliant with Azure Policies by reading data from the PolicyStates table in Azure Resource Graph.
It extracts useful details such as Resource ID, Resource Name, Resource Type/Category, Subscription ID, Policy Assignment ID, and the last evaluation timestamp.
Resources are categorized into groups like VM, Storage, Network, SQL, and Key Vault based on their resource type/provider.
It then joins the non-compliant resources with specific policy assignments (three named policies) to show which policy caused the non-compliance, along with the policy scope, and evaluation time.

Why CISOs and governance leaders should care

For a CISO, this is not about counting failed evaluations. It is about knowing whether critical controls are drifting, where the risk sits, and who owns the response.

Three use cases stand out:

Audit readiness: show control-focused evidence instead of a flat list of resource IDs.
Ownership: enrich assignments with metadata so findings can be routed to the right team faster.
Prioritization: focus on the controls that matter now, not every non-compliant resource in the estate.

Operational benefits: scalable, repeatable, and security-friendly

From an engineering perspective, this pattern is attractive because it is repeatable, scalable, and aligned to the native Azure Policy data model.

It also fits naturally into operational tooling. The enriched output can feed workbooks, dashboards, Sentinel content, and alerting workflows.

Closing thought

At small scale, Azure Policy can be reviewed in the portal. At enterprise scale, that quickly becomes noise. The better question is not Which resources are non-compliant? It is Which important controls are failing, where, and who should act?

That is what makes this pattern powerful: it turns Azure Policy from a compliance dashboard into a control intelligence layer that works for both engineers and executives.

Windows 365 Boot

MichaelHildebrand — Sat, 04 Jul 2026 17:01:23 GMT

Hi folks – Mike Hildebrand here! It’s the July 4^th holiday here in the good 'ol USA and happens to also be our country’s 250^th birthday … and where I live, that means it’s probably hot. VERY hot. So, I’m taking some time to enjoy the A/C and type up a ‘cool’ post about a ‘cool’ solution.

In the land of Windows 365, there are a couple of physical endpoint connectivity options – the Windows App or browser from any device and thin-client or other purpose-built devices, like our own Link (and one soon coming from Asus).

We also have another option called Windows 365 Boot. In this nifty little situation, we take a full-throated Windows 11 device and apply policy from Intune to transform the shell and other settings into a Link-like experience.

NOTE: For a long time, the Boot configuration process was only configurable via a ‘black-box’ guided flow in the Intune portal – and that works just fine. However, after an update of docs and the Intune Settings Catalog, the W365 Boot configurations can now be hand-carved like all of your other Intune configuration policies.

Recently, I was part of a customer conversation where they had a substantial quantity of Flex Dedicated CPCs used by rotating call center staff and accessed from a fleet of Windows 11 PCs deployed at hot-desk stations. They wondered about a model to simplify and streamline access directly to the CPCs, bypassing the local Windows OS, which wasn’t used/needed and sometimes caused confusion.

The physical devices were still ‘current’ and had a lot of life left (i.e. warranty coverage, driver and firmware support, parts availability, etc.) - and due to the price-jumps of new devices, it made ‘dollars and sense’ ( 🙂 ) to leverage that investment and re-purpose them.

They also wondered if they could use Autopilot in ‘Self-deploy’ mode to further automate the deployment process for these endpoints.

“Let’s try it out”

I proposed a rapid, off-the-cuff ‘right now’ PoC to try out the W365 Boot scenario in their environment and they were up for it. These days, it’s common and easy to perform carefully controlled ‘production pilots’ to more accurately validate the proposed experience.

NOTE: Since the customer already had Entra, Intune, and modern management in steady-state operations for quite some time, we were able to make this idea very real, very fast.

We reset a few of the test PCs they use for their hot-desks and uploaded them into Autopilot via the Get-WindowsAutopilotInfo PowerShell script and the -online switch.

Entra – Create a Device Group

We created a device group in Entra for the PoC Boot devices and added the Autopilot-uploaded test devices into it as members

This group was used by Intune to target several different elements of the PoC:

o An Autopilot Self-deployment Profile - for an almost zero-touch rollout

o An Enrollment Status Page (ESP) profile - to prevent access to the Boot device until the Windows App is installed

o The Windows App – used by the Boot device to connect to Cloud PCs

o A W365 Boot Configuration Profile to transform the Windows 11 OS into a W365 Boot device

Intune - Autopilot Self-deploy Profile

We created an Autopilot ‘self-deployment’ profile via Intune, to automatically enroll the physical endpoints at the call center desks.

Autopilot self-deploy requires very little interaction at the endpoint - plug in power, connect to network and turn it on.

o There are some specific URLs and other requirements for Autopilot Self-deploy devices so be sure to check this (i.e. you can’t use Hyper-V VMs)

https://learn.microsoft.com/en-us/autopilot/self-deploying

Intune – Enrollment Status Page

We created an ESP targeted at the device group to block access to the Boot devices until the Windows App is installed.

Intune – Windows App

They already deploy the Windows App to ‘All Devices,’ so this step was easy 😊

The key thing here is make sure it installs in the ‘System’ context:

Intune - Boot Device Configuration Policy

We created a very simple Configuration Policy (two settings from the Settings Catalog – that’s it) in Intune to transform these self-deployed endpoints into “Shared PC Mode” Windows 365 Boot devices. These have minimal ‘end user’ configurations/apps because they boot to the W365 purpose-specific ‘cloud shell’ – which allows the user to sign in to the Boot device and be directly SSO’d into their CPC.

NOTE: The ‘Boot to Cloud PC Enhanced’ setting includes many other settings/behaviors but they’re all bundled up which makes it super easy to deploy this
NOTE: If the ‘Personalization > Company Name’ setting isn’t used, you’ll see ‘Cloud PC’ at the sign in screen

Self-deploy…oh the joy!

Plug it in; turn it on … Autopilot Self-deploy OOBE screen, followed by a brief ESP

NOTE: As part of the Autopilot deployment profile, a device naming template was applied and the devices were renamed; this was reflected in various portals/UIs

Before:

After:

“So, what does it look like for the users?”

I thought you’d never ask! A PIN, a touch and TA DA!

NOTE: The org already was using FIDO2 for these users, so they insert their FIDO2 key to the Boot device, enter the PIN for it, touch it for ‘proof of presence’ - and that’s it. No long username to type in; no long password to remember/type; no additional prompts. The users glide right through to their CPC desktop.

NOTE: Hello for Business (H4B) is supported for the “Dedicated Mode” Boot deployment option but since we used the “Shared PC Mode” setting, where H4B is not supported, we didn’t test. Maybe official H4B support will come later to Shared PC Mode, but given how easy FIDO2 is, and the fact that the target users already use FIDO keys, we didn’t spend any more time on H4B.

At the end of the shift, disconnect the session from the CPC desktop to get back to the Boot sign in screen:

A few FAQs

“What if a user has more than one CPC?”

Connection Center is supported via Boot – here’s one of my demo users, using Boot w/ more than one CPC:

Further, you can select ‘Connect automatically’ from the three dots of a specific CPC’s card; then you’ll always bypass the Connection Center and get SSO’d right into that one.

o To get back to the Connection Center from the Cloud PC, you can use the hotkey combo of <Ctrl> + <Windows key> + <Up Arrow>

o BONUS SECRET HOTKEY COMBO (just between us) – For detailed connection info, from the Cloud PC: <Ctrl> + <Windows key> + <Down Arrow>

“Can I customize the look and feel of the Boot sign in experience?”

Yes – There are policy settings for a custom icon, company name and wallpapers to help differentiate Boot devices from other PCs/devices.

o Personalization CSP | Microsoft Learn

- - TIP: those docs indicate needing to use a URL for files – you can use this syntax for local content already on the device: file:///C:/Folder/File.jpg

There you have it, folks … Windows 365 Boot (or, DAS BOOT!! as I like to sometimes yell) … in the form of a quick PoC.

P.S. A special shout-out is in order for Mr. Liu for his assistance and appreciation of the Boot scenarios.

Stay cool out there…

Hilde

Building C# and C++ Apps with GitHub Copilot CLI and Visual Studio 2026

hewagen — Thu, 02 Jul 2026 08:00:00 GMT

Most engineers learned Visual Studio through a mouse-driven workflow — New Project — open a project, click through a few dialogs, press F5. The GitHub Copilot CLI inverts that workflow: you describe the desired outcome in plain English (or any other language Copilot supports), and the agent scaffolds the project, drives MSBuild, resolves its own compiler errors, and explains the result. By the way: this style of working — you describe what you want and the AI does the actual programming and takes care of the rest — is also known as Vibe Coding. For Microsoft FTEs, this translates into measurably faster proofs of concept for customer escalations, reproduction builds, and internal tooling. Engineers outside Microsoft benefit in exactly the same way, as long as their organization — or their personal subscription — provides the corresponding Copilot entitlement.

This article documents the setup and workflow recommended for engineers onboarding to the CLI. The guidance is deliberately opinionated, assumes a clean Windows 11 installation, and has been verified end-to-end against the current Visual Studio 2026 Community (18.6.2) and Copilot CLI 1.0.56.

Why use the CLI at all?

Copilot is available inside Visual Studio, inside VS Code, in the browser, and on the command line. These front-ends share the same underlying model, but the user experiences differ significantly.

The CLI is the preferred choice in the following scenarios:

You want a single tool that drives the whole machine — installer flags, MSBuild, winget, certificates, registry, even vswhere — rather than only the files open in an editor.
You are working on a throwaway repro for a customer issue, where opening the full IDE is disproportionate.
You want repeatable, scriptable workflows. The CLI accepts instructions, plans and prompts that can be checked in, reviewed, and shared with the rest of your team.
You need to build small tools or short projects without deep programming expertise.

Prerequisites

Windows 11 (or Windows 10 22H2) with administrator rights for the install step.
Microsoft FTE GitHub account linked through the Open Source @ Microsoft portal and a Copilot Business or Enterprise seat assigned by your org. Engineers at other organizations use whichever GitHub identity their employer has assigned a Copilot seat to; individuals can substitute a personal GitHub account that holds a Copilot Pro or Pro+ subscription.
A modern terminal — Windows Terminal with PowerShell 7 is the supported combination.

Note Everything in this guide is built on supported, GA components. Nothing here requires private previews, MSIT exceptions, or non-public flags. If your tenant has additional Conditional Access policies, you may be prompted for MFA the first time you sign in.

Recommended: Run it all in a virtual machine

Before installing anything, an important recommendation: don't run the agent on your primary, company-managed laptop. The CLI — especially with --yolo — has full read, write and execute access to any directory you have trusted. A well-intentioned prompt such as "clean up the temp files in my projects folder" may delete production work if it is pointed at the wrong root. Compliance tooling, OneDrive Known Folder Move, and on-access antivirus on the corporate image also routinely conflict with build outputs and cause agent runs to fail in opaque ways.

The safe, repeatable pattern is to host Visual Studio 2026 and the Copilot CLI inside an isolated environment that can be snapshotted, reset, or discarded. The following options are all suitable:

A Microsoft Dev Box (preferred — already domain-joined, already monitored, and easily recreated from an image).
An Azure VM in your sponsored subscription, ideally with the Visual Studio image from the Marketplace.
A local Hyper-V or WSL2/Windows Sandbox-based Windows 11 VM for offline experimentation.

Important Treat the VM as ephemeral. Retain customer artifacts, screenshots and reproductions only within the VM (or in a dedicated OneDrive/SharePoint location outside the trusted Copilot directory). If something goes wrong, you reset the VM — not your corporate laptop.

Setting up the workspace

Select a workspace folder before performing any other step, and observe two rules:

Use a local path under your profile.
Do not place it on OneDrive, Known Folders Move, or any other sync root.

The rationale is mundane but consequential: the Copilot agent writes files, MSBuild writes obj\ and bin\, and OneDrive's file-system filter will conflict with all of them. You will observe ghost lock files, partially rewritten .cs files, and "the process cannot access the file" errors that are extremely difficult to diagnose.

# Recommended workspace root mkdir "$env:USERPROFILE\AppData\Local\Projects" cd "$env:USERPROFILE\AppData\Local\Projects"

Warning Also avoid %TEMP% for build output. MSBuild emits warning MSB8029, and cleanup tasks in some scheduled jobs may delete your intermediates mid-build.

Installing the Copilot CLI

Open an elevated PowerShell window — the package needs to register PowerShell 7 as a dependency on first run:

winget install GitHub.Copilot

Winget downloads the CLI itself (currently 1.0.56) and, on a fresh installation, also installs PowerShell 7 as a dependency. Once the installation completes, the elevated shell can be closed — do not run Copilot as administrator for day-to-day work.

Confirm the install in a normal (non-elevated) terminal:

copilot --version

Installing Visual Studio 2026 Community

The CLI does not require Visual Studio — it strictly requires only MSBuild and the appropriate toolchain. However, the Community edition is the most straightforward way to obtain a known-good, fully Microsoft-signed installation of MSBuild 18.6.x, the MSVC v145 toolset, and the Windows 10/11 SDK, all in a single step. Select the variant that matches your target workload:

Variant A — C# only (≈ 2.4 GB)

winget install --id Microsoft.VisualStudio.Community -e --source winget ` --override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \ --add Microsoft.Net.Component.4.8.1.SDK \ --add Microsoft.Net.Component.4.8.1.TargetingPack \ --add Microsoft.VisualStudio.Component.CSharp \ --includeRecommended --passive --norestart"

Variant B — C# + native C++ + C++/CLI (≈ 4.3 GB)

winget install --id Microsoft.VisualStudio.Community -e --source winget ` --override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \ --add Microsoft.VisualStudio.Workload.NativeDesktop \ --add Microsoft.VisualStudio.Component.VC.CLI.Support \ --add Microsoft.Net.Component.4.8.1.SDK \ --add Microsoft.Net.Component.4.8.1.TargetingPack \ --add Microsoft.VisualStudio.Component.CSharp \ --includeRecommended --passive --norestart"

A brief description of each component:

Component	Why it's there
Workload.ManagedDesktop	Brings WPF, WinForms, the .NET Framework 4.8.1 target packs and Roslyn analyzers.
Workload.NativeDesktop	Native C++ with the MSVC v145 toolset, Windows 10/11 SDK 10.0.26100, ATL/MFC if you add them.
VC.CLI.Support	The "C++/CLI support" component. Without it, anything with <CLRSupport>true</CLRSupport> fails to compile.
Net.Component.4.8.1.*	SDK + targeting pack for the .NET Framework 4.8.1 surface that ships with Windows.

As a Microsoft FTE you have access to Visual Studio Proffessional or Visual Studio Enterprise. If you already have installed a different version of Visual Studio, you don't need to install 2026 Community.

Important Visual Studio 2026 ships the new v145 platform toolset, not v143. Old .vcxproj files copied in from VS 2022 must be retargeted, otherwise the build fails with MSB8020 — build tools for v143 cannot be found. Copilot can perform this retargeting on request, but the requirement must be stated explicitly.

First launch & sign-in

Change into your project folder and start Copilot. The default invocation recommended for day-to-day FTE work is:

cd "$env:USERPROFILE\AppData\Local\Projects\Repro-12345" copilot --yolo --no-ask-user --model "claude-opus-4.8" --effort "medium"

The flags are defined as follows:

Flag	What it does
--yolo	Pre-approves tool execution, file writes and shell commands for the session. Equivalent to --allow-all-tools --allow-all-paths --allow-all-urls. Use only within trusted folders.
--no-ask-user	Suppresses the interactive confirmation prompts mid-task — the agent continues without interruption.
--model	Pins a specific model. Useful when determinism across a team is required or when comparing runs. To see, which model best fits your needs, take a look at the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison
--effort	low, medium, or high. Higher values allocate more reasoning tokens per turn — slower, but advantageous for complex build errors and architectural work.

Copilot first prompts you to confirm that you trust the current folder. Select "Yes, and remember this folder for future sessions" only for workspaces you control. Then run /login if you have not yet authenticated — this opens a browser tab in which you sign in with your FTE GitHub identity.

Sign in to Copilot on an unmanaged / non-FTE-domain machine

The Copilot CLI signs in with a GitHub identity, not directly with your Microsoft corporate account. On a company-managed device this is transparent — your Enterprise Managed User (EMU) account <alias>_microsoft is accepted without further action.

On a fresh VM, an Azure VM image, or any other unmanaged device, /login will refuse the EMU account unless you have explicitly linked a personal GitHub account to your EMU and granted it Copilot entitlement. The same pattern holds for engineers at other enterprises: they sign in with the GitHub identity their organization has provisioned with a Copilot seat. Individuals on a Copilot Pro or Pro+ plan can sign in directly with their personal GitHub handle, without any linking step.

For Microsoft FTEs, linking is performed once, from any browser, at:

https://aka.ms/copilot

Sign in with your Microsoft corporate account, link your personal GitHub handle (creating one first if necessary), and accept the prompts. When complete, the page should display every checkbox in green:

A correctly linked account ataka.ms/copilot. The first green check confirms Copilot on the EMU account; the bottom green check is the one that is relevant for unmanaged VMs — "GitHub Copilot enabled for your personal GitHub account for use everywhere", granted through your MicrosoftCopilot organization membership.

Once that bottom row is green, run copilot inside your VM, use /login, and select your personal GitHub handle when the browser device-code flow opens. From that point onward, every CLI session in that VM uses your linked personal identity, your Copilot entitlement follows you, and your activity remains attributable through the MicrosoftCopilot organization for audit purposes.

Tip The link between the EMU and the personal account is per-user, not per-device. Once it is established, every new VM you provision will work after a single /login — there is no need to revisit aka.ms/copilot again unless you change your personal handle.

The bootstrap prompt

This is arguably the most valuable step in the entire setup. Before asking Copilot to build anything, instruct it to profile your machine and write itself a memory file. Paste the following verbatim:

I have Visual Studio 2026 Community Edition installed with C#, .NET Framework 4.8.1 targeting pack, native C++ and C++/CLI. Locate the installation paths using vswhere, verify that you can create and compile a C# app, a native C++ app, and a C++/CLI app. Then create a global copilot-instructions.md under %USERPROFILE%\.copilot\ that documents the VS environment so future sessions don't have to rediscover it.

The behavior that follows is informative to observe. Copilot uses vswhere.exe to locate the installation, reads setup.config.json, generates three disposable projects in your temp folder, builds them with MSBuild, parses the output, and on success writes a structured Markdown file to your user profile. That file is then automatically picked up by every future Copilot CLI session on this machine. The discovery work is performed exactly once.

What a good copilot-instructions.md looks like

Copilot CLI reads instructions from several well-known locations, in this order of precedence:

.github/copilot-instructions.md in the repo

AGENTS.md (or CLAUDE.md, GEMINI.md) in the repo root

.github/instructions/**/*.instructions.md for path-scoped rules

%USERPROFILE%\.copilot\copilot-instructions.md as a global fallback

The machine-level file should be concise, declarative, and contain exact paths. A verified skeleton is shown below:

# Build environment on this PC (Visual Studio 2026) - Visual Studio Community 2026, version **18.6.2** - MSBuild **18.6.3** - MSVC toolset **14.51.36231**, platform toolset name **v145** - Windows 10/11 SDK: **10.0.26100** - Default .NET Framework target: **net481** ## Key paths | Purpose | Path | |--------------------|------| | VS install root | `C:\Program Files\Microsoft Visual Studio\18\Community` | | vswhere.exe | `C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe` | | MSBuild.exe | `...\18\Community\MSBuild\Current\Bin\MSBuild.exe` | | MSVC cl.exe (x64) | `...\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe` | | vcvars64.bat | `...\VC\Auxiliary\Build\vcvars64.bat` | ## Conventions - For SDK-style csproj, always run `Restore` together with `Build`. - New `.vcxproj` files must use `<PlatformToolset>v145</PlatformToolset>`. - For C++/CLI: `<CLRSupport>true</CLRSupport>` and `<TargetFrameworkVersion>v4.8.1</TargetFrameworkVersion>`. - Never put build output under `%TEMP%`.

Tip Treat copilot-instructions.md as a configuration file. Commit a repo-local version to your .github/ folder for projects with non-standard build flags (custom response files, signing scripts, and similar). The repo-local version overrides the global one.

Worked example: a C# console app on .NET Framework 4.8.1

Consider a task representative of customer-engineering work — a small utility that reads a registry key and emits JSON. Inside Copilot, enter:

Create a new C# console project targeting net481 in .\RegistryProbe\. The app should accept a registry key path as its single argument, read all values under it, and print them as JSON to stdout. Add a few unit tests with MSTest. Build the project with MSBuild in Release and show me the dotnet run output.

Behind the scenes Copilot will:

Use vswhere to locate MSBuild (already cached via the instructions file).

Generate RegistryProbe.csproj with <TargetFramework>net481</TargetFramework>.

Write Program.cs with appropriate argument parsing and a Microsoft.Win32.RegistryKey reader.
Add an MSTest project, wire it up via a .sln file.

Run MSBuild /t:Restore,Build /p:Configuration=Release and read the output.

Run the binary against a safe key like HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and present the JSON output.

For a more deliberate workflow, press Shift+Tab to toggle Plan mode. Copilot will produce an implementation plan first and wait for approval before writing to disk — a recommended practice for any work involving a customer reproduction.

Worked example: a native C++ command-line tool

The same approach applied to native C++. Prompt:

Create a new native C++ console project ".\PortPing\" targeting x64, Release, using the v145 platform toolset and Windows SDK 10.0.26100. The tool takes "host:port" on the command line and prints "open" or "closed" depending on whether a TCP connect succeeds within 1 second. Build it with MSBuild and run it against microsoft.com:443.

The agent generates a PortPing.vcxproj that looks roughly like:

<PropertyGroup Label="Globals"> <PlatformToolset>v145</PlatformToolset> <WindowsTargetPlatformVersion>10.0.26100.0</WindowsTargetPlatformVersion> <ConfigurationType>Application</ConfigurationType> </PropertyGroup>

…and builds it with:

& $msbuild "PortPing.vcxproj" /p:Configuration=Release /p:Platform=x64

Tip If you want Copilot to compile a single .cpp with cl.exe instead of going through MSBuild, instruct it to load vcvars64.bat first. This sets INCLUDE, LIB and PATH for the MSVC toolchain so that direct compiler invocations succeed.

Worked example: a C++/CLI interop assembly

C++/CLI is the workload that most commonly causes confusion in practice, because it requires the optional VC.CLI.Support component and a few non-obvious project properties. With Copilot, the task reduces to:

Create a C++/CLI class library ".\InteropBridge\" that targets .NET Framework 4.8.1, uses the v145 toolset, and exposes a managed wrapper around the native function CreateFileW. Add a small C# console app in the same solution that consumes the wrapper. Build everything Release|x64 and run the C# app to prove the interop works.

The two critical lines that Copilot adds to the .vcxproj are:

If the C++/CLI support component is not yet installed, Copilot will detect the corresponding "Cannot find <CLRSupport>" error, suggest the correct winget command to add the component, and offer to re-run the build.

Models, effort, and custom agents

Copilot CLI allows the model to be selected per session, and this selection should be made deliberately. The appropriate choice depends on the task at hand:

Profile	Recommended invocation	When to use
Fast iteration	copilot --yolo --model "claude-opus-4.8" --effort "medium"	Day-to-day work: scaffolding, small refactors, and build fixes.
Hard problems	copilot --yolo --model "claude-opus-4.7-1m-internal" --effort "high" --context "long_context"	Cross-file analysis, large reproductions, and complex C++ template errors.
Maximum autonomy	copilot --allow-all-urls --allow-all-tools --allow-all-paths --no-ask-user	Sandboxed Dev Box or VM only — never on a production laptop.

To determine which model best suits your purpose, consult the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison. And if you have ever wondered what skills, tools, plugins and similar concepts actually are — or what an MCP server is for — the answers are available at https://docs.github.com/en/copilot/concepts/agents/copilot-cli/comparing-cli-features.

Useful slash commands within Copilot CLI

/plan — produce an implementation plan before any code is written.
/review — run the code-review subagent against the local diff.
/diff — display the changes Copilot has made to the working tree.
/agent — select a custom agent (explore, task, general-purpose, rubber-duck, code-review, research).
/mcp — register an MCP server (useful for Azure CLI, Kusto, or internal tooling).
/instructions — show which instruction files are currently loaded — useful when investigating unexpected agent behavior.

Tip Press Shift+Tab at any time to toggle Plan mode. For any action that would be recorded in a change ticket, planning first is inexpensive insurance.

Security & compliance for Microsoft FTEs

GitHub Copilot CLI falls within the scope of Microsoft's standard "responsible use of AI" guidance. Engineers at other enterprises should substitute the equivalent policy of their own employer, and individuals using a personal Copilot subscription should still treat these principles as a sensible default. The condensed guidance for engineers is:

Do not paste customer data into prompts unless your engagement explicitly permits it. The agent will faithfully transmit such data to the model.
Do not use --yolo on shared infrastructure. The flag pre-approves shell execution and file writes. Reserve it for personal workspaces or sandboxed Dev Boxes.
Review the diff. Use /diff or git status before committing — Copilot will, on occasion, refactor files you did not anticipate.
Secrets stay out of source. If you ask Copilot to test something that requires credentials, direct it to use azd, the Az module, or your Key Vault — never inline secrets.
Telemetry and logs from the CLI reside under %USERPROFILE%\.copilot\logs. If a customer escalation requires evidence of agent actions, those logs serve as your audit trail.

Important Any action Copilot performs on your machine still runs as you. Treat agent sessions with the same care you would extend to a teammate with full access to your development machine.

Beyond Visual Studio: where else Copilot CLI helps

The Visual Studio scenarios in this article are the most obvious use case, but they are by no means the only one. The following list covers additional areas in which Copilot CLI has proven productive on real engagements.

Generating and maintaining tests — Ask Copilot to write MSTest, NUnit or xUnit tests for an existing class, including mocks and boundary cases, or to fill coverage gaps in methods that were touched in the last commit.
Refactoring across files — Rename a public API, extract an interface, or restructure a folder hierarchy and have Copilot propagate the change consistently throughout the solution, including project file references and unit tests.
Modernizing legacy code — Port code from .NET Framework 4.8.1 to .NET 8/9, replace WebClient with HttpClient, or swap manual JSON parsing for System.Text.Json. Copilot handles the boilerplate; you review the deltas.
Building customer reproductions from scratch — Translate a bug description from a support ticket into a minimal repro project. Copilot scaffolds the solution, simulates the failing call path, and runs it to confirm the symptom matches.
Reviewing the local diff — The /review slash command analyses staged or unstaged changes and surfaces real issues — race conditions, off-by-one errors, missing input validation, dropped exceptions — while suppressing style-only noise.
Writing and optimizing database code — Generate Entity Framework Core models and migrations from an existing schema, draft complex LINQ or raw SQL queries, and ask Copilot to inspect an execution plan and propose targeted indexes or query rewrites.
Interpreting performance and memory profiles — Hand Copilot a PerfView trace summary, a dotnet-counters capture, or a BenchmarkDotNet result table. It identifies hot paths, allocation spikes, and contended locks, then suggests concrete code changes to address them.
Generating documentation — Produce XML doc comments for public APIs, README sections, architecture overviews, or migration guides — written directly from the current code, not from a stale design document.
Investigating unfamiliar codebases — Drop into a foreign repository and ask "what does this service do?", "where is authentication enforced?", or "which class handles cache invalidation?". The explore subagent answers with file and line references rather than vague summaries.
Analyzing logs and traces — Point Copilot at an ETW trace, an Event Viewer export, a Fiddler capture, or a multi-megabyte server log. It groups errors, identifies the dominant failure pattern, and suggests next steps for the investigation.
PowerShell, Bicep and other operational scripting — Beyond compiled applications, Copilot writes and debugs PowerShell modules, Bicep/ARM templates, Terraform configurations, and shell scripts — useful, among other things, for provisioning the very Dev Box or Azure VM described earlier in this article.
Drafting technical communication — Generate the first draft of a customer-facing root-cause analysis, a pull request description, a release-note entry, or an internal incident retrospective directly from a diff or a chat transcript. The final wording remains yours; the boilerplate does not.

On a slightly meta note: GitHub Copilot CLI can also take a surprising amount of work off your hands when, for instance, you set out to write a blog post like this one. :-)

A note on customer data. Several of the scenarios above — building customer reproductions and analyzing customer-supplied logs in particular, but also any review, database or profiling task that involves production samples — may rely on material provided by a customer. Such data must always be handled with care: depending on the engagement, the customer's data-classification level, or the applicable regulatory regime, sharing it with a Copilot model may be restricted or outright prohibited. Public Sector engagements warrant particular caution. When in doubt, redact, reproduce against synthetic data, or confirm with your account team or compliance contact before pasting anything into a prompt.

Wrapping up

A clean Windows installation, two winget commands, one bootstrap prompt, and a global copilot-instructions.md are all that separate you from a fully working, AI-driven C# / C++ / C++/CLI workflow on Visual Studio 2026. From that point, the agent does what agents do best — it handles the routine work while you remain focused on the customer problem. The list of additional scenarios in the previous section is intentionally non-exhaustive — most engineering tasks that can be described in plain English are candidates, provided the agent has the relevant context and the required permissions.

Productive prompting — and may your builds remain evergreen.

Authenticating AWS Workloads to Azure Functions using Workload Identity Federation

kasturi — Mon, 29 Jun 2026 04:38:32 GMT

What you will learn:

What Workload Identity Federation is and how it works
How to set up trust between AWS and Microsoft Entra ID
How to exchange AWS identity tokens for Azure access tokens
How to securely call an Azure Function from AWS without storing credentials

This approach improves security, removes secret management overhead, and aligns with Zero Trust principles.

Let’s start by understanding why this approach is needed in a multi-cloud environment.

Why this approach is needed

In today’s multi-cloud landscape, organizations frequently need to connect services across cloud providers like AWS and Azure.

Traditionally, this required storing long-lived Azure client secrets within AWS environments. While functional, this introduces:

Security risks (secrets can leak or be misused)

Operational overhead (secret rotation and storage)

Increased maintenance complexity

Microsoft Entra ID provides a modern alternative: Workload Identity Federation, which eliminates the need for static credentials entirely.

What is Workload Identity Federation?

Workload Identity Federation is a feature in Microsoft Entra ID that allows you to trust identities from external providers like AWS, GCP, or GitHub. Instead of a secret, Azure validates the identity of the AWS resource based on its own native OIDC (OpenID Connect) token.

This approach is particularly useful for:

Securing Cross-Cloud Pipelines: Enabling AWS Lambda or EC2 to call Azure APIs without managing keys.

Eliminating Secret Rotation: Removing the need to update expired secrets across different cloud providers.

Enhancing Security: Using short-lived, verifiable claims that automatically expire.

In this blog, we will cover the configuration for service-to-service authentication and user-led validation for troubleshooting. The following guide outlines the complete technical configuration required to implement this architecture.

An overview of what we will be doing:

Generate AWS Token: Your AWS resource (Lambda, EC2, etc) generates a short-lived OIDC token signed by AWS.
Exchange for Azure Token: The AWS token is sent to Microsoft Entra ID. Azure validates the AWS signature using your Federated Credential and issues a native Azure Access Token in return.
Attach Verified Permissions: We configure an App Role on the Function App and link it to our Caller App. This helps Azure identify the correct permissions to inject into the token, confirming the caller is officially permitted to access your API.
Authorize Azure Function: The AWS resource calls the Function URL with the Azure token. The Function's authentication layer verifies the token's claims and grants access.

Section 1: AWS side setup

Step 1–Enabling Outbound Identity Federation

Go toIdentity and Access Management (IAM)-> Access Management->Account Settings
Scroll down to the Outbound Identity Federation section and enable it. Note down the Token Issuer URL—we will use it later to set up the Issuer claim in the federated credentials on the Azure side.

Step 2– Create a role for your AWS resource (Lambda, EC2)

Go to Identity and Access Management (IAM) -> Access Management->Roles
Click on the Create role button on the top right and select the trusted entity type, I selected AWS service. For use case I selected EC2.
Under Permissions, click Add permissions > Create inline policy.
Switch to the JSON tab and paste this:
curl -X POST "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=<CLIENT_ID> " \ -d "scope=api://<APP_URI> /.default" \ -d "grant_type=client_credentials" \ -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \ -d "client_assertion=<WebIdentityToken> "
Review and Save (name it something like AllowSelfWebIdentityToken). This permission allows the role to generate its own OIDC token for external exchange (you can do this step after the creation of role as well by editing the role)
I named the role aws-federation-role. Review and create the role. After the creation is complete note down the ARN for the role.

Section 2: Azure side setup

Step 3 — Register the AWS Caller App in Entra ID

This registration represents the AWS resource that will request a token and call your API in the Azure side.

Go to Azure Portal → Microsoft Entra ID → App registrations → + New registration. Fill in the following details:
- Name: aws-caller-app
- Supported account types: Single tenant (your tenant)
Click Register. Now you’ll see Application (client) ID and Directory (tenant) ID. Copy both — you’ll need them later.

Step 4— Create Federated Credentials

This allows AWS to impersonate this application by establishing a trust with an external OpenID Connect (OIDC) identity provider and get tokens to access Microsoft Entra ID resources.

In the aws-caller-app that you just created, go to Manage->Certificates and Secrets. Go to the Federated credentials section on the page.
Fill the following details:
- Federated credential scenario: Other issuer
- Issuer: Add the Token Issuer URL that we copied in Step 1 from AWS.
- Type: Explicit subject identifier
- Value: Add the ARN of the AWS resource that we copied in Step 2
- Name: aws-federation
Add Description and leave the Audience claim as is. Click Add.

Step 5— Register your Function App in Entra ID

This registration represents the Function App resource that will receive a token and be called on the Azure side. My Function App is an API called aws-entra-federation-api.

Go to Azure Portal → Microsoft Entra ID → App registrations → + New registration. Fill in the following details:
- Name: function-api-app
- Supported account types: Single tenant (your tenant)
Click Register. Now you’ll see Application (client) ID and Directory (tenant) ID. Copy both — you’ll need them later.

Step 6– Create an App Role in function-api-app

App roles are custom role templates which define permissions that can be assigned to users or apps.

In the function-api-app that you just created, go to Manage → App Roles in the left menu.
Create a new Role and fill the following details:
- Display Name: access_as_app
- Allow Member Types: Applications
- Value: access_as_app
- Description: Allow application to application access
- Do you want to enable this app role?: True (Checked)
Click "Apply".

Step 7– Assign API Permissions to the aws-caller-app

In the previous step we created a role on the function-api-app, now we will assign this role to the aws-caller-app so that it is able to authorize and call the function-api-app.

In the function-api-app, go to Manage → API Permissions in the left menu.
Click "+ Add a permission". Click on the "APIs my organization uses" tab.
In the search bar, enter the name of the app/service principal created before function-api-app.
Select Application permissions and, under the Permissions section, choose the role created before (access_as_app).
Click the "Add permissions" button.
Back in the Manage → API Permissions screen, click "Grant admin consent for Default Directory".

Step 8— Configure Authentication on the Azure Function resource (aws-entra-federation-api)

Enable authentication on your function resource (aws-entra-federation-api) and link it to the app registration (function-api-app) you created earlier.

Go to your Function App resource in the Azure Portal
(aws-azure-federation-api)
On the left menu, select Authentication.
Click + Add identity provider. Add the following details:
- Identity provider: Microsoft
- App registration type: Provide details of an existing app registration
- Client ID: Paste the Application (client) ID of your function-api-app from step 5(APP_URI)
- Issuer URL: https://login.microsoftonline.com/<tenant-id>/v2.0 (Replace <tenant-id> with your Directory (tenant) ID)
- Client application requirement: Allow requests from any application
- Identity requirement: Allow requests from any identity
- Tenant requirement: Allow requests only from the issuer tenant
- Under Restrict access, select Require authentication
- Unauthenticated requests: HTTP 401
Any other field not listed should remain as default. Click "Add" and refresh the Settings → Authentication view.
The new configured provider will appear. Click "Edit". A list of fields will appear. Make the following changes:
Allowed token audiences: Lets consider Application ID for function-api-app from step 5 as the value for variable APP_URI. Add the following three different audiences.
- <APP_URI>
- api://<APP_URI>
- api://<APP_URI> /.default
Any other field not listed should remain as default. Save the changes. Now the Function App will only accept calls with valid Azure AD access tokens.

Congratulations, you have successfully completed the setup required for using Federated Identity authentication. Now let’s test if the setup is working correctly.

Section 3: Validating the setup

Step 9 – Requesting Azure token and authenticating to the function app.

In my case, I’ve logged in to my AWS account using my user account (not root user) and then opened AWS CloudShell. I will be validating the setup through user account as I have not deployed any AWS resource. You should be able to request for Azure token through Lambda or other AWS resource in a similar manner.

We will be using the following variable and values in the following steps:

ARN: The ARN of the role created in step 2 on AWS.

TENANT_ID: Your Azure tenant ID, you can find this by going to your Account->All directories and copy the Directory ID

CLIENT_ID: The application (object) ID of the app registration created for the AWS caller app generated in step 3(aws-caller-app, in this case).

APP_URI: The application (object) ID of the App registration created for the function app resource generated in step 5 (function-api-app, in this case).

DEFAULT_DOMAIN: You can find this in the overview section of your Azure Function app resource (aws-entra-federation-api, in this case).

We need to follow a few extra steps because this validation uses a user account. In production, the AWS SDK performs the ‘identity proofing’ step (step 4) for you. In your code, you simply take that identity, exchange it for an Azure token at the Microsoft Entra endpoint, and use the token to call your Azure Function. As a result, a production workload typically doesn’t need the first four steps.

Assume the Role that was created earlier for the AWS resource in Step 2, we are logged in to the AWS CloudShell with the user account but we need to use the role that we created earlier to generate AWS token and exchange it for Azure token. aws sts assume-role --role-arn <ARN>
As output, we get accesskeyid, secretaccesskey and sessiontoken. We will be using these as variables in the next step.
Set these values as variables:
export AWS_ACCESS_KEY_ID="<accesskeyid> " export AWS_SECRET_ACCESS_KEY="<secretaccesskey> " export AWS_SESSION_TOKEN="<sessiontoken>"
Generate the AWS OIDC Token that is specifically formatted for Azure.
aws sts get-web-identity-token \ --audience "api://AzureADTokenExchange" \ --signing-algorithm "RS256" \ --duration-seconds 3600
We get the WebIdentityToken in the output. Store it as we will be using it in the next step.
Now we will exchange the AWS token (WebIdentityToken) for an Entra ID token
curl -X POST "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=<CLIENT_ID> " \ -d "scope=api://<APP_URI> /.default" \ -d "grant_type=client_credentials" \ -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \ -d "client_assertion=<WebIdentityToken> "
We get the access_token as the output of the last step. Store it as we will be using it in the next step.
Use the Entra ID token from the last step to send a request to your app—in this case, the function-api-app.
curl -X GET "https://<DEFAULT_DOMAIN> " \ -H "Authorization: Bearer <access_token>" \ -H "Content-Type: application/json"
You should get a 200 OK response.

Conclusion

By implementing Workload Identity Federation, you have moved away from the "Secret Management" era of cloud security. Instead of worrying about rotating client secrets or securing them in a vault, you are now using a short-lived, verifiable trust relationship between AWS and Azure.

What's Next?

Now that your authentication is secure, you can explore:

Fine-Grained Authorization: Use the claims inside the Azure Access Token to restrict specific actions within your Azure Function code.
Conditional Access Policies: Layer on Azure Conditional Access to ensure requests only come from trusted locations, such as your specific AWS VPC or a designated IP range.
Automating with Terraform/Bicep: Now that you've done it manually, consider codifying this setup to ensure consistent security across all your environments.

Check This Out! (CTO!) Guide (May/June 2026)

TysonPaul — Thu, 18 Jun 2026 21:36:23 GMT

Member: TysonPaul | Microsoft Community Hub

Triggering Azure Functions from Blob Storage Using Event Grid

Team Blog: Core Infrastructure and Security

Author: AndrewCoughlin

Published: 05/11/2026

Summary: The article explains how to trigger Azure Functions from Blob Storage events using Azure Event Grid for real-time file processing. It outlines a step-by-step approach: create and deploy an Azure Function with an Event Grid trigger, set up an Event Grid subscription for BlobCreated events, and validate the process by uploading a blob. The method minimizes latency and avoids polling, making it suitable for enterprise scenarios. Key pitfalls include creating subscriptions before the function exists and misconfigurations. The article provides sample code and emphasizes the solution's simplicity, reliability, and operational transparency.

TLS Certificate Pinning and Best Practices in Azure Open-Source Relational Databases

Team Blog: Core Infrastructure and Security

Author: TameikaL

Published: 05/13/2026

Summary: The article explains TLS certificate pinning and its implications for Azure open-source relational databases (PostgreSQL, MySQL). Certificate pinning enhances client-side security but increases operational risk, especially during certificate rotations, by causing connection failures if certificates change. Unlike Azure SQL, where certificate validation is platform-managed, Azure OSS databases use client-managed trust. The article advises against certificate pinning and recommends trusting documented root CAs, using standard TLS validation modes, and maintaining up-to-date trust stores to ensure secure and resilient client connections during certificate updates.

Azure DDoS Protection & Azure WAF: A Layered Defense for Modern DDoS Attacks

Team Blog: Azure Network Security

Author: saikishor

Published: 05/28/2026

Summary: The article explains how Microsoft Azure provides a layered defense against modern DDoS attacks by combining platform-level infrastructure protection, Azure DDoS Protection for network-level threats (Layers 3/4), and Azure Web Application Firewall (WAF) for application-layer (Layer 7) attacks. This multi-tiered approach ensures comprehensive mitigation by addressing both high-volume network floods and sophisticated application-level threats, using adaptive techniques, rate limiting, bot protection, and real-time analytics. The article emphasizes that a defense-in-depth strategy—leveraging both Azure DDoS Protection and WAF—is essential for safeguarding internet-facing applications and maintaining service availability.

Scaling GitHub Advanced Security in Azure DevOps with a single reusable YAML template

Team Blog: Azure Infrastructure

Author: Paulams732

Published: 05/11/2026

Summary: The article describes how to streamline GitHub Advanced Security (GHAS) integration in Azure DevOps by using a single, reusable YAML pipeline template. This approach dynamically detects repository content, runs only relevant security scans for application code and infrastructure-as-code, and centralizes configuration and reporting. It eliminates the need for multiple pipelines, reduces maintenance, ensures consistent security coverage, and supports polyglot and mixed repositories, resulting in a scalable and efficient DevSecOps process. Key lessons include the importance of detection-driven execution, dynamic configuration, and unified workflows for effective security management across diverse codebases.

Building AI Guardian Extension: AI Detection and Enterprise AI Security

Team Blog: Azure Infrastructure

Author: ranjsharma

Published: 05/19/2026

Summary: The article discusses the security and governance challenges posed by rapid enterprise adoption of generative AI tools, focusing on the risks of "Shadow AI"—the unauthorized use of AI platforms that can lead to data leakage and compliance violations. It introduces the AI Guardian Extension, a platform that autonomously detects and protects against Shadow AI by monitoring AI interactions, preventing sensitive data exposure, blocking risky prompts, and generating compliance reports, thereby enabling safe, compliant, and visible enterprise AI usage.

Public Preview: Migrate your regional virtual machines to availability zones

Team Blog: Azure Compute

Author: micahmckittrick

Published: 05/07/2026

Summary: Microsoft has announced a public preview feature enabling Azure users to migrate regional (nonzonal) Virtual Machines (VMs) and VM Scale Sets (VMSS Flex) into specific availability zones without rebuilding resources. The migration preserves VM names, disks, IPs, and other properties. This improves fault isolation, compliance, and disaster recovery. The process involves deallocating the VM, assigning it to a zone, and restarting it. Migration is one-way and must be done per VM. Certain configurations, like Basic SKU IPs and unmanaged disks, are not supported. Users are advised to roll out migrations in batches for production workloads.

Use Azure Container Registry as an Upstream Source for Artifact Cache

Team Blog: Azure Compute

Author: toddysm

Published: 05/05/2026

Summary: Azure Container Registry (ACR) now supports using another ACR as an upstream source for artifact cache, enabling secure image promotion and distribution within organizations. This feature allows registries to cache images from other ACRs, with user-assigned managed identities (UAMI) supported for authentication, improving security by eliminating credential management. Common scenarios include promoting images between Dev and Prod registries and implementing hub-and-spoke registry topologies. The setup uses Azure CLI, requires proper RBAC permissions, and works best within the same tenant. Cross-tenant and some network configurations have limited support; portal integration is coming soon.

How to use Instance Mix with Azure Virtual Machine Scale Sets

Team Blog: ITOps Talk

Author: OrinThomas

Published: 05/24/2026

Summary: Instance Mix for Azure Virtual Machine Scale Sets allows you to specify up to five compatible VM sizes in a single scale set (Flexible orchestration mode), enhancing scalability, cost optimization, and provisioning success. Azure selects VM sizes during scale-out based on your chosen allocation strategy (LowestPrice, CapacityOptimized, or Prioritized). Best for stateless, horizontally scalable workloads, Instance Mix requires similar VM types, compatible architectures, and pre-checked quotas. It’s configured via Azure CLI or portal, with operational tips for optimal use. Avoid mixing very different VM types, and always verify availability and quotas before production deployment.

The End is Nigh for DES and an Update for hunting down RC4

Team Blog: Ask the Directory Services Team

Author: Chris_Cartwright

Published: 05/08/2026

Summary: Microsoft is finalizing the removal of DES and RC4 encryption types from Windows Kerberos authentication to enhance security. The article provides updated XML filters and event forwarding methods to help administrators identify and track the use of DES and RC4 in their environments. It also includes resources, scripts, and guidance for transitioning to stronger cryptography, with references to related Microsoft support articles and previous blog posts. Note: The described Event Forwarding methods are not yet compatible with Server 2025 but will be updated in the future.

Windows 365 for Agents: run AI agents in Cloud PCs across real applications

Team Blog: FastTrack

Author: JulieHersum

Published: 05/27/2026

Summary: Windows 365 for Agents, now in public preview, enables AI agents to autonomously execute real workflows across applications—including legacy and UI-based systems—within secure, policy-controlled Cloud PCs. This represents a shift from API-based automation, allowing agents to complete complex tasks like processing invoices or updating CRM data while maintaining enterprise security and control. Administrators can define boundaries and monitor agent activity, ensuring agents operate safely without impacting production systems. Windows 365 for Agents thus offers a secure, dedicated environment for scalable, autonomous AI workflow automation across diverse software environments.

From Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance

Team Blog: Azure Storage

Author: GeertVanTeylingen

Published: 05/22/2026

Summary: The article highlights Azure NetApp Files’ new “large volume breakthrough mode,” which sets a benchmark for cloud storage in Electronic Design Automation (EDA) workloads. Independently validated SPECstorage® 2020 benchmarks show this mode enables exceptional scalability and consistent sub-millisecond latency, supporting thousands of parallel EDA jobs without performance bottlenecks. Both single and scaled configurations demonstrated linear scaling in throughput and concurrency, empowering faster, more efficient chip design cycles. As a result, Azure NetApp Files transforms cloud storage from a limiting factor to a strategic enabler for modern, high-performance semiconductor design workflows.

Modernizing Azure Virtual Desktop with Nerdio and Azure Files

Team Blog: Azure Storage

Author: Vybava_Ramadoss

Published: 05/04/2026

Summary: The article discusses how organizations scaling Azure Virtual Desktop (AVD) face challenges with user profile storage, identity management, and cost efficiency. Nerdio Manager streamlines AVD deployment by integrating compute, storage, and identity management, reducing complexity and configuration drift. Azure Files Provisioned v2 enhances storage performance and cost efficiency, while Entra ID authentication simplifies identity architecture. Together, Nerdio and Azure Files enable faster, more reliable, and cost-effective AVD environments with improved user experience, especially during peak loads, and ensure consistent, audit-ready governance at enterprise scale.

Cutover Strategy for Azure PaaS Services: A Step-by-Step Guide to Near Zero-Downtime Migrations

Team Blog: Azure Migration and Modernization

Author: lapadman

Published: 05/06/2026

Summary: The article outlines a step-by-step cutover strategy for migrating enterprise applications to Azure PaaS with near zero downtime. Emphasizing phased parallel cutover, it recommends gradual traffic shifts, robust rollback plans, and continuous monitoring to minimize risk. High availability (HA) and disaster recovery (DR) must be integrated into each phase. Messaging systems, particularly Azure Service Bus, are highlighted as the most complex component. The guide details essential roles, tools, metrics, and checklists to ensure a safe, controlled migration, concluding that cutover and HA/DR should be treated as a unified process for successful Azure transitions.

[Preview] CIS Benchmarks on Azure; Now for Windows Server

Team Blog: Azure Governance and Management

Author: AmirB

Published: 05/28/2026

Summary: Microsoft is announcing the preview of built-in CIS Benchmarks for Windows Server within Azure Policy and Machine Configuration, initially supporting Windows Server 2025. This expands their compliance offerings, which already cover Linux, to Windows environments managed by Azure and Arc. The solution allows flexible configuration, exportable compliance as code, and unified management across machine types. The preview starts in audit-only mode, with auto-remediation and enforcement planned. Future updates will add support for more Windows editions, granular rule enforcement, STIG baselines, and retire older, overlapping policies for streamlined compliance management in Azure.

Introducing the Azure Resource Manager MCP Server!

Team Blog: Azure Governance and Management

Author: stevenbucher

Published: 05/07/2026

Summary: The article announces the public preview of the Azure Resource Manager MCP Server, a tool enabling AI agents to interact with Azure infrastructure via Azure Resource Manager. It allows agents to generate, validate, and execute Azure Resource Graph queries, deploy and manage ARM templates, and monitor deployments—all from natural language prompts. The server supports compliance audits, rapid provisioning, and policy checks, and integrates with GitHub Copilot. It respects Azure security policies and is initially available for VS Code, with more features and client support planned. Users can install and provide feedback during the preview phase.

The power behind AI: Your brain

Team Blog: Microsoft Learn

Author: Nency_Yera

Published: 05/11/2026

Summary: The article shares Nency Yera’s journey as a neurodivergent professional with ADHD who, despite having no coding background, leveraged AI tools like GitHub Copilot and VS Code by customizing them to fit her thinking style. With supportive leadership and a personalized, step-by-step approach, she built practical solutions for her workplace. The story emphasizes that neurodivergent brains are assets, and that AI becomes powerful when adapted to individual needs, enabling anyone—regardless of technical background—to create impactful tools and unlock new potential.

New Microsoft Certified: Intelligent Applications Builder Associate Certification

Team Blog: Microsoft Learn

Author: LibertyMunson

Published: 05/27/2026

Summary: Microsoft has introduced the Certified: Intelligent Applications Builder Associate Certification, aimed at professionals building AI-powered business solutions using Microsoft Power Platform, Copilot, and natural language tools. To earn the certification, candidates must pass Exam AB-410 (beta), which validates skills in creating intelligent applications, automation, data models, and integrating AI agents. The first 300 test-takers before June 17, 2026, receive an 80% discount. Candidates should have experience with Dataverse, Power Apps, Power Automate, and Copilot features. The certification becomes generally available in July 2026, with preparation resources and study guides provided by Microsoft.

Ansible + Azure Arc: Use Ansible modules to deploy and manage Azure Arc machine extensions at scale

Team Blog: Azure Arc

Author: alinetran

Published: 05/20/2026

Summary: Microsoft has introduced new Ansible modules in the azure.azcollection for managing Azure Arc machine extensions at scale. These modules allow teams to automate the deployment, update, and removal of Azure Arc extensions through Ansible playbooks, streamlining extension lifecycle management across hybrid and multicloud environments. This integration eliminates the need for separate tools, enforces consistent configurations, supports compliance scenarios like centralized SSH access, and enhances visibility into extension states. The update strengthens Azure Arc’s position as a unified management platform for Windows and Linux servers using familiar automation workflows.

Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025

Team Blog: Azure Arc

Author: sharmajyoti

Published: 05/19/2026

Summary: Windows Server 2025 introduces hotpatching enabled by Azure Arc, allowing security updates without reboots across hybrid and multicloud environments at no extra cost. Eligible servers must be connected to Azure Arc and have Virtualization-based Security enabled. Azure Update Manager and other tools enable centralized patch management, improving uptime and simplifying compliance. Hotpatching delivers monthly security updates, with quarterly cumulative updates requiring a restart. Existing enrolled machines continue receiving hotpatches without additional action, and hotpatching remains free for Azure-hosted servers. Azure Arc also provides unified governance, monitoring, and lifecycle management for diverse server environments.

What's new in FinOps toolkit 14 – April 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 05/13/2026

Summary: FinOps toolkit 14 introduces AI integration via a Copilot Studio agent template, enabling users to query FinOps hub data in natural language. It adds support for ingesting Azure Advisor and custom optimization recommendations, simplifies hub deployment options, and previews a new dataset for commitment discount eligibility. The release also delivers various fixes and enhancements across guides, Power BI, workbooks, and the PowerShell module. Looking ahead, the toolkit will deepen AI features, expand data support, and offer premium services to further help organizations optimize and manage cloud costs in Microsoft Azure environments.

Azure CLI on macOS: Upcoming Installation Changes

Team Blog: Azure Tools

Author: Alex-wdy

Published: 05/11/2026

Summary: Microsoft is updating how Azure CLI is installed on macOS to better meet security and enterprise requirements. Starting with version 2.86.0 (Preview), Azure CLI will shift from Homebrew Core to new options: Homebrew Cask (recommended) and an offline tarball for air-gapped environments. These changes enable distribution of precompiled, signed, and notarized binaries, aligning with macOS security standards. Homebrew Core remains available during the transition, but users are encouraged to adopt the new methods and provide feedback. Full rollout details and installation instructions are available on Microsoft Learn.

From Prompt to Production: Open in VS Code for Terraform in Azure Copilot

Team Blog: Azure Tools

Author: Jingwei_Wang

Published: 05/12/2026

Summary: Microsoft has introduced "Open in VS Code" for Terraform in Azure Copilot, enabling users to move seamlessly from AI-generated Terraform code in Azure Portal to real deployments within an integrated, guided workflow. This feature supports immediate editing, validation, and deployment in a browser-based VS Code environment, with built-in guidance for backend configuration and deployment. Users can select from Azure Storage, Terraform Cloud, or a temporary workspace for state management. The solution streamlines Infrastructure as Code processes for both beginners and enterprises, now in public preview, with future plans for enhanced CI/CD and editor integrations.

Understanding and building an Azure Hybrid Meshed Hub-Spoke Topology

Team Blog: Azure Networking

Author: Svenbaeck

Published: 05/18/2026

Summary: The article explains how to design a secure, scalable Azure hybrid network using a meshed hub-spoke topology. Centralized hubs control all traffic and security, preventing uncontrolled lateral communication between spokes and supporting hybrid connectivity. Key design principles include controlled routing in gateways and spokes, proper VNet peering, and meshing hubs for multi-region setups. Azure Firewalls or NVAs in the hub enable traffic inspection and policy enforcement. The approach simplifies management, enhances security, and supports regional independence and fault isolation, making it suitable for enterprise-scale Azure environments. Clear address planning and consistent configuration are emphasized for effective operation.

Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager

Team Blog: Azure Networking

Author: Jay-Li

Published: 05/26/2026

Summary: Azure Virtual Network Manager (AVNM) integrates with Azure Virtual WAN to simplify and automate spoke connectivity, routing, and security policy management across large-scale hub-and-spoke network architectures. By grouping virtual networks and applying centralized connectivity and routing policies, AVNM reduces repetitive manual configuration, ensures operational consistency, and enables bulk onboarding, dynamic updates, and incremental deployments. This integration streamlines operations, enhances scalability, and provides robust security controls, making it easier for organizations to manage complex Azure networking environments confidently and efficiently.

Building resilient networks for AI supercomputers

Team Blog: Azure High Performance Computing (HPC)

Author: jithinjose

Published: 05/06/2026

Summary: The article details Microsoft’s networking innovations for the Fairwater AI supercomputer, focusing on resilience and efficiency at extreme GPU scale. Central to this is the Multipath Reliable Connection (MRC), a new, open-source transport protocol that distributes data across multiple paths, enabling robust, high-utilization GPU clusters even during routine network faults. Combined with a two-tier multiplane topology and static SRv6 routing, this approach minimizes disruptions, improves training throughput, and simplifies failure recovery. Microsoft, in partnership with industry leaders, is open-sourcing MRC and related tools to advance resilient AI infrastructure across the ecosystem.

Distributing model weights to your AI cluster: a faster pre-flight on AKS and Slurm

Team Blog: Azure High Performance Computing (HPC)

Author: pauledwards

Published: 05/06/2026

Summary: The article introduces "azcp-cluster", a tool for efficiently distributing large AI model checkpoints across multi-node GPU clusters on Azure. Instead of each node downloading the full dataset separately—causing slowdowns, increased costs, and potential Azure storage throttling—azcp-cluster shards the download across nodes, then broadcasts data at high-speed over InfiniBand. This approach reduces egress costs, maximizes fabric speed, and simplifies cluster setup on Slurm and AKS. Practical deployment examples, Docker integration, and Kubernetes scheduling strategies are provided, with recommendations for both merged-image and init-container patterns. Benchmarks show significant speedups and cost savings.

Share the Moment: Listen Together with Shared Audio

Team Blog: Windows OS Platform

Author: Steven Ilami

Published: 05/26/2026

Summary: The article introduces “Shared Audio,” a new Windows 11 feature that enables two users to wirelessly listen to audio from the same PC using separate Bluetooth LE Audio accessories, like headphones or hearing aids. This solves the longstanding limitation of one-audio-device connections, enhancing shared experiences during flights, study sessions, or road trips. Users can easily manage connections and individual volumes through Quick Settings. Shared Audio requires compatible LE Audio devices, Windows 11 (version 24H2 or newer), and suitable hardware. The feature aims to make group listening more accessible, convenient, and customizable for entertainment, productivity, and accessibility needs.

How to Secure Azure Databricks without Public Exposure using WAF + Private Endpoints

Team Blog: Azure Architecture

Author: FaizaanMerchant

Published: 05/11/2026

Summary: The article outlines how to secure Azure Databricks using a Zero Trust Architecture by combining Azure Application Gateway with Web Application Firewall (WAF) and Private Endpoints. This approach eliminates public internet exposure, ensures all traffic is inspected and routed securely, and aligns with strict compliance requirements. The recommended architecture uses a Hub-and-Spoke model, disabling public access and enforcing internal and external access through WAF and private endpoints, respectively. Key considerations include proper DNS configuration, SSL setup, and custom WAF rules, ensuring secure, compliant, and seamless access for both internal and external users.

Cloud Native Platforms: Evolve

Team Blog: Azure Architecture

Author: KishoreKumarPattabiraman

Published: 05/21/2026

Summary: The article argues that AI is transforming software engineering by augmenting workflows across the entire software development lifecycle—not just code generation. Success depends on disciplined adoption: turning individual AI prompts into reusable workflows, implementing robust guardrails, and maintaining clear boundaries for human judgment. Responsible AI, with practices ensuring fairness, transparency, safety, and accountability, is essential. Teams should measure AI by outcomes (like defect rates and lead time), not usage. The key is evolving engineering practices to leverage AI safely and effectively, making workflows, not individual suggestions, the core unit of value.

New Platform SSO with registration during Automated Device Enrollment on macOS

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 05/14/2026

Summary: Microsoft Intune now supports Platform Single Sign-On (PSSO) registration during Automated Device Enrollment (ADE) setup for macOS 26 and newer. With the new “Enable Registration During Setup” setting and Intune Company Portal version 5.2604.0+, users register their devices and sign in with Microsoft Entra credentials during Setup Assistant, enabling immediate access to work resources. This streamlines onboarding, reduces compliance gaps, authentication issues, and IT helpdesk tickets. The feature requires coordinated policies assigned to static user groups. Future updates aim to reduce multiple sign-in prompts for an even smoother enrollment experience.

Migrating frontline mobile devices: Aligning stakeholders before real-world testing

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 05/01/2026

Summary: The article outlines the crucial steps for migrating frontline mobile devices by emphasizing the need to align stakeholders and processes before conducting real-world testing with Microsoft Intune. It highlights translating discovery findings into actionable decisions, identifying and aligning key operational and technical stakeholders, and ensuring readiness across licensing, identity, and device lifecycle areas. Real-world testing should validate end-to-end workflows, security, and supportability in operational conditions, not just device enrollment. Standardization can evolve post-testing, and clear ownership of success criteria is essential to achieve meaningful pilot outcomes and support future device management decisions.

Microsoft Security Copilot: AI-Driven Security Operations at Greater Scale

edgarus71 — Thu, 18 Jun 2026 20:49:10 GMT

At its core, Security Copilot is built to enhance every facet of security operations at machine speed. It translates a vast array of inputs (Microsoft’s cloud-scale telemetry, threat intelligence feeds, security best practices, and enterprise-specific data) into tailored recommendations and summaries, helping security teams “catch what others miss,” respond faster, and strengthen their expertise. In the sections below, I explore the key security benefits of Security Copilot, its extensibility via third-party plugins and skills, and the value of its deep integration with Microsoft’s security ecosystem.

Key Benefits for Security Operations

Security Copilot meaningfully improves threat detection, investigation, response, correlation of signals, and analyst productivity. The table below summarizes these core security benefits and capabilities:

Security Operations Aspect	Benefit with Security Copilot
Threat Detection	Augmented detection of elusive threats: Security Copilot leverages broad threat intelligence and comprehensive signals to identify subtle threats, anomalies, and attack patterns that might be missed through manual analysis. By reasoning over Microsoft’s vast security graph and global threat telemetry, it helps analysts “catch what others miss,” ensuring unique or stealthy threats are surfaced.
Incident Investigation	Faster, context-rich investigations: Security Copilot can swiftly summarize and analyze incident data from multiple sources, enhancing incident details with additional context from logs, alerts, and threat intel. It correlates related events and highlights root causes, giving analysts a consolidated understanding of complex incidents in minutes. This enables quicker triage and deeper insights, so investigators know what happened and where to focus next.
Response & Remediation	Guided response and remediation: Security Copilot not only identifies issues but also provides prescriptive guidance on how to respond. It can suggest remediation steps and mitigation strategies in plain language, helping analysts act decisively. For example, it may outline containment steps or orchestrate automated actions through integrated tools, significantly reducing response time to incidents.
Signal Correlation	Holistic cross-domain correlation: Because it taps into signals across identities, endpoints, email, cloud workloads, and more, Security Copilot automatically connects the dots among disparate alerts and data streams. It presents unified incident narratives by linking related indicators (e.g., matching an endpoint malware alert with identity login anomalies and cloud logs), eliminating manual cross-tool correlation and uncovering hidden attack paths. Analysts get a single cohesive view of an incident across the kill chain.
Analyst Productivity	Boosted efficiency & skill elevation: By automating repetitive tasks (like scanning logs, writing KQL queries, or summarizing reports) and supporting natural language interaction, Security Copilot reduces manual workload and accelerates everyday tasks. This lets analysts focus on higher-value activities. In practice, teams using Security Copilot have seen significant productivity gains – a recent study found 23–47% improvement in SecOps task efficiency after adoption. Junior analysts ramp up faster (learning from Copilot’s guidance), while senior analysts can handle more incidents with less fatigue.

These improvements translate into measurable security outcomes. Incident response becomes faster and more consistent, with mean time to resolution reduced by 30% on average within a few months of use according to early research. Security Copilot’s ability to accelerate investigations and streamline tasks drives down risk exposure and helps organizations make the most of their security investments. Ultimately, it strengthens an organization’s security posture by augmenting human analysts with AI-driven speed, scale, and intelligence.

Seamless Integration with the Microsoft Security Ecosystem

Another key strength of Security Copilot is its deep native integration with Microsoft’s security portfolio. From day one, Security Copilot was “designed with integration in mind.” It plugs directly into a broad range of Microsoft security products — including Microsoft 365 Defender (XDR), Microsoft Sentinel (SIEM), Microsoft Entra (ID and access management), Microsoft Intune (endpoint management), Microsoft Purview (compliance), and more. In practice, Security Copilot is available as both a standalone portal and as an embedded side-by-side experience within these Microsoft security tools. This means a security analyst working in Microsoft Sentinel or Defender can access Copilot’s capabilities without switching context: Copilot is right there in the workflow, ready to answer questions or assist with tasks in real time.

Because of this close integration, Security Copilot can access data and signals from across all Microsoft security solutions that an organization uses. It operates over a unified security data estate encompassing endpoints, identities, emails, applications, cloud workloads, data repositories, and beyond. The result is truly end-to-end visibility and protection: Copilot can reason across diverse telemetry (e.g., correlating a device malware alert from Defender with cloud logs from Azure, or identity risk signals from Entra) to provide comprehensive insight. This unified approach eliminates silos and tool fragmentation — analysts spend less time pivoting between separate consoles or manually stitching together information because Copilot synthesizes it automatically.

Moreover, leveraging the Microsoft ecosystem means Security Copilot can immediately add value without requiring a rip-and-replace of existing tools. It acts as a “force multiplier” across the installed Microsoft Security stack, maximizing the return on those investments by making them more effective and easier to use. For example, Copilot can turn a collection of raw alerts from different Microsoft products into a single, coherent incident storyline with actionable next steps. This synergy leads to significant operational efficiency gains and a more streamlined SOC workflow, as analysts have a central AI assistant coordinating across all defenses on their behalf.

By providing unified insights, reducing tool sprawl, and bringing together Microsoft’s best-in-class security technologies, Security Copilot emerges as a valuable asset for modern security teams. It empowers organizations to practice “AI-first” security operations – enabling defenders to work faster and smarter, while fully utilizing an integrated security ecosystem to protect the enterprise from evolving threats. In summary, Microsoft Security Copilot offers a compelling combination of advanced AI capabilities, extensibility, and seamless integration that helps security teams achieve unprecedented speed, breadth, and efficiency in defending their organizations. It enhances human expertise with machine-scale intelligence, improving threat detection and response outcomes and transforming the way security operations centers operate for the better.

Open Extensibility with Third-Party Plugins and Skills

A standout capability of Security Copilot is its extensible plugin architecture, which allows it to incorporate external data sources and integrate with third-party security tools. Plugins in Security Copilot are modular connectors that bring in specific data or perform defined actions (each plugin encapsulates certain “skills,” such as running a KQL query, calling an API, or searching threat intel). Microsoft provides numerous pre-installed plugins out-of-the-box for common Microsoft security services and workflows, and administrators can easily add or develop custom plugins to connect 3rd-party systems or bespoke data sources. This design ensures that Security Copilot’s capabilities can expand and adapt to different environments.

Through both Microsoft-built and third-party plugins, Security Copilot can tap into a wide variety of security data beyond the Microsoft stack. For example, supported third-party plugins let Copilot pull context from external solutions such as IT service management tools (e.g., ServiceNow), vulnerability management platforms, identity providers, network security appliances, and others. Plugins feed additional logs, alerts, and intelligence into Copilot’s analysis, thereby enriching its understanding of incidents with non-Microsoft data and events. This means a SOC can leverage existing investments in third-party security products by having Security Copilot analyze and correlate those systems’ outputs alongside Microsoft’s telemetry.

Microsoft and its partners have already created an ecosystem of Security Copilot plugins. For instance, Microsoft announced 15+ new third-party plugins at Ignite 2024, spanning categories like threat intelligence (e.g., integrating feeds from providers like CrowdSec, Cybersixgill, GreyNoise) and device/network/identity management tools (e.g., Red Canary, Netskope, Tanium, CyberArk, etc.). These plugins bring rich external data on threat actors, indicators of compromise, vulnerabilities, device health, user activity, and more, allowing Copilot to provide even more comprehensive analyses and recommendations.

Crucially, customers can build their own plugins and skills if needed, using Security Copilot’s developer tools and APIs. This means an enterprise could integrate a proprietary threat feed, custom data store, or even trigger custom response workflows via Copilot, tailoring the AI assistant to their unique security environment. Thanks to secure design and admin controls, organizations maintain full governance over which plugins are enabled and how they consume resources. In summary, Security Copilot’s open, plugin-based extensibility ensures that it can grow with an organization’s needs, incorporating any relevant third-party data or workflow to further enhance threat analysis and incident response.

Technical Resources:

Security Copilot RBAC for Embedded Experience in Unified Security Platform

SantoshPargi — Wed, 17 Jun 2026 11:10:30 GMT

Introduction

The evolution of Security Operations Centers (SOC) is increasingly driven by AI-powered capabilities that improve efficiency, accuracy, and response time. Microsoft Security Copilot represents a significant advancement in this space by embedding AI-driven assistance directly within security platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra.

The concept of embedded experience is central to this transformation. Rather than operating as a standalone interface, Security Copilot is integrated within existing security tools, allowing analysts to invoke AI-generated insights directly during investigations. This reduces the need for tool switching and accelerates decision-making.

The purpose of this document is to define and explain the Role-Based Access Control (RBAC) model required to securely enable this embedded experience. It provides a structured understanding of how access is governed across multiple layers, how these layers interact, and how organizations can align permissions with SOC workflows while maintaining a least-privilege security posture.

Understanding Embedded Experience

Security Copilot in embedded mode operates within the context of the host platform. When invoked from Defender or Sentinel, it does not function independently but instead consumes data already accessible to the user. This model ensures that Copilot enhances visibility without expanding access boundaries.

This behavior is governed by an On-Behalf-Of (OBO) model, where Security Copilot leverages the permissions of the authenticated user. It does not introduce new entitlements or override existing RBAC configurations.

As a result, the insights generated by Copilot are always limited to what the user is already authorized to see, reinforcing Zero Trust principles and preventing unauthorized data exposure.

Prerequisites for Embedded Experience

To enable Security Copilot in an embedded environment, organizations must establish foundational prerequisites that ensure seamless and secure operation.

First, access to underlying platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra must already be provisioned. Since Copilot is not a standalone data source, it cannot function without these integrations.

Second, RBAC alignment across identity, platform, and service layers must be configured correctly. Misalignment can lead to incomplete results, restricted functionality, or inconsistent analyst experiences.

Finally, governance processes such as access review, monitoring, and adherence to least privilege principles should be implemented. These controls ensure that Copilot usage remains compliant, auditable, and aligned with organizational security policies.

RBAC Framework for Security Copilot

Security Copilot adopts a multi-layer RBAC model consisting of three tightly integrated layers. These layers collectively determine whether a user can access Copilot features and what data they can retrieve.

RBAC Layer Mapping

RBAC Layer	Role Type	Purpose	Example Roles	Access Impact
Security Copilot Platform	Feature access control	Determines who can use Copilot capabilities	Security Copilot Owner, Security Copilot Contributor	Enables use of Copilot features but does not grant data access
Microsoft Entra ID	Identity and directory governance	Controls access to identity data and reports	Security Reader, Reports Reader, Security Administrator	Governs identity insights and directory visibility
Service-Specific RBAC	Data access control	Defines access to security data within services	Defender Security Reader, Sentinel Reader	Determines what Copilot can retrieve and present

This layered approach ensures that no single role grants full access. All three layers must align for complete functionality.

Security Copilot Platform Roles

Security Copilot platform roles control who can interact with the Copilot interface and execute AI-driven workflows.

The Security Copilot Owner role provides administrative control over Copilot configuration, including access management and platform-level settings. This role is typically assigned to administrators responsible for governance and operational enablement.

The Security Copilot Contributor role enables analysts to run prompts, perform investigations, and interact with Copilot features during daily SOC operations. However, this role does not grant visibility into security data by itself.

This clear separation ensures that Copilot remains a controlled interface layer rather than a source of privilege escalation.

Microsoft Entra ID Roles

Microsoft Entra roles govern access to identity-related data, which is critical for security operations involving user behavior, sign-in logs, and directory insights.

Roles such as Security Reader provide read-only visibility into security data, while Reports Reader enables access to reporting and analytics capabilities. In certain advanced cases, the Security Administrator role may be required for configuration-level actions.

The document emphasizes avoiding excessive privilege assignment, particularly the use of Global Administrator roles for daily operations, as this conflicts with least privilege principles.

Service-Specific RBAC Roles

Service-level roles determine the data sources that Security Copilot can access when embedded in platforms.

In Microsoft Defender XDR, roles such as Security Reader allow access to alerts, incidents, and endpoint data. In Microsoft Sentinel, Sentinel Reader provides access to log data, analytics, and incidents. In Microsoft Entra, roles like Reports Reader provide access to identity insights.

Copilot cannot retrieve or analyze data beyond what these roles permit. The output it generates is always constrained to the user’s effective permissions across these services.

Unified RBAC Behavior in Embedded Experience

In an embedded scenario, all three RBAC layers are evaluated simultaneously.

When a SOC analyst invokes Copilot in Defender, the system validates whether the user has permission to use Copilot, access identity data, and retrieve Defender-specific insights. Only when all these conditions are satisfied does Copilot provide a comprehensive output.

This ensures that Copilot responses are both contextually rich and access-compliant, eliminating the risk of unauthorized data exposure while maintaining operational efficiency.

Security Copilot Core Use Cases

Security Copilot enables a layered set of capabilities that span both analyst interaction patterns and agent-driven execution models. These use cases collectively enhance SOC efficiency, decision-making, and operational scalability.

Use Case Mapping Table

Use Case	Description	Embedded / Agent Example	Value to SOC
Summarization	Transforms complex alerts, incidents, and telemetry into structured, human-readable insights by correlating signals across multiple sources	Summarizing a Defender XDR incident involving endpoint, identity, and cloud alerts into a unified attack narrative	Reduces analyst fatigue and significantly accelerates triage by eliminating manual data aggregation
Guided Response	Provides contextual, step-by-step investigative guidance and recommended remediation actions based on observed patterns and threat intelligence	Suggesting investigation paths in Sentinel, including pivoting to identity logs, device timeline, and lateral movement indicators	Improves consistency in investigations and enables less experienced analysts to operate effectively
Script Analysis	Evaluates scripts, queries, and command-line activities to identify malicious patterns, errors, or optimization opportunities	Analyzing PowerShell scripts or KQL queries used in threat hunting scenarios to detect obfuscation or suspicious logic	Enhances detection accuracy and reduces the risk of missing critical indicators
Reporting	Generates structured incident summaries, executive reports, and compliance-ready documentation with contextual insights	Producing incident summaries for leadership or compliance teams with both technical and business context	Improves communication, supports audit readiness, and reduces manual reporting overhead

Agent-Driven SOC Use Cases (Expanded Capabilities)

With the introduction of Security Copilot agents, the platform extends beyond assistance into orchestrated, intelligence-driven operations across SOC workflows.

Agent-Based Use Case	Description	Real Agent Example	SOC Impact
Dynamic Threat Detection	Continuously analyzes telemetry to identify previously undetected or weak signals across the attack surface	Dynamic Threat Detection Agent correlates signals across Defender workload telemetry to surface hidden threats	Improves detection coverage and reduces the likelihood of missed attacks
Threat Intelligence Correlation & Briefing	Aggregates internal and external intelligence sources to generate contextual threat insights aligned to organizational risk	Threat Intelligence Briefing Agent produces structured intelligence reports based on attack patterns and exposure context	Enhances situational awareness and supports proactive defense strategies
Advanced Threat Hunting	Enables hypothesis-driven and AI-assisted threat hunting by generating queries, exploring telemetry, and correlating historical data	Advanced Threat Hunting Agent builds and executes queries across Defender and Sentinel datasets for proactive investigation and telemetry exploration	Accelerates threat discovery and reduces reliance on manual query development
Security Analysis & Threat Prioritization	Performs AI-driven analysis of security telemetry to identify high-risk patterns, prioritize threats, assess risk exposure, and recommend investigative actions	Security Analyst Agent analyses password spray attacks, ransomware activity, malware campaigns, identity abuse, and other security risks by generating telemetry-driven assessments and recommendations	Improves analyst productivity, prioritizes high-impact threats, and enables faster decision making
Security Triage Automation	Automates alert prioritization and classification by adding contextual enrichment and reducing noise	Security Triage Agent / Phishing Triage Agent evaluates alerts and distinguishes between real threats and false positives	Reduces alert fatigue and improves prioritization accuracy in high-volume environments
End-to-End Investigation Orchestration	Performs multi-step investigation by gathering signals, correlating activity, and building attack timelines	Security Analyst Agent investigates incidents across identity, endpoint, email, cloud, and data signals to produce a consolidated incident narrative	Reduces Mean Time to Investigate (MTTI) and ensures consistent investigation outcomes
Cross-Domain Threat Correlation	Connects signals across identity, endpoint, cloud, email, and data domains to identify multi-stage attack chains	Agents operating across Defender, Entra, Sentinel, and Security Copilot correlate activities such as phishing leading to identity compromise and lateral movement	Breaks down silos and enables holistic threat visibility across the environment
Remediation & Response Enablement	Identifies vulnerable assets and supports remediation workflows through contextual recommendations	Agents integrated with endpoint and policy systems suggest patching actions, containment actions, and configuration changes based on detected risks	Improves response effectiveness and strengthens overall security posture

Each of these use cases operates within the RBAC boundaries defined earlier, ensuring secure and context-aware outputs.

Mapping Use Cases to SOC Processes

The four core use cases align directly with SOC operational stages, enabling a consistent and repeatable analysis model.

Summarization plays a significant role during the detection and triage phase, where analysts need quick clarity on incoming alerts. Instead of manually analyzing raw data, Copilot provides a structured overview, helping analysts determine priority and relevance.

Guided response becomes critical during the investigation and response phase, where decision-making speed is essential. By suggesting next steps and correlating data points, Copilot assists analysts in navigating complex attack scenarios.

Script analysis supports both threat hunting and investigation, allowing analysts to validate scripts, queries, or automation logic. This reduces the risk of overlooking malicious behavior embedded in scripts.

Reporting aligns with the post-incident and compliance phase, where structured documentation is required. Copilot generates summaries that can be shared with leadership or compliance teams, ensuring clarity and consistency.

Together, these use cases create a continuous cycle of detection, investigation, response, and reporting, fully integrated with SOC workflows.

Summary

Security Copilot’s embedded experience represents a transformative shift in how AI is integrated into security operations. By embedding intelligence directly within platforms such as Defender and Sentinel, it enhances analyst productivity while maintaining strict governance controls.

The three-layer RBAC model, consisting of Security Copilot roles, Microsoft Entra roles, and service-specific roles, ensures that access is both secure and compliant with least privilege principles. The On-Behalf-Of model further guarantees that Copilot does not expand access beyond existing permissions.

The inclusion of structured use cases such as summarization, guided response, script analysis, and reporting enables organizations to operationalize Copilot effectively across SOC processes.

When RBAC is properly aligned and integrated with SOC workflows, Security Copilot becomes a powerful enabler of faster investigations, improved accuracy, and enhanced security posture—all while maintaining strict control over data access and governance.

Automating Daily MDE Compliance Monitoring Across Azure VMs

SayanRoy — Mon, 15 Jun 2026 11:52:45 GMT

The Problem We’re Solving

Most security teams have no automated way to know when a VM silently falls out of MDE coverage, whether because the agent stopped, the VM was newly provisioned without onboarding, or the device stopped reporting. This Logic App closes that gap and puts the right information in front of the right people every day.

Disclaimer: This solution is designed for Azure Virtual Machines only. For non-Azure VMs onboarded to Microsoft Defender for Endpoint through Azure Arc, a separate companion blog will be published soon to cover that scenario.

What changes once you deploy this

Challenge Without This Logic App	How This Logic App Helps
Security gaps go undetected for days or weeks	Any VM that is not onboarded or has stopped reporting is caught within 24 hours of the daily run
No automated owner notification	The VM's ServerOwner tag is read automatically, and the owner is emailed directly with full compliance details
VMs with no owner fall through the cracks	Flagged explicitly in the IT summary report with instructions for how to assign the tag
Manual compliance reporting is time-consuming	Full CSV report auto-attached to every daily IT summary; no manual extraction needed
Agents silently stop reporting after onboarding	Detects "Onboarded, Not Reporting" as a distinct status, separate from "Not Onboarded"
Large multi-subscription environments are hard to cover	Paginated queries across all enabled subscriptions; every running VM is checked

Compliance States Detected

Compliance Status	Priority	What It Means
Not Onboarded	P2, High	The VM is running in Azure but has never appeared in MDE. There is zero security telemetry for this machine.
Onboarded, Not Reporting	P3, Medium	The VM was previously enrolled but has not checked in within the configured window. The MDE agent may be stopped or the VM may have lost network connectivity to MDE.
Compliant	No alert	VM is onboarded and checked in within the required time window. It is excluded from all notifications.

Running VMs Only: This workflow queries Azure Resource Graph with a filter of powerState == "VM running". Deallocated, stopped, and powered-off VMs are intentionally excluded — they are not expected to report to MDE while offline. Only machines that are turned on are evaluated.

Workflow Architecture

The workflow runs as a sequential daily pipeline. All Azure VM data and MDE device data are collected into memory first, then each VM is evaluated in a single For Each loop.

Execution Pipeline

Recurrence trigger fires daily at 08:00 IST.
CONFIG compose action reads MDE_LASTSEEN_HOURS (default 24). This defines the compliance window: how recently a VM must have reported to MDE to be considered Compliant.
Init-varITTeamEmail and Init-varSenderEmail load the configurable email addresses used for sending and receiving notifications.
Get-AllSubscriptions calls the Azure Management API to discover all subscriptions in the tenant.
ForEach-Subscription runs a paginated Azure Resource Graph query per enabled subscription, collecting all running VMs along with Private IP, OS Type, Location, ServerOwner tag, and VM UUID.
Init-MDEVariables then Paginate-MDEDevices call the MDE Security Center API in pages of 10,000 to load every enrolled device into the AllMDEDevices array.
ForEach-AzureVM looks each Azure VM up in AllMDEDevices and determines compliance status and priority.
Non-compliant handling builds HTML and CSV rows. If the VM has a ServerOwner tag, a compliance alert email goes to the owner with the IT Team CC'd. If there's no owner, the VM is appended to NoOwnerList.
IT Summary email is sent once all VMs are processed. If any non-compliant VMs were found, the consolidated IT report is sent with the CSV attachment. Otherwise an All Clear email is sent.

How Azure VM Data is Matched to MDE Data

Each Azure VM is matched against the MDE device list using a two-level strategy. Both checks run for every VM on every run.

Match Method	How It Works
Primary: Azure VM ID	Compares azureVmId from the MDE device record (lowercase) against the VmId captured from Azure Resource Graph (lowercase). Immune to hostname changes; this is the preferred match.
Fallback: Hostname + IP	Checks that MDE computerDnsName starts with the Azure VM name (case-insensitive) AND lastIpAddress matches the Azure Private IP. Both conditions must be true.
Not Found	A synthetic MDE record with onboardingStatus: "NotFound" is created. The VM is treated as Not Onboarded and a P2 High alert is raised.

Pagination Design

The workflow handles large environments through two independent pagination mechanisms that run before any compliance evaluation begins.

Data Source	Page Size	Mechanism
Azure Resource Graph	1,000 VMs per page	Uses $skipToken from the response. The Until loop re-queries with the token until no token is returned (last page). Variables VMSkipToken and VMFetchComplete manage loop state per subscription. Supports up to 50,000 VMs (50 pages).
MDE Security Center API	10,000 devices per page	Uses the $skip offset parameter. MDESkip is incremented by 10,000 each iteration. The loop stops when a page returns fewer than 10,000 records. Supports up to 500,000 MDE devices (50 pages × 10,000).

Prerequisites
Azure Resources

Resource	Requirement	Notes
Azure Logic App	Standard plan, Stateful workflow	Consumption plan also supported
Managed Identity	System-assigned on the Logic App	Enable under Logic App > Identity
Sender mailbox (varSenderEmail)	Licensed Microsoft 365 account	Emails are sent FROM this address
IT Team email (varITTeamEmail)	Valid email address or distribution list	Receives all reports; CC'd on owner alerts
Azure VMs	Running, with ServerOwner tag (recommended)	Tag value must be a valid email address
MDE licensing	Microsoft Defender for Endpoint P1 or P2	Tenant must be enrolled in MDE

The ServerOwner Tag

Server owner notifications rely on a VM-level Azure tag. Without it, the VM is included in the IT summary, but no individual alert is sent to an owner.

Tag Name	Expected Value	Effect
ServerOwner	Valid email, e.g. john@yourcompany.com	Compliance alert sent TO this address; IT Team CC'd

If the tag is missing or empty, the VM is flagged in the Action Required: No Owner Tag Found section of the IT summary email, with step-by-step instructions for tagging it in the Azure Portal.

Required Permissions & Why

The Logic App's Managed Identity must be granted three API permissions. These are Application permissions that cannot be assigned through the Azure Portal UI, so the PowerShell script in Section 4.3 must be used. Admin consent is required.

Permission Summary

Permission	API / Service	AppId	Why It Is Required
user_impersonation	Azure Management	797f4846-ba00-4fd7-ba43-dac1f8f63013	Allows the Managed Identity to call the Azure Resource Graph API to query VM inventory across all subscriptions. Without this, the workflow cannot discover VMs.
WindowsDefenderATP.Read.All	MDE Security Center	fc780465-2017-40d4-a0c5-307022471b92	Allows reading all device records from the MDE API (/api/machines). This returns onboarding status, last seen time, and health status — the core compliance data.
Mail.Send	Microsoft Graph	00000003-0000-0000-c000-000000000000	Allows sending emails via the Graph /sendMail endpoint on behalf of the varSenderEmail mailbox. Without this, no alerts or reports can be sent.

Important: The Azure Management and MDE permissions belong to separate service principals — they are NOT part of Microsoft Graph. Each permission must be assigned to its own service principal using the AppId shown above. The script in Section 4.2 handles this correctly.

Where to find the required values

Parameter	Where to find it in Azure Portal
$tenantID	Azure Portal > Microsoft Entra ID > Overview > Tenant ID
$managedIdentityObjectId	Logic App > Settings > Identity > System assigned tab > Object (principal) ID

Permission Assignment Script

Run this in Azure Cloud Shell or any terminal with the Microsoft.Graph PowerShell module installed. Update $tenantID and $managedIdentityObjectId before running.

# PowerShell # ── Update these two values before running ─────────────────────────── $tenantID = "<tenantID>" # Your Tenant ID $managedIdentityObjectId = "<objectID>" # MI Object ID # Install Microsoft.Graph if not already present if (!(Get-Module -ListAvailable -Name Microsoft.Graph)) { Install-Module -Name Microsoft.Graph -Scope CurrentUser -Force } # Connect to Microsoft Graph Connect-MgGraph -TenantId $tenantID ` -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All" # MDE Compliance Logic App needs 3 permissions across 3 different service principals $permissions = @( @{ Permission="user_impersonation"; AppId="797f4846-ba00-4fd7-ba43-dac1f8f63013" }, @{ Permission="WindowsDefenderATP.Read.All"; AppId="fc780465-2017-40d4-a0c5-307022471b92" }, @{ Permission="Mail.Send"; AppId="00000003-0000-0000-c000-000000000000" } ) foreach ($entry in $permissions) { $sp = Get-MgServicePrincipal -Filter "AppId eq '$($entry.AppId)'" $appRole = $sp.AppRoles | Where-Object { $_.Value -eq $entry.Permission } if ($appRole -ne $null) { New-MgServicePrincipalAppRoleAssignment ` -ServicePrincipalId $sp.Id ` -PrincipalId $managedIdentityObjectId ` -ResourceId $sp.Id ` -AppRoleId $appRole.Id Write-Host "Assigned: $($entry.Permission)" -ForegroundColor Green } else { Write-Host "Not found: $($entry.Permission)" -ForegroundColor Yellow } } Write-Host "All permissions assigned." -ForegroundColor Green

Verify Permissions Assigned

# PowerShell # Run after the assignment script to verify all 3 permissions are present Get-MgServicePrincipalAppRoleAssignment ` -ServicePrincipalId $managedIdentityObjectId | Select-Object AppRoleId, PrincipalDisplayName | Format-Table -AutoSize

Note: You should see three assignment rows in the output — one for each permission. If any are missing, re-run the assignment script. An error saying the assignment already exists is normal and can be safely ignored.

Creating the Logic App
Create the resource

Azure Portal > search Logic Apps > + Create.
Select your Subscription and Resource Group. Logic App name: la-mde-compliance-monitor.
Plan type: Standard > Windows > select or create a Hosting Plan > Review + Create > Create.
Once deployed, click Go to resource.

Enable System-assigned Managed Identity

Open the Logic App > left menu: Settings > Identity.
On the System assigned tab, toggle Status to On.
Click Save > Yes on the confirmation dialog.
The Object (principal) ID appears. Copy this value for the PowerShell script.
Run the Permissions Assignment script to assign all three permissions to this identity.

Why Managed Identity: A System-assigned Managed Identity is automatically scoped to this Logic App and deleted when the Logic App is deleted. It authenticates to Azure Management API, MDE API, and Microsoft Graph without any stored passwords or client secrets.

Create the workflow and import the JSON

Logic App > left menu: Workflows > + Add.
Workflow name: MDEComplianceMonitor. State type: Stateful. Click Create.
Click the workflow name > left menu: Code.
Press Ctrl + A > Delete to clear the editor completely.
Paste the complete workflow JSON from the companion file (see Appendix A).
Click Save. It should succeed with no validation errors.

Important: Always use Stateful. Stateless workflows do not support run history, have a 5-minute timeout, and do not retain intermediate state — all of which are required by this workflow's pagination loops.

Configuration: What You Can Change

After importing the JSON, update only the values described below. Everything else runs automatically.

Email Address Variables

Variable	Description	Where to Update
varITTeamEmail	The IT Team email address. All IT Summary reports are sent TO this address. All per-VM owner emails CC this address.	3000
varSenderEmail	The Microsoft 365 licensed account that emails are sent FROM via Graph API. Must have Mail.Send permission granted to the Managed Identity.	3000

Compliance look-up window: MDE_LASTSEEN_HOURS

This setting in the CONFIG compose action defines how recently a VM must have reported to MDE to count as Compliant. Default is 24 hours.

Value	Behaviour
24 (default)	Compliant if the VM checked in with MDE within the last 24 hours. Recommended starting point.
12	Stricter check; suitable for high-security environments requiring near-real-time coverage.
48	More relaxed; suitable for environments with scheduled maintenance windows or intermittent connectivity.

Running VMs Only

The Azure Resource Graph query includes a filter for powerState == "VM running". This means:

Deallocated VMs are excluded (not expected to report to MDE while offline).
Stopped (allocated) VMs are excluded.
Newly started VMs are included and checked on the next daily run.

To Change the Filter: To change the power state filter, locate the "query" string inside the Build-VMQuery-Paged action and modify the | where powerState == clause. For example, removing the filter entirely will check all VMs regardless of state.

Sample Email Notifications

The screenshots below show actual emails generated by this workflow. All sensitive data (email addresses, VM names, subscription IDs, IP addresses) has been redacted.

Per-VM owner alert

Sent to the server owner (ServerOwner tag) when their VM is non-compliant. The IT Team is CC'd. The email contains full server details, compliance status, priority, last MDE check-in time, and resolution SLA.

Note: If no ServerOwner tag is set the VM is skipped here and included in the "No Owner Tag Found" section of the IT summary instead.

IT Team Daily Summary Report

Sent once per day to the IT Team after all owner emails are dispatched. Shows up to 20 VMs inline with a full CSV attachment containing the complete list, plus a dedicated section for VMs with no owner tag.

Note: The CSV attachment always contains the complete list of all non-compliant VMs regardless of count. The inline HTML table is limited to 20 rows to keep the email size manageable.

All Compliant VMs:

If all VMs are compliant, you’ll see email like this:

Post-Deployment Checklist

Before you leave the workflow running unattended, walk through this checklist once.

#	Item
1	Logic App resource created (Standard plan, Stateful workflow)
2	System-assigned Managed Identity enabled; Object ID copied
3	PowerShell script run; user_impersonation, WindowsDefenderATP.Read.All, and Mail.Send assigned
4	Permissions verified using Get-MgServicePrincipalAppRoleAssignment (3 rows expected)
5	Workflow JSON pasted into Code view; saved without validation errors
6	varITTeamEmail updated to your IT security team or distribution list address
7	varSenderEmail updated to a licensed Microsoft 365 mailbox
8	MDE_LASTSEEN_HOURS reviewed (default 24, adjust if needed)
9	At least one Azure VM has the ServerOwner tag set with a valid email
10	Manual run triggered: Logic App > Overview > Run Trigger > Run
11	Run history shows Succeeded; no 401 or 403 errors on any HTTP action
12	IT Team received the daily summary email with CSV attachment
13	Server owner received a per-VM alert with the IT Team CC'd
14	Recurrence trigger confirmed running daily at 08:00 IST

Wrapping Up

What I love about this is how much it accomplishes with so little: a Logic App, a Managed Identity, and three permissions. No connectors, no secrets to rotate, no third-party services. Yet every morning, your security team starts the day knowing exactly which VMs are out of MDE coverage and which owners have already been notified.

If you adopt this pattern, here are a few natural next steps to consider:

Hook into Microsoft Sentinel by writing non-compliant VMs to a custom table for trend analysis.
Auto-create ServiceNow or Jira tickets for VMs that remain non-compliant for more than 48 hours.
Extend the match logic to include Arc-enabled servers, not just Azure VMs.
Add a Teams adaptive card notification alongside email for faster response.

I'd love to hear how you're solving MDE coverage gaps in your environment.

Appendix A: Workflow JSON

The complete Logic App workflow definition is provided below. To import it: open the Logic App in Azure Portal, navigate to the workflow, click Code view, press Ctrl + A to clear the existing content, paste the entire JSON, then click Save.

{ "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "contentVersion": "1.0.0.0", "triggers": { "Recurrence": { "recurrence": { "frequency": "Day", "interval": 1, "schedule": { "hours": [ "8" ], "minutes": [ 0 ] }, "timeZone": "India Standard Time" }, "evaluatedRecurrence": { "frequency": "Day", "interval": 1, "schedule": { "hours": [ "8" ], "minutes": [ 0 ] }, "timeZone": "India Standard Time" }, "type": "Recurrence" } }, "actions": { "CONFIG": { "runAfter": {}, "type": "Compose", "inputs": { "MDE_LASTSEEN_HOURS": 24 } }, "Set-ExcludedSubscriptions": { "runAfter": { "CONFIG": [ "Succeeded" ] }, "type": "Compose", "inputs": [] }, "Init-varITTeamEmail": { "runAfter": { "Set-ExcludedSubscriptions": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "varITTeamEmail", "type": "string", "value": "admin@contoso.onmicrosoft.com" } ] } }, "Init-varSenderEmail": { "runAfter": { "Init-varITTeamEmail": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "varSenderEmail", "type": "string", "value": "admin@contoso.onmicrosoft.com" } ] } }, "Get-AllSubscriptions": { "runAfter": { "Init-varSenderEmail": [ "Succeeded" ] }, "type": "Http", "inputs": { "uri": "https://management.azure.com/subscriptions?api-version=2022-12-01", "method": "GET", "headers": { "Content-Type": "application/json" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com" }, "retryPolicy": { "type": "fixed", "count": 3, "interval": "PT60S" } } }, "Parse-AllSubscriptions": { "runAfter": { "Get-AllSubscriptions": [ "Succeeded" ] }, "type": "ParseJson", "inputs": { "content": "@body('Get-AllSubscriptions')", "schema": { "type": "object", "properties": { "value": { "type": "array", "items": { "type": "object", "properties": { "subscriptionId": { "type": "string" }, "displayName": { "type": "string" }, "state": { "type": "string" } } } } } } } }, "Init-AllVMs": { "runAfter": { "Parse-AllSubscriptions": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "AllVMs", "type": "array", "value": [] }, { "name": "VMSkipToken", "type": "string", "value": "INIT" }, { "name": "VMFetchComplete", "type": "boolean", "value": false } ] } }, "ForEach-Subscription": { "foreach": "@body('Parse-AllSubscriptions')?['value']", "actions": { "Check-SubscriptionEnabled": { "actions": { "Reset-VMSkipToken": { "type": "SetVariable", "inputs": { "name": "VMSkipToken", "value": "INIT" } }, "Reset-VMFetchComplete": { "runAfter": { "Reset-VMSkipToken": [ "Succeeded" ] }, "type": "SetVariable", "inputs": { "name": "VMFetchComplete", "value": false } }, "Until": { "actions": { "Build-VMQuery-Paged": { "type": "Compose", "inputs": { "subscriptions": [ "@{items('ForEach-Subscription')?['subscriptionId']}" ], "query": "Resources | where type == 'microsoft.compute/virtualmachines' | extend VMName = tostring(name), ResourceGroup = tostring(resourceGroup), Location = tostring(location), OSType = tostring(properties.storageProfile.osDisk.osType), VMSize = tostring(properties.hardwareProfile.vmSize), ServerOwner = tostring(tags.ServerOwner), Environment = tostring(tags.Environment), SubscriptionId = tostring(subscriptionId), nicId = tolower(tostring(properties.networkProfile.networkInterfaces[0].id)), VmId = tolower(tostring(properties.vmId)) | join kind=leftouter (Resources | where type == 'microsoft.network/networkinterfaces' | extend privateIP = tostring(properties.ipConfigurations[0].properties.privateIPAddress) | project nicId = tolower(id), privateIP) on nicId | join kind=leftouter (Resources | where type == 'microsoft.compute/virtualmachines' | extend powerState = tostring(properties.extended.instanceView.powerState.displayStatus) | project id, powerState) on id | where powerState == 'VM running' | project VMName, ResourceGroup, Location, OSType, VMSize, ServerOwner, Environment = 'Azure', SubscriptionId, PrivateIP = privateIP, VmId, CloudEnvironment = 'Azure'", "options": { "$skipToken": "@if(equals(variables('VMSkipToken'), 'INIT'), '', variables('VMSkipToken'))" }, "$top": 1000 } }, "Get-VMs-Paged": { "runAfter": { "Build-VMQuery-Paged": [ "Succeeded" ] }, "type": "Http", "inputs": { "uri": "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": "@outputs('Build-VMQuery-Paged')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "ForEach-VM-Result-Paged": { "foreach": "@body('Get-VMs-Paged')?['data']", "actions": { "Append-SingleVM-Paged": { "type": "AppendToArrayVariable", "inputs": { "name": "AllVMs", "value": "@items('ForEach-VM-Result-Paged')" } } }, "runAfter": { "Get-VMs-Paged": [ "Succeeded" ] }, "type": "Foreach" }, "Check-VMSkipToken": { "actions": { "Set-VMFetchComplete": { "type": "SetVariable", "inputs": { "name": "VMFetchComplete", "value": true } } }, "runAfter": { "ForEach-VM-Result-Paged": [ "Succeeded" ] }, "else": { "actions": { "Set-VMSkipToken": { "type": "SetVariable", "inputs": { "name": "VMSkipToken", "value": "@body('Get-VMs-Paged')?['$skipToken']" } } } }, "expression": { "or": [ { "equals": [ "@string(body('Get-VMs-Paged')?['$skipToken'])", "" ] } ] }, "type": "If" } }, "runAfter": { "Reset-VMFetchComplete": [ "Succeeded" ] }, "expression": "@equals(variables('VMFetchComplete'), true)", "limit": { "count": 50, "timeout": "PT1H" }, "type": "Until" } }, "else": { "actions": {} }, "expression": { "and": [ { "equals": [ "@items('ForEach-Subscription')?['state']", "Enabled" ] } ] }, "type": "If" } }, "runAfter": { "Init-AllVMs": [ "Succeeded" ] }, "type": "Foreach" }, "Init-MDEVariables": { "runAfter": { "ForEach-Subscription": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "AllMDEDevices", "type": "array" }, { "name": "MDESkip", "type": "integer", "value": 0 }, { "name": "MDEFetchComplete", "type": "boolean", "value": false } ] } }, "Paginate-MDEDevices": { "actions": { "Get-MDEDevices-Page": { "type": "Http", "inputs": { "uri": "https://api.securitycenter.microsoft.com/api/machines?$select=computerDnsName,id,osPlatform,lastSeen,onboardingStatus,healthStatus,lastIpAddress&$top=10000&$skip=@{variables('MDESkip')}", "method": "GET", "headers": { "Content-Type": "application/json" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://api.securitycenter.microsoft.com" }, "retryPolicy": { "type": "fixed", "count": 3, "interval": "PT60S" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "Parse-MDEPage": { "runAfter": { "Get-MDEDevices-Page": [ "Succeeded" ] }, "type": "ParseJson", "inputs": { "content": "@body('Get-MDEDevices-Page')", "schema": { "type": "object", "properties": { "value": { "type": "array", "items": { "type": "object", "properties": { "computerDnsName": { "type": [ "string", "null" ] }, "id": { "type": [ "string", "null" ] }, "osPlatform": { "type": [ "string", "null" ] }, "lastSeen": { "type": [ "string", "null" ] }, "onboardingStatus": { "type": [ "string", "null" ] }, "healthStatus": { "type": [ "string", "null" ] }, "lastIpAddress": { "type": [ "string", "null" ] }, "azureVmId": { "type": [ "string", "null" ] } } } } } } } }, "Append-MDEPage-ToArray": { "foreach": "@body('Parse-MDEPage')?['value']", "actions": { "Append-SingleMDEDevice": { "type": "AppendToArrayVariable", "inputs": { "name": "AllMDEDevices", "value": "@items('Append-MDEPage-ToArray')" } } }, "runAfter": { "Parse-MDEPage": [ "Succeeded" ] }, "type": "Foreach" }, "Check-PageSize": { "actions": { "Set-FetchComplete-True": { "type": "SetVariable", "inputs": { "name": "MDEFetchComplete", "value": true } } }, "runAfter": { "Append-MDEPage-ToArray": [ "Succeeded" ] }, "else": { "actions": { "Increment-MDESkip": { "type": "IncrementVariable", "inputs": { "name": "MDESkip", "value": 10000 } } } }, "expression": { "and": [ { "less": [ "@length(body('Parse-MDEPage')?['value'])", 10000 ] } ] }, "type": "If" } }, "runAfter": { "Init-MDEVariables": [ "Succeeded" ] }, "expression": "@equals(variables('MDEFetchComplete'), true)", "limit": { "count": 50, "timeout": "PT1H" }, "type": "Until" }, "Init-Variables": { "runAfter": { "Paginate-MDEDevices": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "EmailsSent", "type": "array", "value": [] }, { "name": "NoOwnerList", "type": "array", "value": [] }, { "name": "NonCompliantList", "type": "array", "value": [] }, { "name": "SummaryStats", "type": "object", "value": { "TotalNonCompliant": 0, "P1Critical": 0, "P2High": 0, "P3Medium": 0, "P4Low": 0, "EmailsSent": 0, "NoOwnerFound": 0 } }, { "name": "HTMLRows", "type": "string" }, { "name": "NonCompliantCount", "type": "integer", "value": 0 }, { "name": "CSVRows", "type": "string", "value": "@{concat('\"VM Name\",\"Private IP\",\"OS Type\",\"Location\",\"Server Owner\",\"MDE Status\",\"Last Seen\",\"Priority\",\"Action Taken\",\"Subscription ID\"', decodeUriComponent('%0A'))}" }, { "name": "HTMLRowCount", "type": "integer", "value": 0 } ] } }, "ForEach-AzureVM": { "foreach": "@variables('AllVMs')", "actions": { "Find-VMInMDE-Filter": { "type": "Query", "inputs": { "from": "@variables('AllMDEDevices')", "where": "@or(and(not(equals(item()?['azureVmId'], null)), not(equals(item()?['azureVmId'], '')), equals(toLower(item()?['azureVmId']), toLower(items('ForEach-AzureVM')?['VmId']))), and(or(equals(item()?['azureVmId'], null), equals(item()?['azureVmId'], '')), startsWith(toLower(item()?['computerDnsName']), toLower(items('ForEach-AzureVM')?['VMName'])), equals(item()?['lastIpAddress'], items('ForEach-AzureVM')?['PrivateIP'])))" } }, "Find-VMInMDE": { "runAfter": { "Find-VMInMDE-Filter": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(greater(length(body('Find-VMInMDE-Filter')), 0), first(body('Find-VMInMDE-Filter')), json('{\"computerDnsName\":\"NOT_FOUND\",\"onboardingStatus\":\"NotFound\",\"lastSeen\":\"1900-01-01T00:00:00Z\",\"lastIpAddress\":\"N/A\",\"healthStatus\":\"Unknown\"}'))" }, "Get-ComplianceStatus": { "runAfter": { "Find-VMInMDE": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(equals(outputs('Find-VMInMDE')?['computerDnsName'], 'NOT_FOUND'), 'Not Onboarded', if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(greater(outputs('Find-VMInMDE')?['lastSeen'], addHours(utcNow(), mul(-1, outputs('CONFIG')?['MDE_LASTSEEN_HOURS']))), 'Compliant', 'Onboarded - Not Reporting'), 'Not Onboarded'))" }, "Get-Priority": { "runAfter": { "Get-ComplianceStatus": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(equals(outputs('Get-ComplianceStatus'), 'Not Onboarded'), 'P2 - High', if(equals(outputs('Get-ComplianceStatus'), 'Onboarded - Not Reporting'), 'P3 - Medium', if(equals(outputs('Get-ComplianceStatus'), 'Compliant'), 'Compliant', 'P4 - Low')))" }, "Is-NonCompliant": { "actions": { "Append-CSVRows": { "type": "AppendToStringVariable", "inputs": { "name": "CSVRows", "value": "\"@{items('ForEach-AzureVM')?['VMName']}\",\"@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}\",\"@{items('ForEach-AzureVM')?['OSType']}\",\"@{items('ForEach-AzureVM')?['Location']}\",\"@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'No Owner Tag', items('ForEach-AzureVM')?['ServerOwner'])}\",\"@{outputs('Get-ComplianceStatus')}\",\"@{if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)')), concat(outputs('Find-VMInMDE')?['onboardingStatus'], ' - Last Seen: ', convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')))}\",\"@{outputs('Get-Priority')}\",\"@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'IT Team Notified', 'Email sent to Server Owner')}\",\"@{items('ForEach-AzureVM')?['SubscriptionId']}\"@{decodeUriComponent('%0A')}" } }, "Check-HTMLRowCount": { "actions": { "Append-HTMLRows": { "type": "AppendToStringVariable", "inputs": { "name": "HTMLRows", "value": "<tr><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:600;\">@{items('ForEach-AzureVM')?['VMName']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['OSType']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['Location']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'No Owner Tag', items('ForEach-AzureVM')?['ServerOwner'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;color:#c80000;\">@{outputs('Get-ComplianceStatus')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)')), concat(outputs('Find-VMInMDE')?['onboardingStatus'], ' - Last Seen: ', convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')))}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Get-Priority')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'IT Team Notified', 'Email sent to Server Owner')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-break:break-all;\">@{items('ForEach-AzureVM')?['SubscriptionId']}</td></tr>" } }, "Increment-HTMLRowCount": { "runAfter": { "Append-HTMLRows": [ "Succeeded" ] }, "type": "IncrementVariable", "inputs": { "name": "HTMLRowCount", "value": 1 } } }, "runAfter": { "Append-CSVRows": [ "Succeeded" ] }, "else": { "actions": {} }, "expression": { "and": [ { "less": [ "@variables('HTMLRowCount')", 20 ] } ] }, "type": "If" }, "Increment-NonCompliantCount": { "runAfter": { "Check-HTMLRowCount": [ "Succeeded" ] }, "type": "IncrementVariable", "inputs": { "name": "NonCompliantCount", "value": 1 } }, "Check-ServerOwner": { "actions": { "Send-OwnerEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "[@{outputs('Get-Priority')}] MDE Compliance Alert - @{items('ForEach-AzureVM')?['VMName']}", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:680px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;overflow:hidden;\"><div style=\"background:#c80000;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Alert</h2><p style=\"color:#ffcccc;margin:6px 0 0;font-size:13px;\">Priority: @{outputs('Get-Priority')}</p></div><div style=\"padding:28px;\"><p style=\"margin-top:0;font-size:14px;\">Your server <strong>@{items('ForEach-AzureVM')?['VMName']}</strong> has a Microsoft Defender for Endpoint compliance issue requiring immediate attention.</p><table style=\"width:100%;border-collapse:collapse;font-size:14px;\"><thead><tr style=\"background:#f5f5f5;\"><th style=\"text-align:left;padding:10px 14px;border:1px solid #ddd;width:38%;\">Field</th><th style=\"text-align:left;padding:10px 14px;border:1px solid #ddd;word-wrap:break-word;\">Value</th></tr></thead><tbody><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Server Name</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['VMName']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Private IP</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">OS Type</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['OSType']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Location</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['Location']}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Compliance Status</td><td style=\"padding:9px 14px;border:1px solid #ddd;color:#c80000;font-weight:700;\">@{outputs('Get-ComplianceStatus')}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Priority</td><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:700;\">@{outputs('Get-Priority')}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">MDE Onboarding Status</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Find-VMInMDE')?['onboardingStatus']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Last Seen in MDE (IST)</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)'))}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Resource Group</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['ResourceGroup']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Subscription ID</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-break:break-all;\">@{items('ForEach-AzureVM')?['SubscriptionId']}</td></tr></tbody></table><br/><table style=\"width:100%;border-collapse:collapse;\"><tr style=\"background:#fff8e1;\"><td style=\"padding:10px 14px;border:1px solid #ffe082;font-size:13px;\"><strong>Resolution SLA:</strong> P1 Critical - 24hrs | P2 High - 48hrs | P3 Medium - 72hrs</td></tr></table><br/><p style=\"font-size:13px;color:#555;\">For assistance contact IT Security: <a href=\"mailto:@{variables('varITTeamEmail')}\">@{variables('varITTeamEmail')}</a></p></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@{items('ForEach-AzureVM')?['ServerOwner']}" } } ], "ccRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" }, "retryPolicy": { "type": "fixed", "count": 2, "interval": "PT60S" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "Append-EmailsSent": { "runAfter": { "Send-OwnerEmail": [ "Succeeded" ] }, "type": "AppendToArrayVariable", "inputs": { "name": "EmailsSent", "value": "@{items('ForEach-AzureVM')?['VMName']} → @{items('ForEach-AzureVM')?['ServerOwner']}" } } }, "runAfter": { "Increment-NonCompliantCount": [ "Succeeded" ] }, "else": { "actions": { "Append-NoOwnerList": { "type": "AppendToArrayVariable", "inputs": { "name": "NoOwnerList", "value": "<tr><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:600;\">@{items('ForEach-AzureVM')?['VMName']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Get-ComplianceStatus')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:700;\">@{outputs('Get-Priority')}</td></tr>" } } } }, "expression": { "and": [ { "not": { "equals": [ "@items('ForEach-AzureVM')?['ServerOwner']", "" ] } } ] }, "type": "If" } }, "runAfter": { "Get-Priority": [ "Succeeded" ] }, "else": { "actions": {} }, "expression": { "and": [ { "not": { "equals": [ "@outputs('Get-ComplianceStatus')", "Compliant" ] } } ] }, "type": "If" } }, "runAfter": { "Init-Variables": [ "Succeeded" ] }, "type": "Foreach", "runtimeConfiguration": { "concurrency": { "repetitions": 1 } } }, "Check-AnyNonCompliant": { "actions": { "Send-ITSummaryEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "MDE Compliance Report (Azure Workloads) - @{variables('NonCompliantCount')} Non-Compliant VMs Found", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:1400px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;\"><div style=\"background:#0078d4;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Daily Report</h2><p style=\"color:#cce4ff;margin:6px 0 0;font-size:13px;\">Generated: @{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')} IST</p></div><div style=\"padding:28px;\"><table style=\"border-collapse:collapse;font-size:14px;margin-bottom:28px;\"><thead><tr style=\"background:#f0f0f0;\"><th style=\"padding:10px 18px;border:1px solid #ddd;word-wrap:break-word;\">Metric</th><th style=\"padding:10px 18px;border:1px solid #ddd;word-wrap:break-word;\">Value</th></tr></thead><tbody><tr><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">Total Non-Compliant VMs</td><td style=\"padding:9px 18px;border:1px solid #ddd;font-weight:700;color:#c80000;\">@{variables('NonCompliantCount')}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">Server Owners Notified</td><td style=\"padding:9px 18px;border:1px solid #ddd;color:#107c10;font-weight:600;\">@{length(variables('EmailsSent'))}</td></tr><tr><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">No Owner Tag</td><td style=\"padding:9px 18px;border:1px solid #ddd;color:#e65100;font-weight:600;\">@{length(variables('NoOwnerList'))}</td></tr></tbody></table><p style=\"background:#fff3cd;border:1px solid #ffc107;padding:10px 14px;border-radius:4px;font-size:13px;margin-bottom:16px;\">This report shows the first <strong>20 non-compliant VMs</strong> only. <strong>Please check the attached CSV file</strong> for the complete list.</p><table style=\"width:100%;table-layout:fixed;border-collapse:collapse;font-size:13px;\"><colgroup><col style=\"width:120px\"><col style=\"width:90px\"><col style=\"width:70px\"><col style=\"width:100px\"><col style=\"width:160px\"><col style=\"width:110px\"><col style=\"width:165px\"><col style=\"width:80px\"><col style=\"width:90px\"><col style=\"width:195px\"></colgroup><thead><tr style=\"background:#0078d4;color:#fff;\"><th style=\"padding:10px 12px;border:1px solid #005a9e;\">VM Name</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Private IP</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">OS Type</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Location</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Server Owner</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">MDE Status</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Last Seen (IST)</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Priority</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Action Taken</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Subscription ID</th></tr></thead><tbody>@{variables('HTMLRows')}</tbody></table><br/><h3 style=\"border-bottom:2px solid #e65100;padding-bottom:8px;\">Action Required - No Owner Tag Found</h3><div style=\"background:#fff8f0;border:1px solid #ffccbc;padding:16px;border-radius:4px;font-size:13px;margin-bottom:16px;\"><p style=\"margin:0 0 8px 0;\">The following <strong>@{length(variables('NoOwnerList'))}</strong> server(s) have no <strong>ServerOwner</strong> tag assigned.</p><ol style=\"margin:0;padding-left:20px;\"><li style=\"margin-bottom:6px;\">Identify the owner of each server below</li><li style=\"margin-bottom:6px;\">Go to the VM in Azure Portal → Tags → Add tag</li><li style=\"margin-bottom:6px;\"><strong>Tag Name:</strong> ServerOwner | <strong>Tag Value:</strong> owner email address</li><li>Once tagged, the next daily report will automatically notify the owner</li></ol></div><table style=\"width:100%;table-layout:fixed;border-collapse:collapse;font-size:13px;\"><thead><tr style=\"background:#e65100;color:#fff;\"><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">VM Name</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">Private IP</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">MDE Status</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">Priority</th></tr></thead><tbody>@{if(equals(length(variables('NoOwnerList')), 0), '<tr><td colspan=\"4\" style=\"padding:12px;text-align:center;\">None - All servers have owner tags assigned</td></tr>', join(variables('NoOwnerList'), ''))}</tbody></table></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ], "attachments": [ { "@@odata.type": "#microsoft.graph.fileAttachment", "name": "@{concat('MDE-Compliance-Report-', convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy'), '.csv')}", "contentType": "text/csv", "contentBytes": "@{base64(variables('CSVRows'))}" } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } } }, "runAfter": { "ForEach-AzureVM": [ "Succeeded" ] }, "else": { "actions": { "Send-AllClearEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "[@{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy')}] MDE Compliance Report - All VMs Compliant", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:600px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;overflow:hidden;\"><div style=\"background:#107c10;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Report</h2><p style=\"color:#c8e6c9;margin:6px 0 0;font-size:13px;\">Generated: @{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')} IST</p></div><div style=\"padding:28px;text-align:center;\"><h2 style=\"color:#107c10;\">All VMs Compliant</h2><p style=\"font-size:15px;color:#555;\">All Azure Virtual Machines are onboarded to Microsoft Defender for Endpoint and reporting within the required 24-hour window.</p><p style=\"font-size:13px;color:#888;\">No action required. The next report will be sent tomorrow at 08:00 IST.</p></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } } } }, "expression": { "and": [ { "greater": [ "@variables('NonCompliantCount')", 0 ] } ] }, "type": "If" } }, "parameters": { "$connections": { "type": "Object", "defaultValue": {} } } }, "parameters": { "$connections": { "type": "Object", "value": {} } } }

Analyse Intune Diagnostics Logs with GitHub Copilot

StefanRöll — Thu, 11 Jun 2026 12:15:59 GMT

Hello everyone! I’m Stefan Röll, Cloud Solution Architect at Microsoft Germany for Cloud Endpoints. I work closely with IT Admins to improve their experience with everything around Intune, W365 and Windows. I know that troubleshooting an issue can be time consuming and challenging. In this blog I would like to show you how your troubleshooting skills can be supercharged with AI.

TL;DR

The way I troubleshoot issues has completely changed with GitHub Copilot. I just provide it with Intune Diagnostics Logs, network traces etc. and let the magic happen. The output still requires deep technical skills, but finding the root cause of an issue is just way faster and easier now.

GitHub Copilot – not only for developers

GitHub Copilot is best known for helping developers to write and fix code.

But it also has tremendous debugging and troubleshooting skills. And the best part is that it only takes two minutes to set up and you will never go back trying to manually find an issue if you must work through a lot of log files.

Getting started in two minutes

Let’s get started:

Go to https://github.com/features/copilot/plans and get a GitHub Copilot Subscription. If you are interested in Business or Enterprise subscriptions, please reach out to your Customer Success Account Manager (CSAM) or sales team to get started. It is also likely that you company already has subscriptions that you can get internally.

Once you’ve got your subscription, Install GitHub Copilot CLI via terminal:

winget install GitHub.Copilot

Now you can start Copilot via the command:

copilot

Next, type

/login

and log in with your GitHub account.

Now you should add the Microsoft Learn MCP Server and the included skills. This helps Copilot to search through the Microsoft documentation.

You can do this with:

/plugin install microsoftdocs/mcp

Copilot is ready for your first troubleshooting session! 🎉

Example #1 – Why did our PCs restart during the day?

Let’s start with a typical scenario: “All our PCs restarted during business hours. Can you please find the root cause for this?”

Before Copilot, you had to manually check multiple places to find the root cause. Was it triggered by a Windows update, an app update, a driver issue, or another hidden background process?

Now the only thing we need are Intune Diagnostics logs. Simply go to your Intune Console and collect diagnostics:

Once they are uploaded, download the .zip file to a local folder like C:\Temp\CopilotAnalysis.

Next, open a command prompt and go to the folder with the extracted files and start Copilot

cd C:\Temp\CopilotAnalysis copilot

With “Shift + TAB” we switch over to the “Autopilot” mode of GitHub Copilot. This will tell Copilot to do its magic without asking for confirmation for each step. You can find more information about this mode here: https://docs.github.com/en/copilot/concepts/agents/copilot-cli/autopilot

If you don’t want that, you can also continue in normal mode, but expect a lot of confirmation prompts.

With a simple prompt, we can create a deep root cause analysis, and Copilot will use the provided diagnostics logs:

Based on the provided Intune Diagnostics logs, find out why the Windows 11 PC rebooted automatically during business hours. Once you have found the issue, confirm your findings with the configured Microsoft Learn MCP Server. Then create a Root Cause Analysis Report and save it as HTML in the same folder. Include a timeline with relevant events in the report. Extract all needed files like .zip, .cab that you need for the analysis.

Now you can watch Copilot working through the logs and after some minutes you will get a report like this:

Here we go. You can see that the reboot was caused by a misconfigured Intune app deployment.

⚠️Please be aware that AI can make mistakes. Never blindly trust the output, especially any recommendations for how to fix an issue. ⚠️

However, now we have a fantastic starting point. In this case, Copilot correctly identified the root cause and we can fix this in Intune

It also created the requested timeline

Example #2 – Why did the Autopilot deployment fail?

When Autopilot deployments fail, it can be hard to troubleshoot as you may not have the affected device in front of you. Therefore, it is great that Intune automatically uploads diagnostics logs when this happens. In this example, an Autopilot deployment failed, and we are going to analyse the logs with Copilot.

I downloaded the logs to a new folder, opened the terminal, navigated to the folder, and started Copilot:

Now I am going to analyse this with a different prompt:

Analyse the provided Intune Diagnostics logs and find out why this Windows 11 Autopilot deployment failed. Once you have found the issue, confirm your findings with the configured Microsoft Learn MCP Server. Then create a Root Cause Analysis Report and save it as HTML in the same folder. Include a timeline with relevant events in the report. Extract all needed files like .zip, .cab that you need for the analysis.

After a beverage of choice, I had much more clarity on what happened:

Root cause: Enrollment Status Page (ESP) remained blocked in Account setup by a required user-targeted WinGet app that did not complete download/install during the observed log window. The blocking app was Sysinternals Suite - Req - All Users (Win32App_9c514d25-f55e-4177-af53-ca5ebbcf2619, package 9P7KNL5RWT25).

Remarks

In this blog, I did not cover different models, credits, better prompting, and other improvements you can make to optimise the analysis. I wanted to give IT Pros a quick start with GitHub Copilot CLI.

Summary

I highly recommend that you try GitHub Copilot yourself the next time you need to troubleshoot an issue. You will be amazed at how good it is at finding the root cause of an issue. This works with all kinds of log files, network traces, and more.

GitHub Copilot does not replace endpoint expertise, but it can dramatically reduce the time needed to move from raw diagnostics to a validated root-cause hypothesis.

I hope this blog helped you get started😊

Stefan Röll

Cloud Solution Architect – Microsoft Germany

Helpful resources and references:

https://learn.microsoft.com/en-us/training/support/mcp

https://learn.microsoft.com/en-us/training/support/mcp-get-started

https://github.com/features/copilot/plans

https://github.com/features/copilot/cli

Disclaimer:

This posting is provided "AS IS" with no warranties and confers no rights

At-Scale Failure Reporting for Azure Update Manager

rajeshkumar30 — Thu, 11 Jun 2026 06:32:42 GMT

Introduction

Azure Update Manager simplifies patching across Azure virtual machines and Azure Arc-enabled servers by providing a centralized platform for patch assessment and installation. However, as environments scale, a key challenge emerges—efficiently identifying and troubleshooting patch failures across large fleets of machines.

While Azure Update Manager surfaces detailed error messages in the Azure portal, this information is typically available only at an individual machine level.

In enterprise environments managing hundreds or thousands of systems, drilling into each VM to find error details quickly becomes impractical.

In this article, we walk through a real-world use case and demonstrate how to leverage Azure Resource Graph (ARG) to extract failed machines along with their error details for a specific maintenance run—using a single query.

The Challenge: Scaling Patch Failure Visibility

In a large enterprise deployment, Azure Update Manager was configured to manage patching across:

Windows and Linux virtual machines
Azure cloud VMs and Arc-enabled on‑premises servers
Multiple regions and subscriptions

While patching operations were largely successful, a subset of machines experienced failures. The key challenges faced by the operations team were:

Error messages were visible only by drilling into each failed VM in the portal
No built‑in way to aggregate failures across all machines
Lack of a simple mechanism to export:
- Failed VMs
- Error codes
- Error messages

The team needed a scalable, query‑driven approach to analyze failures across an entire maintenance run.

Key Insight: Where Azure Update Manager Stores Data

Azure Update Manager does not rely on Log Analytics to store operational results. Instead:

Patch assessment and installation results are stored in Azure Resource Graph
Azure Resource Graph acts as a centralized, queryable store for update operations

This design enables powerful querying without requiring additional ingestion, configuration, or cost overhead.

Understanding Maintenance Runs and Correlation IDs

Each Azure Update Manager maintenance run generates a unique identifier:

properties.correlationId represents the maintenance (schedule) run ID
All machines involved in the same patch cycle share this ID

This allows all machines within a single patch execution to be correlated and queried collectively.

The Solution: Query Failed VMs with Error Messages

Azure Resource Graph allows querying failures at scale using the maintenanceresources dataset.

Core Query (Kusto Query Language)

1 maintenanceresources

2 | where type =~ "microsoft.maintenance/applyupdates"

3 | where tostring(properties.correlationId) contains "<YourMaintenanceRunID>"

4 | where tostring(properties.status) =~ "Failed"

5 | project properties.resourceId, properties.errorCode, properties.errorMessage

What This Query Delivers

All machines that failed in a specific maintenance run
Error codes for troubleshooting
Full error messages that are otherwise visible only in the Azure portal

Note: Property names for error information can vary by environment. Validate available fields using Azure Resource Graph Explorer and adjust the project clause if required.

Sample Output (Conceptual)

Resource ID	Error Code	Error Message
vm-01	0x80244007	Windows Update API failed
vm-02	0x80072f8f	Connectivity issue
vm-03	1C	WSUS configuration issue

Advanced Scenario: Automatically Detecting the Latest Failed Maintenance Run

In real-world scenarios, you may not always know the maintenance run ID. The following query dynamically identifies the most recent maintenance run that had failures, and then retrieves all failed machines from that run.

1 // Step 1: Identify the latest maintenance run ID with failures

2 let lastFailedRun = toscalar(

3 maintenanceresources

4 | extend runId = extract(@"applyupdates/(\d+)$", 1, properties.correlationId)

5 | where type =~ "microsoft.maintenance/applyupdates"

6 | where tostring(properties.status) =~ "Failed"

7 | order by tostring(properties.startDateTime) desc

8 | take 1

9 | project runId

10 );

11 // Step 2: Query all failed VMs from that run

12 maintenanceresources

13 | where type =~ "microsoft.maintenance/applyupdates"

14 | where tostring(properties.correlationId) contains lastFailedRun

15 | where tostring(properties.status) =~ "Failed"

16 | project properties.resourceId, properties.errorCode, properties.errorMessage

This approach is ideal for automation, scheduled reporting, and dashboard scenarios.

Why This Approach Matters

Operational Efficiency

Eliminates manual portal navigation
Provides consolidated failure insights in seconds

Scalability

Works across large, distributed environments
Supports both Azure and hybrid (Arc‑enabled) machines

Automation Ready

Can be integrated into scripts, dashboards, and reporting pipelines
Enables proactive monitoring and alerting scenarios

Best Practices for Enterprise Patch Reporting

To maximize the value of this approach:

Capture and track maintenance run IDs
Use Azure Resource Graph as the primary reporting layer
Build reusable queries for different patch scenarios
Export reports for compliance and auditing
Correlate failures with root‑cause trends over time

Conclusion

As organizations scale patching operations with Azure Update Manager, visibility, speed, and automation become essential. While the Azure portal is effective for per‑machine troubleshooting, it is not optimized for fleet‑level analysis.

Azure Resource Graph fills this gap by enabling a shift from manual troubleshooting to automated, query‑driven failure analysis at scale. By adopting this approach, teams can significantly improve operational efficiency, reduce mean time to resolution, and build a more mature patch management strategy.

Final takeaway:

Don’t rely only on the portal
Leverage Azure Resource Graph to operationalize patch insights at enterprise scale

References

Azure Update Manager – Query resources with Azure Resource Graph
https://learn.microsoft.com/azure/update-manager/query-logs
Azure Update Manager – Troubleshooting guide
https://learn.microsoft.com/azure/update-manager/troubleshoot
Sample Azure Resource Graph queries for Azure Update Manager
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/update-manager/sample-query-logs.md

Redefining Security for an AI Driven World

edgarus71 — Fri, 22 May 2026 21:14:55 GMT

Vendors are being challenged to help customers address these challenges not as a point-solution vendor but as an end-to-end security and AI platform partner. By integrating identity, data governance, threat protection, and AI services into a unified ecosystem, Microsoft can deliver coordinated defenses, continuous compliance monitoring, and operational efficiency gains that fragmented toolsets cannot match. The sections that follow examine each challenge in depth — why it persists, what makes it hard, and specifically how Microsoft helps organizations bridge the gap.

Challenge 1: Safeguarding Data Privacy in the AI Era

AI systems are voracious consumers of data, and their adoption is outpacing the governance structures meant to protect it. More than 80% of business leaders cite leakage of sensitive data as their primary concern with generative AI, and nearly 48% have responded by banning all use of GenAI in the workplace entirely. Meanwhile, AI is raising the value of human-generated data as a critical training input while introducing entirely new avenues for potential data leakage through models and AI-powered applications.

Why This Challenge Persists

Fragmented tooling is the most immediate obstacle. Organizations are managing security, compliance, and data governance through disconnected platforms, creating siloed visibility that undermines cohesive protection. Only 31% of organizations have established a global data architecture, and just 25% maintain a global data quality program — two foundations essential for trustworthy AI innovation. Without enterprise-wide data classification and access controls, AI systems cannot distinguish what is too sensitive to surface.

At the same time, shadow AI compounds the risk. When employees turn to unapproved AI tools to boost productivity, sensitive data can flow to services outside IT's purview. According to Microsoft's guide on securing the AI-powered enterprise, 80% of business leaders worry that sensitive data could slip through the cracks due to unchecked AI use. AI models also inherit the permissions of their users, meaning an over-permissioned employee can unknowingly expose critical data to an AI system. Gartner has estimated that by 2025, generative AI will account for 10% of all data produced, further blurring the boundary between what is corporate-controlled and what is AI-generated.

Regulatory stakes add urgency: Gartner projects that by 2027, at least one global company will see its AI deployment banned by a regulator for non-compliance with data protection or AI governance legislation.

How can organizations bridge the gap?

Microsoft Purview provides a unified platform that combines data classification, data loss prevention (DLP), and AI-specific posture management to address fragmentation head-on. Its Data Security Posture Management (DSPM) for AI centralizes visibility into how AI applications interact with sensitive data across the organization — including Microsoft 365 Copilot, enterprise AI apps, and third-party AI tools. Security teams can see, for example, how many unlabeled files were referenced by Copilot and where the greatest concentrations of unprotected data reside.

Sensitivity labels created in Purview travel with documents and are enforced at inference time: when an AI app retrieves a file labeled "Highly Confidential," the system ensures the requesting user holds the required EXTRACT and VIEW usage rights before returning data. In practice, an executive running a Copilot query on a labeled strategy document would see the sensitivity label clearly marked alongside the response. Purview's DLP policies now extend to AI scenarios directly, including inline browser protection that can block or warn users attempting to paste sensitive data into third-party generative AI sites such as ChatGPT in Microsoft Edge, Chrome, or Firefox.

For organizations handling the most sensitive workloads, Azure Confidential Computing protects data even while it is being processed, using hardware-based Trusted Execution Environments (TEEs) that keep information encrypted in memory — invisible even to cloud operators. This capability is especially relevant for AI training and inference on regulated data, where customers need verifiable proof that their information was never exposed in plaintext during processing.

The net result is defense-in-depth for data: discover where sensitive information lives, classify it so AI systems respect boundaries, enforce policies at the point of AI interaction, and encrypt data in use for the highest-risk scenarios — all governed through a single compliance surface.

Challenge 2: The AI-Weaponized Threat Landscape

Adversaries are using AI to accelerate, scale, and personalize attacks faster than traditional defenses can respond. In the past year, 67% of all phishing attacks employed some form of AI, and organizations now face an average of 66 data security alerts per day — up from 52 in 2023. Under this pressure, 73% of cybersecurity experts admit they have missed, ignored, or failed to respond to high-priority security alerts.

Why This Challenge Persists

The speed differential is the core problem. AI-enabled threat actors can now use models to autonomously discover, chain, and exploit vulnerabilities, compressing the window from discovery to exploitation from months to hours. Attackers leverage generative AI for malware generation, automated vulnerability scanning, customized exploits, password cracking, sophisticated phishing and social engineering, and deepfake-based impersonation of data, email, and voice.

At the same time, AI systems themselves introduce novel attack surfaces. A staggering 88% of organizations, according to a Gartner Peer Community survey of 332 participants, are concerned about indirect prompt injection attacks — where malicious instructions embedded in data manipulate an AI's behavior to reveal confidential information or bypass controls. AI models are also susceptible to fabrications, initially known as hallucinations, in essence biased outputs, and data poisoning — risks that traditional vulnerability management frameworks were never designed to address.

From an operational standpoint, SOC analysts already spend nearly three hours per day on incidents, accumulating costs that reach billions in aggregate. Layering AI-driven attacks on top of this existing overload threatens to break conventional security operations entirely.

How can organizations bridge the gap?

Microsoft counters the asymmetry with AI-powered defense at cloud scale, grounded in threat intelligence no single organization could replicate alone. Microsoft processes more than 100 trillion security signals per day from endpoints, cloud services, identity systems, and the edge, and tracks 1,500 unique threat actor groups — including 600 nation-state actors, 300 cybercrime groups, and 200 influence operations groups. This intelligence feeds directly into detection models and product updates, ensuring customers benefit from patterns observed across billions of users and devices worldwide.

Microsoft Security Copilot is the most visible expression of this strategy. A generative AI security assistant combining advanced OpenAI models with a Microsoft-developed security-specific model, it helps analysts investigate and remediate incidents in natural language — from triaging complex alerts into actionable summaries, to reverse-engineering malicious scripts, to generating KQL queries for threat hunting. Early deployment data shows that Defender XDR customers using Security Copilot experienced a 30% reduction in incident resolution time in just three months.

For securing AI models themselves, Microsoft Defender for Cloud now offers AI model security (in public preview since March 2026), which scans custom AI models in Azure Machine Learning registries and workspaces for embedded malware, unsafe operators, and exposed secrets — integrated directly into CI/CD pipelines so risky models are stopped before reaching production.

The Microsoft Digital Defense Report 2025 reinforced this posture with seven top recommendations, led by managing cyber risk at the boardroom level, prioritizing identity protection, and investing in people alongside tools. Microsoft's approach treats AI threats not as a separate domain but as an intensification of the broader threat landscape that demands coordinated, platform-level defense.

Challenge 3: Identity and Access Governance for AI Agents

AI is creating an entirely new class of digital actors that most identity systems were never designed to manage. According to IDC, there will be approximately 1.3 billion AI agents operating across enterprises by 2028. These agents — which range from simple automation bots to fully autonomous decision-making systems — require resource access, generate data, and interact with users and services in ways that fundamentally differ from traditional applications or human users.

Why This Challenge Persists

Most organizations lack lifecycle management, ownership models, and policy controls for non-human identities, and AI agents amplify these gaps significantly. Industry analysts argue that AI agents should not be treated as just another non-human identity; they introduce complex delegation chains between humans, agents, and services that require distinct identity, accountability, and audit models. Traditional human-in-the-loop controls may not scale for agentic systems, yet new identity-centric governance mechanisms are only beginning to emerge.

Compounding the issue, the indeterministic nature of large language models means that an AI agent with broad access privileges may behave unpredictably — potentially taking actions its developers did not anticipate. Without proper controls, forgotten or orphaned agent identities can become easy targets for attackers, and the resulting security incidents may be difficult to attribute or contain.

How can organizations bridge the gap?

Microsoft extends its identity-first Zero Trust architecture to AI through Microsoft Entra Agent ID (in public preview). The core idea: every AI agent receives a unique, first-class identity — discoverable, manageable, and securable alongside human users, applications, and devices. Once registered, an agent's access can be scoped using the same enterprise-grade controls as any other identity: conditional access policies, role-based access control, lifecycle governance, and risk-based protection.

Conditional Access for Agents allows organizations to evaluate an agent's context and risk level before granting a token. Policies can enforce controls such as restricting agents to specific network locations or blocking access when risk signals are elevated. Microsoft is also developing RBAC guardrails specifically tailored to AI agent behaviors, acknowledging that LLM-based agents present heightened risk when granted broad role assignments.

For lifecycle management, Microsoft provides mechanisms for IT administrators to create automated lifecycle policies for agent identities — including periodic attestation by designated sponsors, automated cleanup of unmonitored agents, and notifications when agent identities approach expiration. This directly addresses the "agent sprawl" problem identified by CISOs and security architects.

At a broader level, Microsoft Agent 365 delivers a unified control plane for agents, aggregating posture, and real-time risk signals from Defender, Entra, and Purview into a single dashboard — providing discovery of both Microsoft and third-party agents, AI posture tracking, and governance controls to delegate remediation tasks to the appropriate teams. The Security Dashboard for AI (in GA now) answers the executive-level questions: Which AI assets exist in our environment? What is their current security posture? Where must we take action? — covering Microsoft 365 Copilot, Copilot Studio agents, Foundry apps, and third-party AI including Google Gemini, OpenAI ChatGPT, and MCP servers

Challenge 4: Regulatory Compliance and Ethical AI Governance

The regulatory landscape for AI is evolving faster than most organizations can track, and the stakes — legal, financial, and reputational — are escalating. More than 52% of business leaders admit they are unsure how to navigate rapidly evolving AI regulations. Frameworks like the EU AI Act (whose first obligations took effect on February 2, 2025), GDPR, and sector-specific rules such as DORA are converging to create a compliance environment that demands continuous adaptation.

Why This Challenge Persists

The EU AI Act alone adopts a risk-based approach to AI regulation, classifying systems by their potential impact on health, safety, and fundamental rights and imposing corresponding obligations for documentation, transparency, human oversight, and testing. Organizations must map every AI deployment to the correct risk category — and misclassification can lead to regulatory violations. Simultaneously, the responsibilities of security leaders are expanding to include governance and regulatory compliance oversight that traditionally belonged to legal or compliance teams.

The NC State University Executive Perspectives on Top Risks survey of 1,540 board members and C-suite executives ranked regulatory uncertainty and fragmentation as the eighth-highest near-term risk (2026–2028), and AI implementation risks as sixth. Among AI-specific concerns, 24% of respondents identified lack of governance and accountability for AI deployments as a top three worry. Culturally, building internal consensus around what constitutes "responsible" AI use — across diverse business units with different risk appetites — remains a persistent organizational challenge.

How can organizations bridge the gap?

Microsoft's Responsible AI program, anchored by six durable principles established in 2018 — Fairness, Reliability & Safety, Privacy & Security, Inclusiveness, Transparency, and Accountability — provides a governance blueprint that has proven stable even as AI technology evolves rapidly. These principles shape design, deployment, and oversight choices across Microsoft's products, and the company shares the lessons openly through its 2025 Responsible AI Transparency Report and customer guidance.

In preparing for the EU AI Act specifically, Microsoft has taken a proactive, layered approach to compliance, conducting impact assessments and adversarial red teaming on high-risk models and systems, and extending its Sensitive Uses governance program to ensure additional oversight for the most consequential AI deployments. Microsoft has also documented its approach to EU AI Act implementation to help customers understand how its products and services are being built to comply.

Operationally, the Security Dashboard for AI provides board-ready analytics and compliance insights, aggregating risk signals across Entra, Defender, and Purview into a single executive view with recommendations and direct remediation paths. This makes AI governance visible and actionable within the same tools security leaders already use for broader risk management.

Microsoft also fosters community-driven governance through initiatives like the Security for AI Accelerated Collaboration Forum (ACF), which brings together CISOs, security architects, SOC leaders, identity and data owners, and platform engineers to share challenges, shape roadmap priorities, and develop reusable governance frameworks.

Challenge 5: Integration Complexity and Workforce Readiness

Even when the right AI security tools exist, most organizations struggle to integrate them into existing technology stacks and to equip their people to use them effectively. Among executives surveyed by NC State University, 31% identified integrating AI with existing technologies, business processes, and workforce as a top-three AI concern, 29% pointed to equipping the workforce to realize AI's value proposition, and 28% flagged the inability to deploy AI at a competitive pace.

Why This Challenge Persists

Years of tool proliferation have left enterprises with fragmented security architectures. Organizations rely on disconnected platforms for endpoint protection, cloud workload security, identity management, and data governance — and AI capabilities are now being added to each domain independently. Microsoft's own research notes that organizations using fragmented platforms across security, compliance, and data teams see exacerbated security outcomes. When a data loss prevention alert in one system cannot be correlated with an identity anomaly in another, threats slip through.

At the same time, AI security as a discipline lacks comprehensive resources and seasoned experts. Because major cloud AI platforms only became generally available in 2021–2023, organizations must often develop protective measures without much external guidance or established precedent. The cybersecurity workforce shortage is well documented; the additional demand for professionals who understand both machine learning and security compounds it further.

The broader threat environment amplifies the urgency: cyberthreats have grown 5X in scale, Microsoft now tracks over 1,500 threat actor groups (up from roughly 300 just a few years ago), and the median time for an attacker to access confidential data after a successful phishing attack is just 1 hour 12 minutes. Teams that cannot integrate and respond quickly are structurally disadvantaged.

How can organizations bridge the gap?

Microsoft's primary answer to integration complexity is a unified, cloud-native security platform in which AI, identity, data governance, and threat protection work as a coordinated system. Security Copilot, for instance, is embedded within and integrates across Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune, Microsoft Entra, and Microsoft Purview. An analyst can use a single natural language interface to investigate incidents drawing on data from any of these products, generate remediation steps, build reports for stakeholders, and automate routine tasks with autonomous Security Copilot agents — all without switching consoles.

The inclusion of Security Copilot in Microsoft 365 E5 and E7 licensing simplifies adoption further. Customers receive a monthly allocation of SCUs or Secure Computing Units to empower Security Copilot, eliminating the need for separate AI security procurement. This positions integrated, agentic AI-powered security as a default capability rather than an add-on.

For endpoint-level visibility into AI agent sprawl, Microsoft Defender for Endpoint now automatically discovers supported AI coding agents on onboarded Windows 11 devices — including OpenClaw, Claude Code, Codex, Cursor, GitHub Copilot CLI, ChatGPT Desktop, Gemini CLI, and others — and surfaces them in the Defender portal inventory for investigation and correlation with existing device telemetry.

On workforce enablement, Microsoft operates the Security Copilot Adoption Hub, which provides role-specific guidance for CISOs, threat intelligence analysts, IT admins, and data security administrators on how to embed AI into their daily workflows. The broader Microsoft Learn platform now offers modules on securing AI applications and responsible AI governance.

Microsoft's role here is as a force multiplier: by consolidating tools, reducing integration burden, and actively investing in customer readiness, Microsoft enables organizations to convert AI from a source of complexity into an operational advantage — without leaving security behind.

Conclusion: Turning AI Security into Competitive Advantage

The five challenges examined here — data exposure, adversarial threats, identity sprawl, regulatory uncertainty, and integration complexity — will only intensify as AI adoption accelerates. Yet for organizations that address them proactively, the payoff extends well beyond risk mitigation. Robust AI security has become a source of trust with customers and regulators, a prerequisite for bold innovation, and a differentiator in markets where competitors may still be scrambling to catch up.

Microsoft's contribution is structural: an integrated platform where identity, data governance, threat intelligence, and compliance converge — backed by principles of Responsible AI that have remained durable since 2018 and by threat visibility at a scale (more than 100 trillion signals per day, 1,500+ tracked threat actor groups) that no single enterprise can replicate. For executive leadership, the actionable imperative is to treat AI security not as a technical footnote but as a boardroom priority — one that spans the CIO, CISO, Chief Data Officer, and business-unit leaders working together. As Microsoft's own AI security guidance articulates, cross-team collaboration, employee training, and transparent governance are just as essential as firewalls and encryption in building a secure AI future. The organizations that internalize this lesson will be those best positioned to harness AI's full potential — securely, responsibly, and at scale.

Tech Resources:

Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark

Securing AI and Navigating risks and compliance for the future

Entra agent Identities for AI agents

Secure Dashboard for AI

Microsoft Security Copilot

Microsoft Security Copilot FAQ

Build a Local Microsoft Sentinel Triage Agent in VS Code (Copilot + MCP)

absharan — Mon, 18 May 2026 04:28:02 GMT

Modern SOC work is not limited by data—it’s limited by the friction of collecting it. This post shows a local-first workflow that lets you investigate Microsoft Sentinel incidents from inside VS Code using GitHub Copilot Chat for reasoning and a small, deterministic MCP toolset for evidence retrieval and (optionally) approval-gated writeback.

What you’ll take away:

How to structure a Copilot + MCP triage loop that stays grounded in Azure evidence
A reliability pattern: fall back to KQL when Sentinel subresource APIs are flaky
A safety pattern: draft-first, explicit-approval writeback for incident comments

Why This Exists

Sentinel triage is powerful but fragmented: you jump between the portal, KQL, entity pivots, and case notes just to answer “what happened?” The goal here is to collapse that into a single, repeatable loop inside the editor.

Resolve the incident and pull the underlying alerts/entities
Pivot into AzureActivity (and other logs) to identify the actor and outcome
Use threat intelligence (TI) for context—not as the decision
Generate an evidence-backed narrative and draft comment; write back only on explicit approval

Design Principles

Evidence first: every claim must be traceable to Sentinel APIs or Log Analytics results
Small tool surface: fewer tools, clearer prompting, easier hardening
Reliability by design: if one API path fails, pivot to KQL and continue
Safety boundary: investigation and writeback are separate, and writeback is approval-gated

Architecture & Data Flow

A local TypeScript MCP server exposes a handful of triage tools to Copilot Chat in VS Code. Reads come from Sentinel + Log Analytics; writes (incident comments) are optional and require explicit approval.

Copilot Chat (VS Code) decides the next step and summarizes outputs
MCP server executes allowed tools: incident lookup, alert/entity retrieval, KQL queries, optional comment writeback
Evidence sources: Sentinel Incident APIs + Log Analytics tables (SecurityIncident, SecurityAlert, AzureActivity, TI tables)
Safety gate: writeback happens only after explicit approval; otherwise you get a draft

Tool Surface

MCP is useful here because it separates reasoning from execution: Copilot can decide what to do, but only the MCP server can do it—and only through tools you explicitly define and can audit.

list_incidents / get_incident (ground the case)
get_incident_alerts / get_incident_entities (fast path)
run_incident_kql (reliable fallback + pivots)
add_incident_comment (draft-first; writes only with approval)

The Investigation Loop (3 Steps)

Prompt used

sentinel-triage-local Investigate Sentinel incident 1478 end to end in workspace Subscription ID/Resource Group/Workspace Name. Resolve the incident ID first, collect underlying alerts and entities, enrich with AzureActivity and TI, determine whether the activity is malicious or benign, and return: 1. Investigation summary 2. Key evidence 3. Entity analysis 4. TI enrichment result 5. Risk assessment 6. Recommended disposition 7. Final incident comment draft Rules: - Use tool output only, no guessing. - If alert/entity subresource APIs fail, pivot to KQL and continue. - Do not submit the comment unless I explicitly say: APPROVE COMMENT.

1) Ground the incident

Resolve the human-friendly incident number to the Sentinel incident resource ID, then capture the metadata you need to drive every later pivot.

Incident numbers are convenient for analysts, but the actual investigation flow depends on the underlying incident resource ID. Resolving that first gives the workflow a concrete anchor for:

Title
Severity
Owner
Status
Alert count
Analytic rule IDs
Incident URL

This gives you the stable identifiers (and the URL) needed to retrieve alerts, entities, and supporting logs.

2) Collect alerts and entities (fast path)

Pull the alerts behind the incident and the entities they reference. When the incident subresource APIs behave, this is the fastest way to assemble the working set.

In the ideal path, the agent can call the incident alert and entity subresources directly. That gives fast access to:

Alert IDs
Alert names
Timestamps
Severities
Entities
Provider metadata

3) Stay reliable: pivot to KQL when APIs fail

In real environments, the incident subresource APIs for alerts/entities are not always dependable. When they fail, the workflow switches to Log Analytics and reconstructs the same evidence via KQL—so the investigation continues.

SecurityIncident to recover the incident record and alert IDs
SecurityAlert to retrieve alert details and entities
AzureActivity to determine who or what performed the operation
ThreatIntelligenceIndicator and ThreatIntelIndicators for enrichment

The High-Signal Pivot: AzureActivity

In the incidents I tested, AzureActivity was the fastest way to classify “suspicious deployment” alerts: it tells you who did the action, what operation ran, and whether it succeeded.

The evidence showed:

The caller was a single Microsoft Entra ID object ID
Claims_d.idtyp = "app"
Authorization_d.evidence.principalType = "ServicePrincipal"
The activity was tied to a policy assignment
The operation was MICROSOFT.RESOURCES/DEPLOYMENTS/WRITE
The result was BadRequest with InvalidTemplate

That pattern typically points to automation (service principal + policy-driven deployment) failing due to a bad template—not an interactive attacker.

Threat Intelligence: Use It as Context

Enrich observables against TI, but treat it as corroboration: a hit is not proof, and a miss is not a clean bill of health. In my test runs, TI mainly helped refine confidence after AzureActivity and alert evidence established the likely story.

Output: An Evidence-Backed Narrative (and a Draft Comment)

Once the tools return results, Copilot’s job is synthesis: turn structured evidence into a short narrative an analyst can paste into the case.

What happened, who/what triggered it, and whether it succeeded
Key supporting evidence (alerts, entities, AzureActivity pivots, TI context)
A recommended disposition and a draft incident comment

Incident comment written back automatically (after approval) (screenshot):

Safety + Reliability: Approval-Gated Writeback

The agent can draft a comment automatically, but it cannot change incident state unless the analyst explicitly approves. That boundary is what makes the workflow usable in real operations.

After approval, the tool submits the drafted comment directly to the Sentinel incident so the portal reflects the same evidence-backed narrative.

Default: return the draft comment only
On approval: acquire an ARM token via Azure CLI and submit via curl.exe (hardened with validation + retries)

Why This Is Worth Building

Less context switching: investigation happens where you already work
More consistency: the same loop runs every time, with deterministic tools
Better classification: AzureActivity pivots reduce false “user did X” assumptions
Safer automation: drafts are automatic; writes are explicit and auditable

Conclusion

AI is most useful in a SOC when it is constrained: deterministic tools fetch the evidence, the model synthesizes it, and humans keep control of state changes. A local Copilot + MCP workflow hits that sweet spot—faster triage for the SOC analysts.

TLS Certificate Pinning and Best Practices in Azure Open-Source Relational Databases

TameikaL — Mon, 15 Jun 2026 13:42:38 GMT

TLS certificate pinning in Azure Database for PostgreSQL and MySQL

Transport Layer Security (TLS) encrypts data in transit between client applications and the server and authenticates the service endpoint in client-server authentication.

Azure Database server certificates are issued by well-known trusted public Certificate Authorities (CAs), including Microsoft-issued certificates, and are validated by clients during the TLS handshake. Customers do not manage certificates on the server side.

Certificate pinning is a client-side security technique where an application restricts trust to a specific certificate, for example by thumbprint, public key, or CA, rather than relying solely on the default OS or platform trust store. The trust store contains pre-installed root CAs and may also include additional certificates configured by the client. During standard TLS validation, the client will trust any server certificate that chains to one of those root CAs.

When pinning is used, the client will only connect if the presented certificate chain matches exactly what it expects. However, the server has no visibility into whether pinning is configured on the client, and any certificate change (even a valid one) can cause connection failures.

Why detecting TLS certificate pinning is not possible by design

Certificate pinning is entirely client-side logic. From the server’s perspective, the client either completes the TLS handshake or aborts it. The server never sees:

Which certificate(s) the client trusts
Whether the client is comparing root CA, intermediate CA, leaf certificate or SPKI hash
Whether the trust decision was static or dynamic

TLS is designed so that trust evaluation happens entirely on the client, which is why the server has no visibility into the client’s software configuration or pinning behavior. If the client rejects the certificate (for example, due to pinning or trust validation failures), the connection is terminated before any application-level error or authentication occurs.

What the server can see is TLS handshake failure patterns, TLS protocol, and cipher negotiation.

TLS certificates in Azure OSS databases vs Azure SQL

The way TLS certificates are handled in Azure OSS databases versus Azure SQL is a core architectural difference.

In Azure SQL (including Azure SQL Database and Azure SQL Managed Instance), the database engine does not directly present a certificate bound to a specific server or host instance. Instead, client connections terminate at a service-managed endpoint. This abstraction allows certificates to be issued and rotated centrally by the service.

From the client’s perspective, it connects to a service-level endpoint (for example, <server>.database.windows.net), and the certificate chain represents the Azure SQL service rather than a specific machine. Clients are expected to trust the platform CA chain and validate the hostname. As a result, certificate pinning is generally not feasible or useful for Azure SQL, because the TLS endpoint is abstracted and managed by the service.

This is also why Azure SQL client configuration guidance emphasizes using Encrypt=True and TrustServerCertificate=False, ensuring that clients rely on standard TLS validation against the platform-managed certificate chain.

In contrast, Azure Database for PostgreSQL and MySQL expose a more traditional, database engine–level TLS surface where clients directly validate the server certificate chain, making certificate pinning possible. TLS is negotiated by the database engine itself, and the server presents a certificate chain anchored in public or regional certificate authorities.

This results in a fundamentally different trust model. In Azure OSS databases, TLS trust is primarily client-managed, whereas in Azure SQL it is platform-managed. While OSS customers have greater control over certificate validation, they are also responsible for appropriately managing trust configuration. Misconfigurations or overly rigid validation, such as pinning specific certificates, can increase operational risk, particularly during certificate rotations.

One of the most common complications during certificate rotations is certificate pinning.

Why certificate pinning is risky

While certificate pinning was historically used to reduce the risk of man-in-the-middle attacks, it introduces significant operational fragility in cloud environments, particularly during certificate rotations.

Server certificates and certificate authorities (CAs) must be rotated periodically to maintain security and compliance. In Azure Database for PostgreSQL and MySQL, when certificate pinning is used, clients bind trust to a specific certificate or CA. As a result, any change to the server certificate chain—including CA updates—can cause connection failures, even when the new certificates are fully valid and secure.

Recommended TLS certificate trust model for Azure OSS databases

Instead of pinning, adopt a CA‑based trust model that allows certificates to change safely.

Trust root CAs, not individual certificates.

Configure clients to use standard TLS validation against Azure-documented root CAs, rather than restricting trust to specific certificates or a narrowly scoped set of certificate authorities. Avoid configurations that effectively implement certificate pinning—such as trusting only a single certificate, public key, or limited CA set—unless explicitly required.

Maintain a flexible and up-to-date trust store

Clients rely on a trust store, key store, or equivalent certificate bundle to validate server certificates during TLS negotiation. While the exact format and configuration vary by client and environment, the same core principles apply across PostgreSQL and MySQL implementations.

Include the appropriate root and intermediate certificate authorities (CAs) required to validate the server certificate chain
Ensure that trust stores are periodically reviewed and updated in line with provider guidance and announced certificate authority changes.

For the current TLS certificates visit the Azure Database for PostgreSQL documentation and Azure Database for MySQL documentation.

Use certificate validation modes that rely on standard CA-based trust rather than pinning

For PostgreSQL client configurations, prefer:

sslmode=verify-ca
- Validates the server certificate chain against trusted CAs
sslmode=verify-full
- Verifies CA and hostname match

For MySQL client configurations, prefer:

ssl-mode=VERIFY_CA
- Validates the server certificate chain against trusted CAs
ssl-mode=VERIFY_IDENTITY
- Validates CA and hostname (like PostgreSQL verify-full)

These modes ensure that clients validate the server certificate chain against trusted CAs, and in stricter modes, verify hostname identity. They do not imply certificate pinning by themselves. They rely on standard CA-based trust.

Configurations only become rigid when trust is narrowly restricted, such as to a single certificate or limited CA set, often through custom or overly constrained trust stores. This effectively introduces certificate pinning.

When properly configured, these modes authenticate the service endpoint and protect against spoofing, while remaining resilient to certificate rotations.

Maintain a combined CA during certificate rotations

Azure may rotate root or intermediate CAs over time. When Azure announces a CA rotation:

Add the new root and intermediate CAs to the client trust store before the rotation begins
Retain existing root or intermediate CAs until the transition is fully complete
Avoid removing older certificates prematurely

This combined CA approach, using both the current and upcoming certificate authorities during the transition window, allows clients to continue validating the server certificate chain without interruption.

As you review your current client configurations, ensure your applications rely on CA-based trust, avoid overly restrictive certificate configurations such as certificate pinning, and are prepared to handle routine certificate rotations without disruption.

Check This Out! (CTO!) Guide (April 2026)

TysonPaul — Wed, 13 May 2026 03:25:05 GMT

Member: TysonPaul | Microsoft Community Hub

Announcing Public Preview for Essential Machine Management

Team Blog: Azure Governance and Management

Author: Meagan McCrory

Published: 04/06/2026

Summary: Microsoft has announced the public preview of Essential Machine Management within Azure’s Compute Infrastructure Hub. This new feature streamlines onboarding and management of servers and VMs across Azure and multi-cloud environments by enabling core capabilities like monitoring, updates, inventory, and configuration at the subscription level. It offers out-of-the-box best practices, automatic enrollment, and consistent operational coverage. Azure VMs and certain Arc-enabled servers can use these features at no extra cost, while other Arc-enabled servers will be charged $9 per server per month once billing begins. The preview is available in the Azure Portal.

New Local Management Group for ALZ & Updated Sovereign Policies for SLZ

Team Blog: Azure Governance and Management

Author: jtracey93msft

Published: 04/27/2026

Summary: Microsoft has introduced a new ‘Local’ Management Group in both Azure Landing Zone (ALZ) and Sovereign Landing Zone (SLZ) architectures to better govern Azure Local workloads and facilitate exit planning to Azure Local disconnected operations. Additionally, SLZ now uses new built-in policy initiatives aligned to sovereign control levels 1 (Data Residency), 2 (Encryption-at-Rest/Transit), and 3 (Encryption-in-Use), replacing previous broad baselines for clearer mapping, simplified compliance, and reduced maintenance. These updates improve governance, portability, and policy alignment for customers with sovereignty or resiliency requirements.

Copilot agents are scaling faster than most organizations expected

Team Blog: FastTrack

Author: JulieHersum

Published: 04/17/2026

Summary: The article discusses how Copilot agents are being adopted rapidly across organizations, moving from small pilots to broader enterprise use. While early adoption is smooth, scaling introduces new challenges, such as overlapping efforts, unclear ownership, and the need for coordination. The focus shifts from building agents to managing them effectively at scale, requiring clear frameworks and leadership alignment. Microsoft recommends a CIO-level framework to address these issues, helping organizations balance experimentation with coherence and guide responsible growth as Copilot agents become integral to business operations.

Copilot Chat in financial services: Is productivity moving faster than policy?

Team Blog: FastTrack

Author: JulieHersum

Published: 04/13/2026

Summary: The article discusses how financial services organizations adopting Copilot Chat are experiencing increased productivity, but this rapid progress is challenging existing governance and compliance policies. As usage expands beyond initial experimentation, leaders are seeking structured approaches to ensure responsible, repeatable adoption without increasing risk. Microsoft 365 Accelerator offers a planning kit to help organizations scale Copilot Chat while maintaining oversight, audit readiness, and governance, focusing on decision-making and risk management rather than just features. The article invites readers to reflect on their experiences and consider how to balance productivity with regulatory requirements.

Flexible Cooling for AI Growth: How Zonal Architecture Supports Diverse Hardware Needs

Team Blog: Azure Architecture

Author: stsolo

Published: 04/28/2026

Summary: Microsoft is introducing zonal cooling in its next-generation AI datacenters to address the diverse cooling needs of modern hardware, particularly AI accelerators requiring liquid cooling and general-purpose equipment relying on air cooling. Zonal cooling uses multiple independent water loops at different temperatures, improving energy efficiency, reducing carbon emissions, and supporting higher server density. This flexible architecture adapts to evolving hardware requirements, enhances performance, and aligns with Microsoft’s sustainability goals. Facility-level zonal cooling is expected to reduce Power Usage Effectiveness (PUE) by up to 10%, making datacenters more efficient and future-ready.

Running Diffusion Models at Scale on AKS

Team Blog: Azure Architecture

Author: PrabalDeb

Published: 04/29/2026

Summary: The article outlines best practices for running diffusion models at scale on Azure Kubernetes Service (AKS). It emphasizes separating API, dispatch, and GPU execution layers for flexible scaling, security, and observability. Key recommendations include isolating GPU workloads, leveraging Kubernetes-native or Service Bus/KEDA-based dispatch, using persistent storage for model caching, enforcing strong identity and secrets management, and instrumenting both application and hardware metrics. The architecture supports scalable, secure, and automated deployments, making AKS a robust platform for production-grade diffusion workloads beyond simple model hosting. Alternatives like KAITO suit less-customized scenarios.

Announcing Log Monitor v2.2.0 Release Candidate

Team Blog: Containers

Author: Bob_Sira

Published: 04/15/2026

Summary: Log Monitor v2.2.0 Release Candidate introduces a switch from Boost.JSON to the lightweight nlohmann/json library, reducing dependencies and build complexity while remaining backward compatible. This version adds an IIS on AKS deployment example, fixes several configuration parsing bugs, and addresses a path traversal vulnerability. The build system now uses CMake and vcpkg. Upgrading from v2.1.x requires no config changes, but output paths have changed. Updated CI/CD pipelines support the new dependency. Release binaries and documentation are available on GitHub, and user feedback is encouraged.

Simplifying gMSA for Windows Containers on AKS: Open-Source Tooling Now Available

Team Blog: Containers

Author: natashapolito

Published: 04/23/2026

Summary: Microsoft has released an open-source tool, available on GitHub, to simplify configuring Group Managed Service Accounts (gMSA) for Windows containers on Azure Kubernetes Service (AKS). This tooling helps organizations modernize Active Directory-dependent Windows applications for Kubernetes without major code changes, enabling secure AD authentication without domain-joined nodes. The repository includes a PowerShell module, automation scripts, and documentation to streamline gMSA setup and validation. Aimed at teams running or modernizing AD-integrated workloads on AKS, the tool reduces manual configuration and invites community feedback to further improve usability.

So, You’ve disabled Windows Hello for Business, but the User can still Sign-in using a PIN

Team Blog: Ask the Directory Services Team

Author: BrentCrummey

Published: 04/27/2026

Summary: Disabling Windows Hello for Business (WHfB) via Intune or Group Policy does not remove a user’s existing PIN sign-in if it was previously provisioned. The PIN option remains, and its removal button is greyed out due to policy design. To fully remove WHfB PIN sign-in, the user must manually delete their Windows Hello container using “certutil.exe -deleteHelloContainer,” after which they cannot re-enroll as long as the policy is disabled. This behavior is expected and documented by Microsoft.

Troubleshooting TPM Certificate: How to Fix the "Missing Stored Keyset" Error

Team Blog: Ask the Directory Services Team

Author: mdhabibnawaz

Published: 04/30/2026

Summary: The article explains the "missing stored keyset" error in TPM certificates, which occurs when applications can’t access necessary keys due to corrupted registry entries, permission issues, or misconfiguration. It provides a step-by-step troubleshooting guide: updating Windows and TPM firmware, verifying TPM status, checking certificate keysets, repairing certificates, resetting permissions, and re-enrolling certificates if needed. The article emphasizes maintaining backups, staying updated, and consulting official documentation or support if problems persist, highlighting the importance of proper TPM management for system security.

AHEAD helps us launch the Strategic Azure Storage Services Partner Program

Team Blog: Azure Storage

Author: karautenMSFT

Published: 04/30/2026

Summary: AHEAD, a premier Microsoft Cloud and AI Partner, has helped launch the Strategic Azure Storage Services Partner (SASS) Program, leveraging its extensive expertise in infrastructure, storage, and cloud solutions. AHEAD provides assessments, migration services, and access to best-of-breed ISV partners, ensuring Azure Storage customers receive optimal solutions for their needs. With over 1,000 Microsoft certifications and global reach, AHEAD delivers tailored guidance and implementation, driving innovation and resiliency for Azure users. Their collaboration has shaped the SASS channel strategy, benefiting customers with enhanced consulting, design, and migration services.

Prefix-scoped access for User Delegation SAS is now generally available for Azure Blob Storage

Team Blog: Azure Storage

Author: despindola

Published: 04/30/2026

Summary: Prefix-scoped access for User Delegation SAS is now generally available in all Azure regions for Azure Blob and Data Lake Storage. This feature allows administrators to grant access to all blobs within a specific prefix or virtual directory, rather than at the container or individual blob level. This simplifies permission management, especially for multi-tenant or organized data structures, and reduces the need for multiple tokens. Prefix-scoped SAS incurs no additional cost and is supported in the latest REST API and .NET SDK versions. Microsoft recommends using prefix-scoped SAS for more granular access control when SAS is required.

Announcing Native PowerShell Tooling for ReFS Snapshots

Team Blog: Storage at Microsoft

Author: Christina_Curlette

Published: 04/30/2026

Summary: Microsoft has released an open-source PowerShell module for native ReFS snapshot management, streamlining scripting and automation tasks. The module wraps the refsutil streamsnapshot utility, offering cmdlets for creating, listing, deleting, comparing, restoring, and exporting file-level snapshots with pipeline support and structured error handling. Designed for Windows Server 2019+ and Windows 10+, it simplifies operational safety, automated comparison, maintenance, and development workflows. Documentation and examples are available on GitHub, enabling easier integration of ReFS snapshots into PowerShell-based storage management.

Public Preview: Managed Identity support for graphical session recording

Team Blog: Azure Network Security

Author: aarontsang

Published: 04/30/2026

Summary: Azure Bastion now supports managed identities for graphical session recording in public preview. This feature allows Bastion to authenticate directly to an Azure storage account for saving session recordings using either a system-assigned or user-assigned managed identity, eliminating the need for manual credential management. Authentication is handled via Microsoft Entra ID, simplifying setup and aligning with Zero Trust principles. Administrators can centrally control access with Azure RBAC, streamlining management across multiple deployments. To use this feature, enable managed identity, assign appropriate roles, and configure the storage account as outlined in the Azure Portal.

General availability of Default Ruleset (DRS) 2.2 for Web Application Firewall

Team Blog: Azure Network Security

Author: andrewmathu

Published: 04/29/2026

Summary: Azure Web Application Firewall (WAF) now supports Default Rule Set (DRS) 2.2 for Azure Front Door and Application Gateway, offering enhanced security based on OWASP CRS 3.3.4 and Microsoft Threat Intelligence. DRS 2.2 improves detection for web vulnerabilities, reduces false positives with configurable paranoia levels, and provides broader, modern protection. Upgrading resets customizations, so planning is advised. DRS 2.2 delivers consistent and advanced security for internet-facing applications, enabling organizations to better defend against evolving threats while maintaining operational flexibility.

Join us at Microsoft Azure Infra Summit 2026 for deep technical Azure infrastructure content

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 04/07/2026

Summary: Microsoft Azure Infra Summit 2026 is a free, virtual event for IT professionals, platform engineers, SREs, and infrastructure teams, held May 19-21, 2026. Focused on advanced, engineering-led sessions (L300-400), it offers deep technical content on Azure infrastructure topics like hybrid operations, networking, storage, observability, and governance. The event emphasizes practical guidance, real-world examples, and peer-to-peer learning, aiming to equip attendees with actionable insights for building and operating Azure environments. Register at https://aka.ms/MAIS-Reg.

Internet Information Services Learning Path

Team Blog: ITOps Talk

Author: OrinThomas

Published: 04/14/2026

Summary: The "Internet Information Services Learning Path" provides a structured curriculum for learning to deploy, configure, manage, secure, and troubleshoot IIS on Windows Server and client systems. Covering both legacy and modern use cases, the modules include IIS installation, website and application configuration, administration, security best practices, and performance optimization. The learning path is relevant to most supported IIS versions and includes new features for Windows Server 2025, offering a comprehensive guide for effective IIS management and maintenance.

From Discovery to Executive Presentation: Plan Your Migration with Azure Migrate in Hours

Team Blog: Azure Migration and Modernization

Author: Shikher

Published: 04/03/2026

Summary: Azure Migrate streamlines the migration planning process by consolidating environment discovery, workload tagging, application grouping, and executive reporting into a single workflow. Using the Azure Migrate Collector, organizations can quickly scan their infrastructure offline, classify assets, and auto-group workloads into applications. The tool generates executive-ready PowerPoint reports with modernization, migration recommendations, security insights, and cost analysis, replacing manual processes that previously took weeks. Application-level assessments provide detailed migration strategies, supporting informed decision-making. This approach accelerates Azure migration planning for IT teams and partners, enabling rapid, data-driven presentations to stakeholders.

Production Cutover in Cloud-Native Migrations

Team Blog: Azure Migration and Modernization

Author: dhruti

Published: 04/15/2026

Summary: The article highlights that production cutover during cloud-native migrations, such as to Azure Kubernetes Service (AKS), involves more than just successful deployment—it requires coordinated runtime orchestration across compute, networking, storage, and integrations. Operational issues often arise only after traffic is routed, emphasizing the need for thorough validation and alignment of all dependencies, including disaster recovery, batch processing, and security. Effective cutover is an orchestrated event ensuring runtime readiness, not just deployment, with success dependent on continuous validation and system-wide coordination throughout the migration lifecycle.

Deploying DNS Private Resolvers and Private DNS Zones for Azure AI Supported Services

Team Blog: FastTrack for Azure

Author: munieswar_avulapalli

Published: 04/28/2026

Summary: The article explains how to deploy DNS Private Resolvers and Private DNS Zones for Azure AI-supported services within private networks. Private DNS Zones enable secure, internal domain resolution across global Azure VNets, while DNS Private Resolvers provide managed, regional DNS resolution between Azure and on-premises environments. It highlights the importance of linking VNets to DNS zones for name resolution and clarifies common misconceptions about VNet peering. The article includes a step-by-step end-to-end flow for DNS queries and emphasizes connectivity verification tools like PsPing. Public networks and DNS zones are mentioned but not discussed in detail.

AI-Powered Downtime Investigation for Azure VMs: Automating Root Cause Analysis

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 04/22/2026

Summary: The article describes how Microsoft Azure uses AI to automate and accelerate root cause analysis for virtual machine downtime. Leveraging the Model Context Protocol (MCP), the system automatically investigates incidents by querying live telemetry, analyzing logs, building recovery timelines, and generating structured reports. This reduces manual investigation time from up to an hour to under five minutes, ensures consistent, thorough analysis for every incident, and streamlines ownership assignment. The AI system encodes expert knowledge, allowing engineers to focus on decision-making rather than data gathering, significantly improving efficiency and incident response across Azure's infrastructure.

Designing Outbound Connectivity for "Private Subnets" in Azure

Team Blog: Core Infrastructure and Security

Author: alexeyn1

Published: 04/23/2026

Summary: Private subnets in Azure disable default outbound internet access, requiring architects to deliberately design outbound connectivity. Three main patterns exist: NAT Gateway for scalable, predictable egress; Azure Firewall for secure, governed, and audited flows; and Load Balancer Outbound for legacy scenarios. Each has strengths and limitations, with NAT Gateway suited for simple, high-scale egress, Azure Firewall for compliance and security, and Load Balancer for transitional or legacy architectures. The key principle is to choose the outbound method based on workload risk and requirements, ensuring intentional, documented, and governed internet access.

Running multimedia AI models on Container Apps with Serverless GPU (A100 & T4)

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 04/20/2026

Summary: The article guides users on deploying multimedia AI models, like ComfyUI, on Azure Container Apps using serverless GPU profiles (A100 & T4). It details infrastructure provisioning with Terraform, model downloading, and monitoring via Azure Log Analytics. Key notes cover storage setup, manual creation of GPU profiles, and protocol choices (SMB vs NFS). Cost optimization tips are provided by right-sizing resources. Users can run text-to-image and text-to-video workflows. The article includes disclaimers about the sample scripts' support and reliability, and highlights the need for manual steps due to Terraform limitations.

Announcing Private Preview: Deploy Ansible Playbooks using Azure Policy via Machine Configuration

Team Blog: Azure Arc

Author: alinetran

Published: 04/01/2026

Summary: Microsoft has announced a private preview allowing Ansible playbooks to be deployed via Azure Policy using Machine Configuration on Azure and Azure Arc-enabled Linux machines. This integration enables organizations to automate configuration management and compliance enforcement for Linux servers without needing an Ansible control node. The solution offers centralized policy-based governance, drift detection, and automatic remediation, with compliance results visible in Azure dashboards. This unifies management across Windows and Linux environments, whether in the cloud, on-premises, or at the edge, leveraging existing Ansible investments within Azure Arc’s unified security and compliance framework.

Automating Arc-enabled SQL Server license type configuration with Azure Policy

Team Blog: Azure Arc

Author: TomClaes

Published: 04/12/2026

Summary: The article explains how to automate the configuration of SQL Server license types on Azure Arc-enabled resources using Azure Policy. It details steps for deploying and assigning policies via PowerShell, automating remediation tasks, and handling role assignments. The approach supports both existing (brownfield) and new (greenfield) environments, ensuring compliance and enabling pay-as-you-go billing. The policy can standardize, migrate, or selectively update license types at scale, and includes mechanisms for recurring billing consent. Tools for monitoring compliance, such as KQL queries and Azure Workbooks, are also provided.

App attach in Azure Virtual Desktop now supports Windows Server 2025 and Windows Server 2022

Team Blog: Azure Virtual Desktop

Author: Michelle_Moya

Published: 04/16/2026

Summary: App attach in Azure Virtual Desktop now supports Windows Server 2025 and 2022, allowing dynamic delivery of MSIX, AppX, and App-V applications to session hosts without embedding them in base images. This reduces image sprawl, simplifies management, and enables continued use of existing App-V packages as support for App-V Server ends in April 2026. Organizations can more easily onboard and update applications, manage a single golden image, and benefit from streamlined app delivery, especially in Azure Virtual Desktop Hybrid environments. For more details, users are encouraged to consult the App attach documentation.

Announcing public preview of redundant TCP support for RDP Multipath for Azure Virtual Desktop

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 04/21/2026

Summary: Azure Virtual Desktop (AVD) now supports redundant TCP transport paths for RDP Multipath, available in public preview. This enhancement improves session resiliency by enabling multiple network paths—both UDP and TCP—for reliable connectivity, even in restrictive or UDP-restricted environments. If a connection path degrades or fails, AVD automatically switches to the next best route without user intervention, ensuring session continuity. The feature is enabled by default for host pools in the validation ring and is supported on Windows App version 2.0.1069.0 or later. Users can opt out if needed.

Update host keys to use SFTP on Azure Blob Storage

Team Blog: Azure PaaS

Author: LuisFilipe

Published: 04/28/2026

Summary: Azure Blob Storage users may receive alerts to update SFTP host keys, which are used to verify server identity for secure connections. To avoid disruptions, users should update their trusted hosts list with new host keys, either by pre-loading both current and next keys or by accepting the new key after rotation. The article provides guidance on listing SFTP-enabled storage accounts, identifying connected clients, and automating updates. Monitoring and diagnostic tools can help track SFTP connections, and users authenticating via SSH key must ensure their known_hosts file is updated to maintain uninterrupted access.

Leveraging Azure Resource Graph Queries for Azure Redis Configuration

Team Blog: Azure PaaS

Author: Soma_Sekhara_Raju

Published: 04/21/2026

Summary: The article outlines how Azure Resource Graph Explorer streamlines the review of Azure Redis configurations across subscriptions using Kusto Query Language (KQL). It details queries for SKU tier, Redis version, TLS settings, public network access, and Microsoft Entra authentication, offering rapid, centralized visibility without the need for custom scripts. This approach accelerates audits, supports security compliance, and simplifies management compared to traditional methods like PowerShell or Azure CLI. The same methodology can be applied to other Azure resource types by querying their schemas.

AI at every career stage (start, grow, lead)

Team Blog: Microsoft Learn

Author: AshleyMastersHall

Published: 04/28/2026

Summary: The article explores how AI can support professionals at every career stage, from newcomers to senior leaders. It provides practical examples of using AI tools like Microsoft Copilot to accelerate learning, streamline workflows, and enhance decision-making. Early-career individuals can use AI for onboarding and communication; midcareer professionals can scale impact and manage complexity; experienced leaders can leverage AI for strategy, coaching, and process improvement. The article also recommends Microsoft’s AI Skills Navigator for tailored AI skill development, emphasizing that it’s never too early or late to adopt AI in your career.

What’s new in AI Skills Navigator: April 2026

Team Blog: Microsoft Learn

Author: Priya_V

Published: 04/20/2026

Summary: The April 2026 update to AI Skills Navigator introduces improvements based on user feedback, including enhanced skilling playlists for clearer, scalable learning paths, and more flexible skilling sessions with better progress tracking and control for learners. The platform now features a directory for Microsoft Training Services Partners to support tailored, local training, and offers new certifications like AI Transformation Leader and AI Business Professional. All training and credentials are unified in one place, making it easier to build, track, and validate AI skills for individuals and organizations.

Azure VNet Data Gateway for Secure Power BI & Power Platform Access in Enterprises

Team Blog: Azure Networking

Author: kirankumar_manchiwar04

Published: 04/22/2026

Summary: The Azure VNet Data Gateway is a Microsoft-managed service that enables secure, private access to data sources for Power BI, Power Platform, and Microsoft Fabric without customer-managed infrastructure. Running within a delegated Azure Virtual Network subnet, it eliminates the need for VMs or manual maintenance, ensuring all data traffic stays on the Azure backbone. The gateway supports enterprise-scale deployments, enforces private-only connectivity, and aligns with Zero Trust and governance requirements, making it ideal for organizations prioritizing security and operational efficiency. Setup involves configuring the VNet, private endpoints, and integrating with Power Platform or Power BI.

A demonstration of Virtual Network TAP

Team Blog: Azure Networking

Author: Marc de Droog

Published: 04/15/2026

Summary: Azure Virtual Network Terminal Access Point (VTAP), in public preview as of April 2026, enables agentless, out-of-band copying of full network traffic (including payloads) from designated Azure VMs to traffic analytics tools or collectors, using VXLAN encapsulation. Unlike VNET Flow Logs, which only capture metadata, VTAP provides full packet capture without impacting VM performance. The article demonstrates VTAP’s functionality by capturing and analyzing traffic from a source VM to a destination VM running Wireshark. VTAP integrates with third-party security and analytics solutions available on the Azure Marketplace.

Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/30/2026

Summary: Microsoft Intune prioritizes and accelerates time-sensitive device updates, with 90% of actions completed in under an hour. Contrary to the “8-hour latency” myth, this delay applies only to routine maintenance check-ins, not critical updates. Intune uses notification-based, priority-driven processing to ensure high-impact actions like security and compliance changes are delivered quickly. Recent improvements focus on prioritization, resilience during bursts of changes, timely notifications, and optimized maintenance check-ins, enhancing speed and predictability for IT admins and security teams without requiring workflow changes.

Unpacking Endpoint Management is back - and we’ve got a lot to talk about

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/24/2026

Summary: "Unpacking Endpoint Management," a candid web series focused on practical strategies for managing and securing endpoints, is back with new episodes featuring Microsoft Intune experts and guest practitioners. Hosted by Danny Guillory and new co-host Rachelle Blanchard, the series offers live discussions, real-world insights, and answers to audience questions. Upcoming topics include policy transitions from hybrid to cloud-native. Episodes are streamed live on multiple platforms, and the community is encouraged to participate, submit questions, and suggest topics, ensuring content remains relevant and actionable for real-world endpoint management challenges.

Triggering Azure Functions from Blob Storage Using Event Grid

AndrewCoughlin — Mon, 11 May 2026 20:24:17 GMT

Overview

Modern workloads increasingly rely on reacting to files as soon as they arrive in Azure Blob Storage. While Azure provides multiple ways to trigger computing from blob operations, choosing the right event-driven pattern is not always straightforward—especially in enterprise environments where latency, reliability, and operational transparency all matter.

Introduction

Hello everyone, Andrew Coughlin here, a Cloud Solution Architect specializing in Infrastructure as a Service on Azure.

In this post, I am going to walk through how to implement a direct Event Grid to Azure Function pattern. This is the simplest and lowest-latency option when you want real-time reactions to blob uploads.

Scenario

Suppose you have a workload where files are continuously uploaded into Azure Blob Storage and you need to trigger downstream processing.

Typical requirements include avoiding polling, achieving near real-time execution, and maintaining strong observability.

Architecture

Blob Storage → Event Grid → Azure Function

The Process

Create and deploy the Azure Function
2. Validate the function
3. Create the Event Grid subscription
4. Upload a blob and validate the flow

Step 1 — Create and Deploy the Azure Function (Function First)

The Function must exist before creating the Event Grid subscription because Event Grid validates the endpoint during creation.

Steps:
1. Create a Function App (Consumption plan + storage account)
2. Open Function App → Functions → Create
3. Select Event Grid trigger
4. Provide function name
5. Create and save the function

Note: A storage account is required for all Function Apps and is created or selected during app creation.

Implement the Function

Below are examples of the HandleBlobCreatedEvent.cs, EventGridListenerFunction.csproj, Program.cs, and host.json

Example of HandleBlobCreatedEvents.cs:

namespace EventGridListenerFunction { public class HandleBlobCreatedEvent { private readonly ILogger _logger; public HandleBlobCreatedEvent(ILoggerFactory loggerFactory) { _logger = loggerFactory.CreateLogger<HandleBlobCreatedEvent>(); } [Function(nameof(HandleBlobCreatedEvent))] public void Run([EventGridTrigger] string data) { // Event Grid sends events as a JSON array using var doc = JsonDocument.Parse(data); if (doc.RootElement.ValueKind == JsonValueKind.Array) { foreach (var ev in doc.RootElement.EnumerateArray()) { HandleOneEvent(ev); } } else { HandleOneEvent(doc.RootElement); } } private void HandleOneEvent(JsonElement ev) { if (ev.TryGetProperty("eventType", out var eventType)) _logger.LogInformation("EventType: {EventType}", eventType.GetString()); if (ev.TryGetProperty("subject", out var subject)) _logger.LogInformation("Subject: {Subject}", subject.GetString()); if (ev.TryGetProperty("data", out var dataObj) && dataObj.ValueKind == JsonValueKind.Object && dataObj.TryGetProperty("url", out var urlProp)) { _logger.LogInformation("Blob URL: {Url}", urlProp.GetString()); } else { _logger.LogWarning("No data.url found in payload."); } } } }

Example of Program.cs:

var builder = FunctionsApplication.CreateBuilder(args); builder.ConfigureFunctionsWebApplication(); builder.Services .AddApplicationInsightsTelemetryWorkerService() .ConfigureFunctionsApplicationInsights(); builder.Build().Run();

Example of Host.json:

{ "version": "2.0", "logging": { "applicationInsights": { "samplingSettings": { "isEnabled": true, "excludedTypes": "Request" }, "enableLiveMetricsFilters": true } } }

Example of EventGridListenerFunction.csproj:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> <OutputType>Exe</OutputType> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.23.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.51.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="2.50.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.EventGrid" Version="3.5.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.7" /> </ItemGroup> </Project>

You will still need to publish this to the function app, which is outlined: Deployment technologies in Azure Functions | Microsoft Learn.

Step 2 — Create the Event Grid Subscription

Navigate to the Storage Account → Events → Create Event Subscription and select BlobCreated events targeting the Function.

Step 3 — Validate

Upload a blob and confirm the Function triggers and logs event data.

Common Pitfalls

Creating the subscription before the function exists
• Storage account misconfiguration
• Networking restrictions preventing Function access to storage

Conclusion

The direct Event Grid to Azure Function pattern provides a simple and reliable approach for real-time blob processing without additional infrastructure.

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.