rss.livelink.threads-in-node

Advanced Windows Firewall

OrinThomas — Sun, 30 Aug 2026 22:38:47 GMT

If you administer Windows, you’re already aware of Windows Firewall. You might use it to allow an application, open a port, or block unwanted inbound traffic. But those familiar tasks only scratch the surface of what it can do.

The Microsoft Learn module Understand advanced Windows Firewall takes you beyond basic rules and introduces Windows Firewall as a powerful platform for host-based segmentation, authenticated access, traffic protection, operational evidence, and incident response. In the module you'll learn about the following:

Rule creation and management

View effective, enabled rules in the ActiveStore.
Inspect the port, address, application, and service filters associated with a rule.
Create precisely scoped inbound rules for services such as HTTPS, WinRM, Remote Desktop, and WMI.
Enable, disable, modify, and remove existing rules with PowerShell.
Define a traffic contract before creating a rule.
Correctly distinguish local and remote ports and addresses.
Scope rules by protocol, port, address, application, service, profile, user, and computer.
Restrict rules to stable executable paths, Windows services, or packaged application identities.
Limit access to management subnets, jump hosts, privileged workstations, application tiers, and collectors.
Create consistent rule names and groups for ownership and automation.

Firewall profiles

Apply different policies to Domain, Private, and Public networks.
Enable the firewall and block unmatched inbound traffic on every profile.
Restrict administrative exceptions to the profiles that require them.
Inspect active network profiles and their default actions.
Design policies that remain secure during DNS, routing, domain-controller, or network-adapter failures.
Test how network failure states affect profile selection.

Host segmentation

Build a traffic matrix describing permitted communication between device and application tiers.
Implement default-deny inbound segmentation.
Block unnecessary workstation-to-workstation communication.
Preserve approved management, monitoring, application, recovery, and domain-member traffic.
Reduce lateral movement through controlled management paths.
Deliver firewall policy centrally through Group Policy.
Disable local firewall-rule merging.
Disable local connection-security-rule merging.
Stage enforcement through logging, discovery, pilots, and role-based deployment.
Define success criteria and maintain a tested rollback path.

IPsec and identity-based access

Design IPsec connection security rules for peer authentication.
Provide packet integrity, replay protection, and optional encryption.
Select Kerberos or certificate-based authentication for different trust scenarios.
Protect legacy plaintext applications without changing the application.
Coordinate secure firewall rules with compatible connection security rules.
Use request authentication during deployment before enforcing required authentication.
Correctly define IPsec endpoints and traffic selectors.
Require authenticated traffic before allowing access.
Authorize traffic by Active Directory user-group membership.
Require both an authorized user and an authorized managed computer.
Combine identity with network, service, application, and profile restrictions.
Create narrowly scoped authenticated bypass rules.
Design governed identity exceptions.
Validate both successful and denied authorization scenarios.

Outbound traffic control

Understand how stateful inspection permits response traffic.
Avoid unnecessary inbound rules for dynamic client ports.
Identify the dependencies required before introducing outbound default-deny.
Restrict administrative tools, service accounts, high-risk applications, and servers to approved destinations.
Account for dynamic cloud services, proxies, certificate endpoints, and content delivery networks.
Introduce outbound restrictions gradually through discovery, narrow allow rules, pilots, and monitoring.

Logging and evidence

Enable logging for dropped packets and successful connections.
Configure the log location and maximum size for every profile.
Verify effective logging settings.
Interpret firewall log fields such as action, protocol, address, port, interface, and direction.
Use observed traffic to discover application dependencies.
Distinguish observed traffic from authorized traffic.
Use dropped-packet records to confirm that traffic reached the host firewall.
Use successful-connection records to confirm firewall admission.
Forward firewall evidence to protected central storage.
Correlate firewall data with process, authentication, application, and network telemetry.

Troubleshooting

Follow a structured diagnostic sequence from the application listener through firewall and IPsec state.
Inspect the merged runtime policy rather than only an individual policy source.
Trace an effective rule back to Group Policy or another originating store.
Identify conflicting or overriding block rules.
Inspect active IPsec rules and main-mode and quick-mode security associations.
Diagnose authentication, trust, time, name-resolution, selector, and cryptographic mismatches.
Capture and interpret IPsec negotiation traffic on UDP ports 500 and 4500.
Differentiate firewall admission failures from application or identity failures.
Make controlled policy changes without disabling the firewall or creating unrestricted exceptions.

Windows Firewall might already be a familiar part of your Windows environment. This module will help you appreciate just how much security and diagnostic functionality is built into it—and how to apply that functionality with greater precision.

Start learning: Understand advanced Windows Firewall

Active Directory Domain Services modules on Microsoft Learn

OrinThomas — Tue, 01 Sep 2026 22:51:08 GMT

The following is a list of Active Directory Domain Services modules on Microsoft Learn sorted from introductory to advanced. Is there an Active Directory topic that isn't listed here that you'd like to see covered? (AD CS modules are coming).

If you know all this, remember we have the free 45 minute practical Active Directory administration test that gets you a validated Microsoft credential. You can take the test here https://aka.ms/ADDSAppliedSkillTest.

Introductory

1. Introduction to AD DS

URL: https://learn.microsoft.com/en-us/training/modules/introduction-to-ad-ds/
Assessment: BEGINNER

This module establishes the essential AD DS vocabulary and mental model. It introduces directory services, users, groups, computers, forests, domains, sites, domain controllers, and organizational units, then shows how directory objects and their properties are managed. It should come first because nearly every later module assumes familiarity with these structures and their relationships.

Intermediate

2. Create and manage Active Directory objects

URL: https://learn.microsoft.com/en-us/training/modules/create-manage-active-directory-objects/
Assessment: INTERMEDIATE

This module turns the foundational concepts into routine administrative skills. It covers users, groups, computers, organizational units, object properties, object creation and configuration, bulk user-account management, and basic domain controller maintenance. The module is the natural bridge from understanding AD DS to operating it.

3. Manage Active Directory Domain Services using PowerShell cmdlets

URL: https://learn.microsoft.com/en-us/training/modules/manage-active-directory-domain-services-use-powershell-cmdlets/
Assessment: INTERMEDIATE

This module applies PowerShell to the object-management tasks learned previously. It introduces cmdlets for creating and maintaining users, groups, group memberships, computers, organizational units, and other directory objects, giving learners a repeatable and scalable alternative to graphical administration. Prior PowerShell familiarity is expected.

4. Deploy and manage Active Directory Domain Services domain controllers

URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-active-directory-domain-services-domain-controllers/
Assessment: INTERMEDIATE

This module moves from directory objects to the servers that host the directory. It reviews forests and domains, explains domain controller topology, covers domain controller deployment and movement between sites, and introduces operations master roles. It provides the deployment context needed before studying domain controller maintenance and role placement in greater depth.

5. Manage AD DS domain controllers and FSMO roles

URL: https://learn.microsoft.com/en-us/training/modules/manage-active-directory-domain-services-flexible-single-master-operation-roles/
Assessment: INTERMEDIATE

This module deepens domain controller administration through deployment, maintenance, backup and recovery considerations, global catalog placement, Flexible Single Master Operations (FSMO) role placement and management, and an introduction to schema management. It builds on the preceding deployment module and prepares learners for later architecture, recovery, and design topics.

6. Implement Group Policy Objects

URL: https://learn.microsoft.com/en-us/training/modules/implement-group-policy-objects/
Assessment: INTERMEDIATE

This module introduces domain-based Group Policy Objects (GPOs), including scope, inheritance, creation, configuration, storage, administrative templates, and the Central Store. It should precede the other Group Policy modules because it explains both the logical processing model and the underlying storage components on which later policy and troubleshooting work depends.

7. Create and configure Group Policy Objects in Active Directory

URL: https://learn.microsoft.com/en-us/training/modules/create-configure-group-policy-objects-active-directory/
Assessment: INTERMEDIATE

This module reinforces GPO definition, scope, inheritance, and domain-based configuration, then extends those skills into domain password policy and fine-grained password policy. Although some content overlaps the preceding module, its identity-policy focus makes it a useful second step after learners understand GPO storage, templates, and general processing.

8. Manage security in Active Directory

URL: https://learn.microsoft.com/en-us/training/modules/manage-security-active-directory/
Assessment: INTERMEDIATE

This module addresses practical directory hardening through user rights, access restrictions, delegated permissions, the Protected Users group, Windows Defender Credential Guard, NTLM blocking, and identification of problematic accounts. It connects identity administration and Group Policy knowledge to least-privilege operations and modern credential protection.

9. Implement and manage Active Directory Certificate Services

URL: https://learn.microsoft.com/en-us/training/modules/implement-manage-active-directory-certificate-services/
Assessment: INTERMEDIATE

This module introduces public key infrastructure and Active Directory Certificate Services (AD CS), including certification authority types, AD CS design and implementation, certificate enrollment, revocation, and trust. It belongs after core directory security because certificates extend AD-based authentication and authorization into a broader trust infrastructure.

Advanced

10. Understand Active Directory Group Policy security settings

URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-security-policies/
Assessment: ADVANCED

This module provides an in-depth treatment of security policy design and operation at scale. It covers password, lockout, and Kerberos account policies; fine-grained password policies; user rights; security options; auditing; secured groups, services, registry keys, files, and logs; network and application policies; and Windows Server 2025 OSConfig baselines. Its assumptions about GPO processing, security identifiers, access tokens, ACLs, Kerberos, and NTLM make it the bridge from practical GPO administration to protocol-level authentication hardening.

11. Active Directory Domain Services authentication and Kerberos hardening

URL: https://learn.microsoft.com/en-us/training/modules/active-directory-authentication-kerberos/
Assessment: ADVANCED

This module examines Windows authentication end to end, explaining how SSPI, Negotiate, NTLM, and Kerberos interact and tracing Kerberos from Ticket Granting Ticket issuance through service-ticket presentation and authorization. It covers diagnosis of Service Principal Name, delegation, Privilege Attribute Certificate, encryption-type, and NTLM fallback problems; staged migration from NTLM to Kerberos; RC4 auditing and remediation for Windows Server 2025; and planning for PKINIT agility, Kerberos encryption policy, SMB NTLM blocking, and password-change hardening. It caps the security stage because it requires learners to combine policy, identity, logging, and authentication-protocol knowledge.

12. Understand how Active Directory Domain Services uses DNS

URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-domain-name-system/
Assessment: ADVANCED

This module explains and diagnoses the DNS mechanisms on which AD DS depends. It traces service discovery and domain controller location through SRV records, LDAP ping, site selection, and caching, and examines AD-integrated zones, application directory partitions, secure dynamic updates, registration, replication convergence, baselining, and failure recovery. This knowledge is essential before designing or troubleshooting site topology and replication.

13. Active Directory sites, topology, and replication

URL: https://learn.microsoft.com/en-us/training/modules/active-directory-site-replication/
Assessment: ADVANCED

This module develops a detailed model of sites, subnets, site links, costs, bridgeheads, connection objects, the Knowledge Consistency Checker (KCC), and the Inter-Site Topology Generator (ISTG). It also covers DC Locator behavior, topology anti-patterns, update sequence numbers, replication vectors, object metadata, replication failure diagnosis, and the Windows Server 2025 replication priority boost. The module supplies the replication foundation needed for the deeper storage and design modules that follow.

14. Understand the Active Directory Domain Services database and SYSVOL

URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-database/
Assessment: ADVANCED

This module explains how a domain controller stores and replicates directory data and SYSVOL through separate mechanisms. It distinguishes the logical directory from the local ESE database and directory partitions, traces transactional writes and logical AD DS replication, explains SYSVOL access and DFS Replication, follows a GPO across its directory and file-system components, and defines safe backup, recovery, virtualization, and version boundaries. It is especially useful for diagnosing whether a failure lies in directory data, SYSVOL, replication, or client access.

15. Understand the Active Directory Domain Services Schema

URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-schema/
Assessment: ADVANCED

This module examines the forest-wide schema that defines directory object classes, attributes, syntax, inheritance, links, identifiers, search behavior, security metadata, and global catalog content. It covers safe inspection, schema versions, governance, extension design and deployment, indexing and replication effects, access control, and schema-related troubleshooting. The topic is advanced because schema changes are forest-wide, effectively permanent, and demand disciplined testing and change control.

16. Design a single-domain Active Directory forest

URL: https://learn.microsoft.com/en-us/training/modules/design-single-domain-active-directory-forest/
Assessment: ADVANCED

This module combines the preceding operational knowledge into a resilient single-domain forest design. It covers durable DNS and UPN namespaces, AD-integrated DNS, sites, subnets, site links, replication convergence and failure behavior, and placement of domain controllers, DNS servers, global catalogs, FSMO roles, and the authoritative time source. Learners also validate designs against objective evidence and failure scenarios.

17. Design a multi-domain or multi-forest Active Directory environment

URL: https://learn.microsoft.com/en-us/training/modules/design-multi-domain-forest-trust/
Assessment: ADVANCED

This module extends single-domain design to scenarios requiring security isolation, legal separation, administrative autonomy, mergers, or replication boundaries. It addresses domain trees and partitions, namespace coexistence, delegation, GPO scope, schema governance, trust direction and security, cross-forest name resolution, global catalog and authentication paths, advanced replication and capacity, and read-only domain controller branch designs. It should follow single-domain design because additional domains and forests introduce complexity that must be justified.

18. Manage advanced features of AD DS

URL: https://learn.microsoft.com/en-us/training/modules/manage-advanced-features-of-ad-ds/
Assessment: ADVANCED

This module brings together several specialized administration scenarios: creating trust relationships, implementing Enhanced Security Administrative Environment (ESAE) forests, monitoring and troubleshooting replication, and creating custom AD DS partitions. These tasks rely on a mature understanding of forest boundaries, trusts, security, partitions, and replication, so they are best approached after both architecture modules.

19. Deploy and manage Azure IaaS Active Directory domain controllers in Azure

URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-azure-iaas-active-directory-domain-controllers-azure/
Assessment: ADVANCED

This module applies established AD DS administration to Azure infrastructure. It compares directory and identity service options, prepares Azure virtual networking for domain controllers, deploys and configures AD DS on Azure virtual machines, installs a replica domain controller, and creates a new forest on an Azure virtual network. The broad prerequisites in on-premises AD DS, Azure IaaS, networking, resiliency, security, PowerShell, automation, and monitoring make this advanced in the proposed path.

20. Active Directory Domain Services migration

URL: https://learn.microsoft.com/en-us/training/modules/active-directory-domain-services-migration/
Assessment: ADVANCED

This module evaluates how to move an existing AD DS environment to Windows Server 2025. It compares in-place forest upgrade with migration to a new forest, then outlines the process for each approach. Although concise, migration is placed late because selecting and executing a safe strategy requires solid knowledge of domain controllers, operations roles, DNS, replication, security, architecture, recovery, and change management.

21. Troubleshoot Active Directory

URL: https://learn.microsoft.com/en-us/training/modules/troubleshoot-active-directory/
Assessment: ADVANCED

This module provides broad recovery and troubleshooting coverage for AD DS failures and degraded performance. It addresses restoring deleted objects with the AD Recycle Bin, recovering the AD DS database and SYSVOL, troubleshooting replication, and diagnosing hybrid authentication issues. The potential impact of recovery operations and the need to correlate several directory subsystems make this an advanced operational module despite its relatively compact scope.

22. Troubleshoot Active Directory Domain Services replication

URL: https://learn.microsoft.com/en-us/training/modules/troubleshoot-active-directory-replication/
Assessment: ADVANCED

This module develops a disciplined process for diagnosing replication failures with Repadmin, DCDiag, PowerShell, and event logs. It teaches learners to distinguish true failures from expected latency or transient topology states, isolate DNS, network, authentication, topology, and domain controller health dependencies, recognize data-consistency risks, apply a targeted correction or escalate safely, and verify convergence and the original business symptom. This diagnostic discipline should precede advanced recovery so learners can distinguish a correctable replication fault from a broader consistency failure that warrants restoration.

23. Advanced Active Directory back up and recovery

URL: https://learn.microsoft.com/en-us/training/modules/active-directory-backup-recovery/
Assessment: ADVANCED

This module treats AD DS backup and recovery as Tier 0 architecture and incident response rather than a single restore operation. It covers backup design around recovery time and recovery point objectives, topology, retention, and trust boundaries; evidence-based backup validation; selection of object, domain controller, domain, or forest recovery scope; recovery of objects, attributes, hierarchies, DNS, and SYSVOL; domain and forest sequencing involving FSMO roles, RID state, global catalogs, and trusts; safe virtualized domain controller recovery; and comprehensive validation before reconnection. It is the final capstone because safe recovery requires the learner to integrate nearly every preceding topic while making high-impact decisions under controlled change and security processes.

Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design

Pierre_Roman — Thu, 13 Aug 2026 07:00:00 GMT

Hello Folks!

Operating at Azure scale means managing change across multiple interconnected systems. As applications, services, and dependencies evolve, resilience becomes a foundational design principle rather than an afterthought. In this Microsoft Azure Infra Summit 2026 session, Bhavana Konchada, Principal Software Engineer at Microsoft and lead architect of the Resilience Control Platform, takes us behind the scenes of a production-grade resilience platform built on Azure and explains the engineering choices that helped bring it to life.

Why IT Pros Should Care

Most of us have shipped a system that worked beautifully on day one and then quietly fell apart the first time something downstream blinked. Bhavana’s session is a brutally honest tour of the decisions you make early that determine whether your platform survives reality. Here’s what you walk away with:

A pragmatic blueprint for service boundaries that you can actually operate at 2 a.m.
Concrete Durable Functions patterns (Monitor, continue-as-new, idempotency) that keep long-running workflows healthy.
A Cosmos DB partitioning strategy grounded in real access patterns, not gut feel.
A multi-region, fail-and-continue mindset (instead of fail-and-recover) that holds up when a region disappears.
Real lessons from production, including the “non-deterministic orchestration” outages nobody warns you about.

In short, if you build, run, or modernize platforms on Azure, this session reshapes how you think about reliability.

What DR by Design Actually Means, a Technical Overview

Bhavana frames the Resilience Control Platform as five chapters: architecture and service boundaries, orchestration with Durable Functions, the Cosmos DB data layer, identity across multiple user realms, and the resilience playbook itself.

The platform has four moving parts:

A portal where operators define and monitor scenarios.
An orchestration engine that executes long-running workflows.
Cosmos DB as a shared persistence layer.
Downstream infrastructure APIs the engine acts on.

The big “DR by Design” idea is that resiliency isn’t bolted on later. It’s a property of every choice from boundaries upward. As Bhavana puts it, you stop designing for “fail and recover” and start designing for “fail and continue.” Users don’t know (or care) which region runs their workflow; they just need it to run reliably, consistently, and without interruption.

How It Works, Under the Hood

Bhavana’s team made several deliberate design moves worth borrowing.

Arm’s-length service boundaries. Version one had the portal and orchestration engine tightly coupled with shared dependency injection and a shared database context. It felt clean until they tried to operate it. Now the two services talk over REST contracts, each with its own dependencies. Yes, that means a bit of duplicated code. What they gained, independent deployments, isolated failures, and clear ownership, more than paid for it.

The right runtime for the workload. The portal is a session-driven web app, so it lives on App Service. The orchestration engine bursts on demand and runs workflows for minutes (sometimes hours), so it’s built on Durable Functions. Forcing both into one model would have looked simpler on paper and been worse in practice.

Accept Fast, Process Asynchronously. Clicking Execute returns a 202 immediately. The orchestrator does the heavy lifting in the background and updates status in Cosmos DB. The portal just reflects progress. Users never wait on long workflows.

Durable Functions patterns that actually scale. Three lessons stood out:

The Monitor pattern replaces busy polling with durable timers. The orchestrator wakes up, checks status, and goes back to sleep without holding compute.
Orchestrators are state machines, not scripts. Calling DateTime.UtcNow inside an orchestrator produces non-deterministic replay and random production failures. The fix is to use the orchestration context for time and IDs.
Continue-as-new keeps replay history bounded. Long-running orchestrations otherwise spend more time replaying history than doing real work.

Cosmos DB designed around access, not org charts. Partitioning by tenant feels logical and creates hotspots the moment one tenant gets busy. The team partitions by entity (each plan owns its partition) and uses hierarchical keys combining plan ID and execution ID. They also lean on TTL for data lifecycle so completed records expire automatically, no cleanup jobs required.

Identity as an execution boundary. Corporate users authenticate through Microsoft Entra with OpenID Connect. Operations users come in through a federated WS-Federation system. Instead of forking the app, the team built home realm discovery at the front door, normalized everything into a single identity model behind it, and added custom middleware in the Azure Functions isolated worker model to extract, validate, enrich, and fail-fast on every token. Authorization is config-driven so every endpoint gets the same treatment.

Multi-region from day one. The full stack (portal, engine, APIs, supporting services) runs in parallel across regions, fronted by Azure Front Door as the global entry point. Health probes drive automatic regional failover with no human in the loop.

Cosmos DB single-write with automatic failover. Multi-write looks attractive on a slide and introduces real conflict-resolution complexity. The team chose one primary write region plus a replica with automatic failover. The Cosmos SDK detects region unavailability and routes requests to the promoted region without application code changes.

Idempotency from day zero. Once you have retries (and Front Door, the SDK, and your clients all retry), every operation has to be safe to run more than once. Client-provided IDs, Cosmos conflict detection (a 409 means “already succeeded”), and idempotent orchestration events make sure the same outcome lands no matter how many times a signal arrives.

Real-World Value, Use Cases, ROI, Scenarios

What does this buy you in practice?

Scenario validation under stress without compromising production. The platform is built to proactively validate and govern system behavior at scale.
Long-running workflows that survive everything. Host restarts, transient downstream errors, regional failovers, none of them lose work in flight.
Predictable cost. Durable timers and continue-as-new mean you stop paying for compute that’s only waiting.
Operability at scale. Independent services, clean contracts, and centralized identity all mean a smaller cognitive load when something breaks at 2 a.m.
Honest tradeoffs. Single-write Cosmos loses theoretical write latency in the second region and gains predictable behavior, no conflict ambiguity, and far easier debugging during failovers. That’s usually the right trade.

In short, the platform behaves the same on a quiet Tuesday and during a regional outage. That’s the whole point.

Getting Started

You don’t need to build the Resilience Control Platform tomorrow. You can start applying these patterns this week.

Map your service boundaries honestly. If two services share a DI container or database context, decouple them behind a REST contract.
Pick runtimes by workload, not by consistency. Interactive UI on App Service; long-running orchestrations on Durable Functions.
Adopt the 202-Accepted pattern for anything that could take more than a couple of seconds.
Audit your Durable orchestrators for DateTime.UtcNow, Guid.NewGuid, and direct HTTP calls. Move them into activities, use the orchestration context for time and IDs, and apply continue-as-new on long loops.
Revisit your Cosmos partition keys against actual access patterns and enable TTL for transient data.
Stand up a second region behind Azure Front Door, enable Cosmos DB automatic failover, and make every write operation idempotent with client-provided IDs.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Container Network Insights Agent (CNIA): Your AI Teammate for AKS Networking Incidents

Pierre_Roman — Wed, 12 Aug 2026 07:00:00 GMT

Hello Folks!

If you run AKS in production, you already know the script. A pod cannot reach an external service, every dashboard says the cluster is healthy, and somebody is SSHing into a node with five browser tabs open trying to piece the story together. This session from the Microsoft Azure Infra Summit 2026 tackles that exact pain.

Shaifali Garg (PM for Azure Container Networking on AKS) sits down with Jonathan Wang, an AKS operator running 30 clusters across two regions on Cilium, and they walk through what a real networking incident feels like, then introduce the Container Network Insights Agent (CNIA) live in the cluster.

Why IT Pros Should Care

In Jonathan’s environment, about 40% of incidents end up being networking problems. The tools all exist (kubectl, dashboards, detectors, Hubble), but the time sink is figuring out which layer the problem lives in and what to check next. CNIA goes after that gap. Here is what you actually get back:

A symptom-to-classification jump in seconds, so you skip the first 30 minutes of “is this DNS, policy, node, or app?”
One chat window with one evidence table, one root cause, and one copy-paste fix command, instead of jumping across five tabs
Senior SRE tribal knowledge baked into the workflow, so anyone on the team can run the same investigation a principal engineer would
Read-only by design, so the agent never changes anything on your cluster. You stay the human in the loop
Installs as an AKS extension (no Helm chart, no YAML to babysit), and Azure handles the lifecycle

In short, CNIA is not trying to replace your SRE team. It hands them back 20 or 30 minutes on every networking ticket, which adds up fast across a fleet.

What CNIA Is, A Technical Overview

Think of CNIA as an AI teammate that lives inside your AKS cluster as a pod. You describe what is broken in plain English, the way you would ping a senior engineer on Slack, and behind the scenes the agent does four things in order. It classifies the kind of problem (DNS, egress, policy, node, app), it pulls live evidence from your cluster, it analyzes that evidence, and it hands you back a clean report with evidence, root cause, and a copy-paste exec command.

Two architectural choices stand out. First, the agent uses your own Azure OpenAI resource (bring your own), so prompts and diagnostic content stay in your tenant and your region. Microsoft does not see your diagnostic data, and nothing gets persisted externally. Second, the answer is grounded in evidence pulled from your cluster, not from the internet. Your pods, your policies, your CoreDNS, your host-level NIC and kernel counters. If the evidence is inconclusive, CNIA says so rather than fabricating a root cause. That last bit is what earns trust with senior SREs.

CNIA fits inside the broader Advanced Container Networking Services (ACNS) story on AKS. ACNS gives you metrics in Azure Managed Prometheus and Grafana, stored and on-demand network logs with Hubble, and FQDN-based filtering with Cilium. CNIA sits on top, automating the triage loop across those signals so you do not have to walk through the playbook by hand every time.

How It Works, Under the Hood

The install is an AKS extension. Roughly 5 to 7 minutes from “az aks extension” to “you have an SRE buddy in your cluster.” One small pod runs continuously. A second helper only spins up on the node during a deep packet-drop investigation, reads host-level network counters, and is cleaned up right after. Nothing left behind.

Permissions are deliberately narrow:

Read-only RBAC on the cluster. The agent looks, it never changes anything
A workload identity tied to your Azure OpenAI resource. No shared credentials
Outbound traffic is HTTPS to your OpenAI endpoint on port 443, and nothing else. If you want to log that further through an NSG or firewall, that is supported

On the safety side, CNIA layers two protections against prompt injection. The agent is scope-restricted by design, so off-topic requests get rejected straight away. In one of Jonathan’s demos, Shefali asks the agent to “delete core-dns” and to “write a script to scrape LinkedIn profiles.” Both are refused on the spot. The second layer is the read-only RBAC at the cluster level. Even if someone tricked the prompt into emitting a destructive command, the cluster itself would refuse. The pod’s execution is scoped to specific diagnostic commands. It is not an open shell.

Honest tradeoffs, because you will ask:

It is one cluster at a time. Multi-cluster correlation is not in scope yet
It does not auto-remediate. It tells you the fix, you verify and run it
It is AKS only. EKS and GKE are not supported today
Session state lives in the pod in memory. If the pod restarts, you start a fresh chat (past sessions are still available in history)
Heavy packet-drop investigations have been validated up to around 7 concurrent users on smaller clusters. The team is actively scaling that up

Real-World Value

The session includes two demos that map directly to incidents you have probably lived through.

Demo 1, egress that silently dies. Pods cannot reach google.com. CoreDNS resolves it fine, example.com works from the same pod, every dashboard says healthy. CNIA classifies it as an egress connectivity problem (not DNS) and surfaces the actual culprit: a Cilium network policy named “restrict external FQDN” with a toFQDN rule that only allows example.com. Everything else gets silently dropped at the egress gate. DNS was allowed, the TCP connection was not. The fix command (a kubectl patch to add google.com to the allow list) is right there in the report. End-to-end fix in under a minute.

Demo 2, the target port typo. A service is down with connection refused. Pods running, service exists, endpoints populated, no network policies. The agent goes inside the pod, looks at the actual listening sockets, and proves the mismatch: target port 8080, but nginx listens on port 80. One-digit typo in YAML that no kubectl get would surface on its own.

The ROI math is straightforward. If your team handles networking incidents weekly and each one costs 20 to 30 minutes of “where do I even start,” that capacity adds up across the org. And critically, the win is not just speed. When the one engineer who knows where to look goes on leave, the rest of the team is no longer stuck calling them at home.

Getting Started

Three steps. That is it.

Read the public docs, get an overview, scan the use cases, and understand what CNIA does and does not cover
Pick a cluster (dev or staging is a great place to start) and install the AKS extension. Give it 5 to 7 minutes
Run a few real network tickets through it. Compare your time-to-answer before and after. Hit thumbs-up or thumbs-down in the chat so the product team sees real signal

Pricing in preview: no license fee. You pay for the Azure OpenAI tokens it uses (your tenant, your resource), plus the tiny bit of cluster compute for the pod. If you already have Azure OpenAI in your tenant, just point CNIA at it.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki

Cheers!

Pierre Roman

Operating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads

Pierre_Roman — Tue, 11 Aug 2026 07:00:00 GMT

Hello Folks!

If you have ever inherited a sprawling Azure environment and quietly wondered whether every VM, database, AKS cluster, and storage account in it is actually being backed up the way the business thinks it is, you are in good company.

In session this session of the Microsoft Azure Infra Summit 2026, Bhavya Tadikonda and Shobhit Garg from the Azure Resiliency product team walked us through how Azure Backup is evolving into a unified, application-centric service that protects IaaS, PaaS, AKS, PostgreSQL, and unstructured storage from a single pane of glass.

Why IT Pros Should Care

Backup is one of those topics nobody talks about until the day it really matters. Then it is the only topic. The session framed Azure Resiliency around three pillars (infrastructure resiliency, data resiliency, and cyber recovery), and Azure Backup sits squarely in the middle of the last two. The reason this session lands hard for ops teams is that the surface area we are expected to protect keeps growing: VMs, SQL on Azure VMs, SAP HANA, Sybase, AKS, PostgreSQL flexible servers, Azure Files, blobs, ADLS, and on it goes.

Here is why this should matter to you:

One vault model now protects IaaS, PaaS, AKS, PostgreSQL flexible server, and storage workloads, with consistent policies and reporting.
Cyber resiliency is built into the vault layer with immutability, soft delete, and multi-user authorization, so backups themselves can survive a ransomware event.
A new threat detection preview (powered by Microsoft Defender for Cloud) scans restore points and tags them healthy or suspicious before you recover.
Azure Backup for AKS protects cluster resources and persistent volumes with granular restores and immutable recovery points.
You can configure backups from VS Code through the Azure MCP server using natural language prompts, which is genuinely useful when you are protecting dozens of resources.

In short, fewer point tools, fewer scripts, and a much better chance of actually meeting your RPO and RTO targets when the day comes.

What Operating Azure Backup at Scale Means, a Technical Overview

The session opened with a quick reminder that resiliency in Azure stands on three pillars working together. Infrastructure resiliency keeps the underlying VMs, zones, and networks alive. Data resiliency keeps your data intact, available, and recoverable. Cyber recovery assumes the worst (a ransomware attack or insider event) and gives you air-gapped, immutable backups plus isolated recovery to restore safely.

Azure Backup is the connective tissue across data resiliency and cyber recovery. At the data layer, it offers snapshot tier backups for instant operational recovery (with up to a four-hour RPO), vault tier backups for long-term retention, and an archive tier for cold compliance storage. For databases, you get database-aware protection for SQL Server in Azure VMs, SAP HANA, and SAP ASE (Sybase), with point-in-time restore and log backups as frequent as every 15 minutes. That gets you to an RPO as low as 15 minutes for SQL, which is a number most IT pros will recognise as good enough for the vast majority of business apps.

At the vault layer, three security primitives stack together: soft delete (deleted backups are kept for an additional retention window), immutability (no operation can shorten retention or destroy recovery points before expiry), and multi-user authorization (critical operations need approval from a second admin via a Resource Guard). These are not bolt-ons. They are baked into Recovery Services vaults and Backup vaults.

How It Works, Under the Hood

The session followed a Contoso scenario where John, a cloud architect, configures backup for an application VM and a database VM. He picks a Recovery Services vault, creates a backup policy, and defines frequency and retention based on his RTO and RPO requirements. For the Linux application tier, John enables the new agentless, crash-consistent backup, which is non-invasive and protects performance-sensitive workloads without an in-guest agent.

For the database tier, John enables Azure Backup for SQL in Azure VMs. The service auto-discovers all databases inside the VM, removes the manual config dance, and lets him layer log backups, differential backups, and archival retention. For SQL Always On, HANA HSR, and Sybase HA clusters, snapshot-based acceleration gives him faster backups and instant restores.

Then John turns to cyber resiliency. From vault properties he reviews soft delete, immutability, and multi-user authorization, then enables the new threat detection preview. This integration with Microsoft Defender for Cloud scans restore points for malware so you can confirm a recovery point is clean before you roll back. Inside the protected items view, each restore point is marked healthy or suspicious, which is exactly the signal you want during an incident response.

For PaaS and cloud-native, Shobhit took over and walked through Azure Backup for AKS and Azure Backup for PostgreSQL flexible server. AKS protection covers the cluster resources, the persistent volumes, and the namespaces, with automated scheduled backups, granular restores, immutable recovery points, and flexible retention. PostgreSQL flexible server gets vaulted backups with long-term retention plus a unified view for monitoring and alerts.

The piece that made the room sit up was the demo of configuring backup from VS Code using the Azure MCP server. John installs the Azure MCP extension, validates mcp.json, opens the chat window, and starts the MCP server. He prompts it to list unprotected AKS clusters in his subscription, then asks it to configure backup for a specific cluster. The MCP server reuses an existing vault and policy, creates the protected item, and applies the enterprise security defaults. That is the kind of conversational ops experience that scales nicely when you have hundreds of resources.

For unstructured data, Azure Backup brings file shares, ADLS data, application artifacts, and large object stores into the same vault-based model, with off-site protection, long-term retention, immutability, soft delete, and MUA applied consistently.

Real-World Value

So where does the ROI show up? A few honest scenarios:

Ransomware attack on production VMs. With immutability and MUA, even a compromised admin account cannot destroy your recovery points. With threat detection, you avoid restoring an infected snapshot.
Accidental deletion of an AKS namespace. Granular AKS backup gets you a controlled, application-aware restore without redeploying the whole cluster.
Compliance audit on a regulated workload. Vault tier plus archive tier gives you the retention you need without inflating hot storage costs.
A cloud architect onboarding 30 new VMs and 10 PostgreSQL servers. Using Azure MCP from VS Code, they can configure backup conversationally instead of click-clicking through portal blades.
A BCDR drill. The resiliency agent (powered by Azure Copilot) can recommend enabling Azure Site Recovery on top of Azure Backup for stricter RTO and RPO, then guide you through enabling it.

Honest tradeoff: threat detection is in preview, agentless crash-consistent backup is newer than the in-guest variant, and multi-user authorization requires a Resource Guard that lives in a separate subscription (ideally a separate tenant). That is extra setup work, but it is the right design for separation of duties.

Getting Started

Concrete first steps you can take this week:

Open Backup Center (or the new Resiliency in Azure experience) and inventory what is already protected versus exposed.
Pick one Recovery Services vault and turn on enhanced soft delete with a meaningful retention period, then make it AlwaysOn for production.
Stand up a Resource Guard in a separate subscription or tenant and wire up MUA on your most critical vault.
For a non-production AKS cluster, install the Backup extension and protect a namespace end to end, including a test restore.
Try the Azure MCP server from VS Code to list unprotected resources and configure backup with a prompt.
If you run SQL on Azure VMs, enable log backups every 15 minutes on one database and validate a point-in-time restore.

Resources

Azure Backup documentation (official docs for vaults, policies, and workload protection)
Configure Multi-user authorization using Resource Guard (separation of duties for critical backup operations)
Threat detection in Azure Backup with Microsoft Defender for Cloud (preview) (healthy or suspicious tagging for VM restore points)
Back up Azure Kubernetes Service by using Azure Backup (cluster resources, namespaces, and persistent volumes)
Azure Backup for PostgreSQL flexible server (vaulted backups with long-term retention)
Azure Site Recovery documentation (DR replication on top of Azure Backup)

Keep Learning...

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre

Zonal Resiliency in Azure: Application-Centric Goals, Recovery Plans, and Drills

Pierre_Roman — Thu, 06 Aug 2026 07:00:00 GMT

Hello Folks

If you have ever stared at a multi-tier app in Azure and asked yourself, “Is this actually going to survive a zone outage?”, you are not alone. In session MAIS23 of the Microsoft Azure Infra Summit 2026, Bhavya, Aditya, and Chaya from the Azure Resiliency product team walked us through the new Resiliency in Azure experiences (formerly Azure Business Continuity Center) and showed how to stop treating resiliency as a per-resource checkbox and start treating it as an application-level outcome.

Why IT Pros Should Care

Most of us have lived this story. An app is “in the cloud”, spread across IaaS VMs, PaaS databases, an app service plan, and a shared Azure Firewall managed by some other team. Then a zonal blip hits, and suddenly nobody can answer the simple question: was this app supposed to be zone resilient or not?

The session opened with a customer scenario called Zava, a fast-growing insurance company running a claims app at 99.9 percent availability that just lost more than $40,000 in revenue in one week because of zonal outages. That is the price tag the speakers put on the problem, and it lines up with the patterns I see every week.

Here is why this matters to IT pros:

You finally get a single pane to see zonal resiliency posture across IaaS, PaaS, and shared services.
Resiliency goals are set at the application level, not buried inside each resource blade.
You get tailored Azure Advisor recommendations plus an Azure Copilot guided flow that emits remediation scripts.
You can run zone-down drills powered by Azure Chaos Studio without stitching together five different tools.
Recovery plans orchestrate failover in a defined order, with on-demand readiness checks before the next real outage.

In short, less guessing, less spreadsheet bookkeeping, and a lot more confidence that the app will behave the way you told the business it would.

What Resiliency in Azure Does, a Technical Overview

The team has rebranded Azure Business Continuity Center to Resiliency in Azure. It is a unified solution that covers infra, data, and cyber resiliency in one place. Today the focus is zonal resiliency, with regional disaster recovery (and proper RPO/RTO goals) on the roadmap.

The central concept is the service group. A service group is a logical application unit that can span subscriptions and resource groups. You add the VMs, databases, app service plans, Redis caches, and other Azure resources that make up an application, and from that point on, resiliency operations work against the whole app, not one resource at a time.

There are two views you will spend most of your time in:

Resource resiliency, a zonal configuration summary across the (roughly 20) resource types supported today.
Service group resiliency, the same summary but pivoted to the application level, so you can prioritize the apps that need attention first.

The speakers were honest about scope. Goals today are a simple intent (“this service group should be evaluated for zonal resilience”). Once additional pillars like regional DR ship, goals will expand to include RPO and RTO targets. I appreciate that they did not oversell it.

How It Works, Under the Hood

Once a service group exists, the workflow has three big building blocks. Each one solves a problem I bet you have hit.

Goals and recommendations. You assign a zonal resiliency goal to the service group, and Azure Advisor surfaces tailored recommendations for the resources inside it. Two details I liked:

The view shows cost implications before you flip the switch. Some Azure services have no cost delta for zone redundancy. Others do. You see it inline, not in a separate calculator tab.
There is an Azure Copilot guided remediation flow that walks you through the recommendation and, at the end, emits a script. That script accounts for resource-type corner cases (SKU changes, redeploys, and so on) and is meant to be run through your automation pipeline.

You can also exclude a resource with a reason (“not critical, zonal redundancy not required”) or manually attest a resource when your own custom solution already provides resiliency that the platform cannot auto-detect. That escape hatch is important, because real environments always have a few weird cases.

Application-centric recovery plans. Instead of failing over one resource at a time, a recovery plan orchestrates the entire app. It auto-detects existing solutions (Azure Site Recovery for VMs, for example), lets you group and order the resources for failover, and excludes resources that are already configured for high availability (no point failing them over if they did not go down). You can run an on-demand readiness check any time the app structure changes, so you find configuration drift before an outage finds it for you.
Zone-down drills powered by Azure Chaos Studio. A zone-down drill template identifies the service group resources, pre-populates the right native faults per resource type (think a Redis cache fault, a VM scale set shutdown, and so on), bundles in identity and permission checks, monitoring, and the recovery plan you already built. When you execute, you pick the region and the target zone, the drill runs a pre-validation check, injects the fault, runs failover, then reprotection and failback, and tracks all of it as a single job in the execution report. Per-resource metrics let you visualize the actual downtime each component experienced. If a native fault is not what you want, you can override with a custom runbook.

That last point is the part I think a lot of folks miss. A drill is not just fault injection. It is fault injection plus failover plus reprotection plus failback, all measured and attestable in one place.

Real-World Value

Back to Zava. They needed to answer three questions: what is our current zonal resiliency posture across these Azure services, what should we prioritize against our 99.9 percent target, and how do we validate that we will actually perform during an outage? Resiliency in Azure answers all three without forcing the platform team to write a 200-line PowerShell script.

Use cases that should be on your shortlist:

Regulated workloads (insurance, healthcare, financial services) that need to evidence drills for compliance. The notes and manual attestation features were clearly designed with auditors in mind.
Apps with mixed estates, where a central platform team owns shared services (firewalls, identity) and app teams own everything else. Service groups can be parented to mirror that org structure.
Apps with custom resiliency solutions that the platform cannot detect. Manual attestation keeps the dashboard honest without forcing you to refactor.
Game-day rehearsals. The pre-built zone-down template means you can run a meaningful drill in an afternoon instead of standing up a custom Chaos Studio experiment from scratch.

The honest tradeoff: zone redundancy is not free for every service, and not every resource type is in scope yet (around 20 today). Plan accordingly, exclude what is not critical, and attest what is covered by something else.

Getting Started

Here is the path I would take on a Monday morning:

Open the Azure portal and search for Resiliency. You will land on the Resiliency in Azure page that replaces the old Business Continuity Center.
Create a service group. Add resources directly, or add resource groups if each resource group is already an application boundary in your environment.
Assign the zonal resiliency goal to the service group.
Review the summary tiles. Exclude or manually attest the resources that need it.
Walk the Advisor recommendations. Use the Copilot guided flow to generate a remediation script and run it through your automation.
Build an application-centric recovery plan, group and order the resources, run an on-demand readiness check.
Create a zone-down drill from the template, validate identity, monitoring, and faults, then execute the drill in a non-production zone first.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki

Cheers!

Pierre Roman

Agentic Migrations and Modernization: How the Azure Migrate Agent Keeps Your Intent Alive End to End

Pierre_Roman — Wed, 05 Aug 2026 07:00:00 GMT

Hello Folks!

If you have ever tried to move a few hundred VMs, a pile of databases, and a couple of web apps from on-prem to Azure, you already know the hard part is not the tooling.

The hard part is keeping context, intent, and momentum alive across weeks of planning, hand-offs, and decisions. In session MAIS15 at the Microsoft Azure Infra Summit 2026, Ankur Gupta (Senior Product Manager on the Azure Migrate team) walked us through the new Azure Migrate agent, an AI layer that sits on top of Azure Migrate and carries your intent from “I have an idea” all the way to “the landing zone is deployed.”

Why IT Pros Should Care

Ankur opened with a line that stuck with me. Infrastructure complexity has far outpaced human scale. We have MySQL here, PostgreSQL there, web apps, storage devices, networking gear, multiple dashboards, multiple alerts, and we are all expected to move faster than ever, with fewer mistakes. In short, migrations rarely fail because someone picked the wrong tool. They fail because the system between the stages breaks.

Here is why the agentic approach matters for the folks in the trenches:

It keeps context across the entire lifecycle, so the intent you set on day one is still the intent at execution.
It guides you when you are stuck, instead of leaving you to figure out which of three discovery methods is the right one.
It compresses tasks that used to take days of analysis (think side-by-side business cases) into a few hours.
It connects IT ops, architects, and developers through a single thread of information, including a clean handoff to GitHub Copilot for code work.
It builds on the Azure Migrate portal you already know, so nothing you have learned goes to waste.

That last point is important. The portal does not go away. The agent is a layer on top. You can still do everything you do today.

What the Azure Migrate Agent Is, technical overview

Azure Migrate has always been Microsoft’s hub for discover, assess, and migrate. What Ankur showed at MAIS15 is the next evolution. Azure Migrate is becoming a migration control plane that spans the whole lifecycle (Decide, Plan, Execute), and the Azure Migrate agent is the conversational, guidance-oriented layer that ties it all together.

In Ankur’s words, the agent is educational and guidance-oriented. You ask one natural-language question, like “how should I plan moving my VMware workloads to Azure,” and you get the next steps you actually need to take. Behind the scenes, the agent is doing three things very well.

It maintains state across the entire lifecycle. Preferences you set early stay with you.
It carries context across discovery, plan, and execute. You can jump around, repeat steps, change your mind, and the agent remembers what your goal was.
It recommends the right next move based on what it has learned about your intent.

This is the heart of the “agentic” part. The agent is not a chatbot grafted onto a portal. It is a stateful workflow runner that remembers you.

How It Works, under the hood

The session walked through a full VMware-to-Azure scenario, and the flow is worth seeing because it shows how the pieces snap together.

The agent supports three discovery methods today: appliance-based discovery, RV Tools, and the new Azure Migrate collector. The collector is the new lightweight option. It ships as a set of PowerShell scripts you run on a machine that can reach your vCenter, it produces a zip file, and you upload that zip to your Azure Migrate project. No appliance to deploy, no inbound network plumbing.

Once the inventory lands, the agent reads it. Ankur asked for a summary and got a card showing 207 VMs, 177 SQL databases, one PostgreSQL instance, and some web apps. He then asked for all servers with an out-of-support OS, got a list of around 50, and tagged them right inside the conversation so he could refer back to them later.

Next came the business case. Ankur asked the agent to generate one based on a modernize preference. A few minutes later, he had Azure cost, on-prem cost, and projected savings. Then he asked for a second business case for lift and shift, and a side-by-side comparison. The agent ran it, showed that the on-prem cost in the lift-and-shift comparison was higher and that lift-and-shift TCO savings were actually higher in that specific scenario, and gave him the data points he needed to bring the decision to leadership.

From there, Ankur moved to application assessment, this time back in the portal. He created an assessment for two apps (Airsonic and Parts Unlimited), let the high-confidence plan run, and got a modernize recommendation with 100% readiness and a target cost of about $580 per month, plus an emissions estimate of 32 kgs of CO2. App Service for the web tier, Azure Database for PostgreSQL for the data tier. Both were flagged “ready with conditions,” with clickable links into why.

Then came one of my favorite parts. Ankur connected GitHub for a Copilot Assessment, which adds code-level insights on top of the infrastructure readiness assessment. The system recalculated, and the migration effort estimate sharpened up.

Finally, the agent built a wave plan from the assessment, then generated a platform landing zone aligned with Azure best practices. He could ask the agent about chosen defaults, request changes to the deployment mechanism, swap in a third-party firewall, or apply naming conventions. The agent produced a downloadable Infrastructure-as-Code template and handed it to a cloud architect, who refined it in their IDE using GitHub Copilot.

That last handoff is the bridge between Azure Migrate’s planning world and the developer world.

Real-World Value (use cases, ROI, scenarios)

So where does this actually pay off? A few scenarios stood out.

Pitching the business case to leadership. Ankur framed the demo around “I need to pitch a migration proposal to the planning committee.” Generating modernize, lift-and-shift, and Azure VMware Solution business cases used to be days of spreadsheet work. With the agent, it is hours.
Cleaning up legacy debt. Tagging out-of-support servers in one conversational step lets you plan upgrades without exporting CSVs and slicing them by hand.
Mixed estates with web apps and databases. The agent surfaces App Service and Azure Database for PostgreSQL targets, gives SKU recommendations, and flags the warnings worth investigating.
Closing the IT-to-developer gap. The GitHub Copilot Assessment and the IaC handoff to the IDE means developers and architects work from the same context.
Reducing intent drift on long migrations. Multi-week journeys lose their original intent. The agent remembers.

In short, the ROI here is measured in calendar time, not just dollars. And honestly, in fewer late-night calls when something goes sideways because nobody remembered the original decision.

Tradeoffs worth flagging: the agentic capabilities are landing in preview, and outputs are advisory. You still need human review, testing, and governance on every recommendation. That is by design.

Getting Started (concrete first steps)

Here is a practical onramp.

Stand up an Azure Migrate project in the Azure portal if you do not already have one.
Pick a discovery method that fits your environment. If you cannot deploy an appliance, try the new collector. Download the PowerShell scripts, run them from a host that can reach vCenter, and upload the zip.
Bring in the Azure Migrate agent from inside the portal and ask it to summarize your discovered inventory.
Generate at least two business cases (modernize and lift-and-shift). Compare them.
Run an application assessment on a small, representative set of apps. Connect GitHub and add a Copilot Assessment for code-level insight.
Ask the agent to build a wave plan and a platform landing zone template, then push the IaC to your repo for the architects.

Start small, build the muscle, and scale out.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here Microsoft Azure Infra Summit 2026

Cheers!

Pierre Roman

From Alert to Resolved: Building a Self-Healing Azure Platform with SRE Agent

Pierre_Roman — Tue, 04 Aug 2026 07:00:00 GMT

Hello Folks!

It’s 3 a.m. Your phone lights up. A critical workload that spans multiple clouds is on fire, ownership is fuzzy, the alert routed to the wrong team first, and now it’s your problem. You sit up in bed, cold and groggy, and start the ritual. Open the runbook. Pull logs from one place. Pull metrics from another. Stare at three dashboards. None of them tell the whole story. So you build a theory. The theory is wrong. The clock keeps ticking. The customer impact keeps climbing. Every wrong turn costs you time, context, and confidence.

That is the scene Lee Oommen opened with at MAIS14, and it is the reason Azure SRE Agent exists. In this session, Lee walks through the four classic SRE pain points and shows how an agentic operations platform compresses MTTR from hours to minutes. I am going to unpack what he showed, why it matters for IT pros, and how to get your hands on it.

Why IT Pros Should Care

If you carry a pager, write runbooks, or get pulled into post-mortems, this one is for you.

The clock is the enemy, not the incident. Lee said it plainly: there is almost always an expert who can fix the problem. The real damage comes from the minutes spent finding that expert and reconstructing context.
Dashboards lie in both directions. False positives create alert fatigue. False negatives let the customer call you before your monitors do. Neither outcome is acceptable.
RCAs take weeks because the answer never lives in one layer. Infrastructure, network, deployments, dependencies, databases, app code. You need someone, or something, that can correlate across all of them in one pass.
You did not become an SRE to be a dashboard watcher. Toil is the work that holds back the people who should be designing reliability into the next generation of services.

What is the SRE Agent

Let’s start with what it is not. It is not a dashboard. It is not a monitoring tool. It is not a chatbot.

Azure SRE Agent is an end-to-end agentic operations platform. Think of it as a senior SRE who sits inside your team, works 24 by 7, never gets tired, never misses a signal, and is fluent in your stack.

Reasons over telemetry, not just text. It pulls metrics, logs, traces, deployment history, and activity logs, then correlates across them.
Takes governed actions. Every action runs inside the permission boundary you define. You decide whether the agent proposes a fix, asks for approval, or acts autonomously.
Authors RCAs in minutes, not weeks. It traces the root cause in a single flow across the entire stack and produces the report immediately after remediation.
Remembers. It captures organizational memory from every incident, every chat, and every scheduled task, then applies it to the next investigation.

Lee called it the operations half of DevOps, and that framing stuck with me. We have automated build and deploy. The operations side has been stuck in toil. SRE Agent closes that loop.

From Alert to Resolved (the workflow)

Lee demonstrated the full loop live. Here is what it looks like end to end.

Detect. The agent integrates with Azure Monitor, PagerDuty, or ServiceNow. When an alert fires, the agent acknowledges it within seconds. The human does not have to wake up cold.
Investigate. The agent runs diagnostics in parallel across the connected resources. It queries Log Analytics, App Insights, Azure Monitor metrics, and any third-party observability tools you wired in through MCP connectors.
Correlate. It uses distributed tracing, cross-workspace KQL queries, and time-based signal alignment to connect dots across services that do not even share trace IDs. It also checks past incidents in memory to see if this looks familiar.
Diagnose. It produces a root cause analysis with the relevant evidence linked inline. No more reconstruction exercise across multiple teams.
Propose or Act. Based on your run mode and the permissions granted, the agent either proposes a fix and waits for approval, or executes the remediation autonomously. Lee demonstrated both. He set up a bad slot swap on Azure App Service, generated HTTP 500 errors, watched the agent acknowledge the alert, investigate, identify the bad slot, ask for permission, and then perform the slot swap to restore the service.
Close the loop. The agent files a GitHub or Azure DevOps issue with full context, opens a pull request with proposed code changes when appropriate, and writes a session insights summary you can review.

Three modes to interact with it:

Interactive. Chat with the agent like a copilot. Most customers start here to build trust.
Reactive. Event-driven. The agent reacts to incidents from Azure Monitor, PagerDuty, or ServiceNow. One agent per incident platform.
Proactive. Scheduled tasks that run every five minutes, every hour, daily, or weekly. Certificate health audits, well-architected framework assessments, cost optimization sweeps, compliance checks. Lee showed a scheduled task that flagged a certificate expiring in 50 days before it could ever fire an alert.

Real-World Value

This is where the conversation gets practical. A few things from Lee’s demo and the live Q&A that I want to call out.

Multi-cloud reality. SRE Agent lives in Azure but is not limited to Azure. Custom runbooks, Python execution, MCP servers, and connectors let it orchestrate across AWS, GCP, and on-premises. Treat it as the central SRE brain.
Your data stays yours. Each agent gets a dedicated data store in your subscription and resource group. Memory, knowledge, threads, and session insights live in your chosen region. Nothing is used to train the model provider. Encryption at rest, TLS 1.2 in transit, Azure RBAC, managed identity, customer-managed keys all apply.
Identity boundary you already know. The agent uses standard Azure managed identity. Grant the identity RBAC on any cross-subscription resource it needs to reach. Least privilege still applies.
Region availability. At session time, agents can be deployed in EastUS2, Sweden Central, and Australia East. The list is updating roughly monthly. Canada is coming. An agent in one region can act on resources globally, but if you have data residency rules, deploy the agent inside the same jurisdiction.
Private endpoints today. If your Log Analytics Workspace or databases are fully locked down behind private endpoints with public access disabled, the agent currently needs a VNet-integrated Azure Function as a proxy. Microsoft is actively working on injecting agents directly into private networks.
Memory is the multiplier. A principal engineer is more valuable than a junior engineer because of pattern recognition. SRE Agent captures that pattern recognition for the whole team, every time it investigates.

Getting Started

The pattern is simple, and Lee summarized it cleanly: you teach the tool, you make the connections, and it works for you.

Provision the agent. Go to sre.azure.com or the Azure portal, pick a subscription and resource group, pick a region, and stand it up. Takes a few minutes.
Onboard it like a new engineer. Tell it about your team, your workloads, and your procedures. Upload runbooks, troubleshooting guides, wikis, and architecture docs to the knowledge base. If you do not have these documents, ask the agent to draft them for you.
Connect your observability stack. Azure Monitor, Log Analytics, App Insights are wired in by default. Add third-party tools through MCP connectors.
Wire in your incident platform. Azure Monitor, PagerDuty, or ServiceNow. One agent per platform.
Grant code access. Connect your GitHub or Azure DevOps repositories so the agent can reason over application code, propose fixes, and open pull requests.
Pick your run mode. Start in interactive mode while you build trust. Move to approval-gated reactive mode. Graduate to autonomous mode on safe operations once you have the audit trail you trust.

Resources

Watch the Rest of the Summit

If you found this useful, the rest of the Azure Infra Summit 2026 is packed with sessions on identity, AKS, deployment, storage, networking, and resiliency. Grab the full playlist here and binge what is relevant to your stack:Microsoft Azure Infra Summit 2026

Big thanks to Lee Oommen for walking us through this. The 3 a.m. pager scenario is something every one of us has lived, and seeing an agent take the first hour of that incident off your plate is a tangible win.

Cheers!

Pierre Roman

Designing Azure Networks That Scale: From Small Deployments to Enterprise-Grade

Pierre_Roman — Mon, 03 Aug 2026 07:00:00 GMT

Hello Folks!

If you have ever spent a long afternoon untangling overlapping CIDR ranges, chasing down a broken VNet peering, or trying to remember which UDR points to which firewall, this MAIS 2026 session is going to feel uncomfortably familiar. Jon Ormond (Principal PM, Azure Networking) brought along Jay Li and Jeff Lovett from the Azure Networking team to walk through what actually happens when an Azure network grows from a handful of VNets into a real enterprise estate, and where most teams hit the wall.

The headline they kept coming back to is simple. Azure networks do not usually fail because they were built wrong on day one. They fail because they did not evolve fast enough. Scale is not a smooth ramp. It is a step function, and every step adds an order of magnitude of complexity.

Why IT Pros Should Care

You may be running three VNets today. That is fine. But the day a second team shows up, or you cross into a second region, or somebody asks for hybrid connectivity to the datacenter, your operating model changes whether you planned for it or not. The session is built around two pivots every growing Azure environment hits:

Management and control inside Azure (VNets, peerings, routes, security rules).
Connectivity and hybrid (VPN, ExpressRoute, Virtual WAN, reliability).

Both of those break quietly. By the time you notice, you are already firefighting drift, broken peerings, or unpredictable latency from on-prem.

Bottom line, here is what you take away:

Design for the next stage, not the one you are in.
Put the management layer in before complexity outpaces manual effort.
Treat reliability as a design choice, not an afterthought.

Start Small, Plan to Grow

One VNet, one subnet, one workload. Nothing wrong with that. You can manage it with the portal, a spreadsheet for CIDR tracking, and a calm heart.

The problem is that the jump from “one VNet” to “a few VNets across teams” is not gradual. As soon as you have a second team that needs isolation, you are into hub and spoke territory. Ten spokes feels manageable. Fifty spokes across multiple subscriptions does not. And by the time you hit a hundred, the spreadsheet is a liability.

Jay made the case that the smartest move at small scale is not to stay manual until it hurts. It is to put Azure Virtual Network Manager (AVNM) in early, even if you only have three VNets. AVNM lets you declare intent once and let the platform handle the rest:

IP address management (IPAM) so new spokes get non-overlapping CIDRs automatically.
Network groups with tag-based dynamic membership so VNets land in the right group the moment they exist.
Connectivity (hub and spoke or mesh) without hand-built peerings.
Security admin rules pushed centrally across the estate.
Routing intent so traffic flows through the right firewall by default.

The honest tradeoff: AVNM is one more thing to learn and operate, and it adds cost. The counter-question Jay kept asking is, “What is the cost of drift?” One overlapping CIDR or one missing UDR at 100 VNets can cascade into an outage that takes days to unwind. That is the real tradeoff.

Mid-Stage Patterns: Hub and Spoke, Peering, and the First Cracks

The hub and spoke topology is the workhorse of Azure networking and the pattern the Cloud Adoption Framework recommends for most enterprises. It centralises shared services (firewall, DNS, ExpressRoute and VPN gateways, Private DNS zones) in a hub VNet, and connects spoke VNets through peerings.

Where teams get into trouble at this stage:

Peering sprawl. Every new spoke needs a peering, sometimes two if you want transitive paths. Doing this by hand across subscriptions is where human error lives.
Route table drift. UDRs copied from spoke to spoke get out of sync. One spoke routes through the firewall, another bypasses it. Now you have a compliance problem.
Security rule drift. NSGs and security policies start as a copy paste exercise and end as a forensic exercise.
CIDR collisions. “Just give me a /24” turns into a multi day investigation when the new spoke overlaps with on-prem.

Jay’s point on this was sharp. The mistake is not the topology. Hub and spoke is the right pattern. The mistake is staying manual on top of it. AVNM network groups let you say, “any VNet tagged environment=production joins the production group, gets the production security baseline, peers to the production hub, and inherits the routing intent that sends east-west traffic through the firewall.” No tickets, no copy paste, no drift.

If you are already deployed via Azure Landing Zones (ALZ) with Bicep or Terraform, AVNM is not a replacement, it is another construct in your template. As Jon put it in the chat, it is “just another object” in your ALZ, and the two layers work together rather than competing.

Enterprise Scale: Virtual WAN, Segmentation, and Governance

At some point hub and spoke stops scaling cleanly. You start adding regions. Branch offices show up. You need SD-WAN integration, more than 30 IPsec tunnels, or transitive routing between VPN and ExpressRoute. That is when Microsoft pushes you toward Azure Virtual WAN.

Virtual WAN is a Microsoft managed global transit network. You deploy regional virtual hubs and connect everything (Azure VNets, branches, remote users, ExpressRoute circuits) into them with consistent routing and security. The trade up is real:

Any to any connectivity by default. Hub to hub mesh is built in.
Routing intent and policies for centralised internet egress and east-west inspection through Azure Firewall or a partner NVA in a secured hub.
Branch scale. Tens or hundreds of sites stop being a custom integration project.
Operational simplification. Microsoft owns the hub control plane so you stop babysitting peerings.

For hybrid connectivity itself, Jeff walked the curve every customer travels:

VPN Gateway is the on-ramp. Cheap, fast to stand up, good enough until public internet latency, throughput, or regulatory requirements force a change.
ExpressRoute circuits give you dedicated bandwidth from 50 Mbps to 100+ Gbps, with predictable performance and over 200 service providers worldwide.
Scalable ExpressRoute virtual network gateways grow and shrink with usage, so you deploy once and stop re-architecting every time traffic changes.
ExpressRoute Metro is the headliner. Same price as a standard circuit, but the redundant device lives in a second, physically distinct co-location facility across town. Building fire, flood, or power outage in one site, and your traffic keeps flowing.
Multiple circuits are still on the table when “this cannot fail” actually means it cannot fail.

Honest tradeoff on Virtual WAN: it is opinionated, Microsoft managed, and you give up some of the granular control you have in a customer managed hub. For most enterprises that is a win. For the few with very specific routing requirements or heavy NVA investments, traditional hub and spoke with Azure Route Server can still be the right call. The CAF guidance lays this out in detail.

Getting Started

If you take one thing from this session, take this. Design for the next stage. Three concrete moves:

Stand up AVNM now, even at small scale. Declare your intent for IPAM, connectivity, security, and routing once. Let new VNets inherit it.
Pick your topology with eyes open. Hub and spoke for customer managed control, Virtual WAN for Microsoft managed global transit at scale. The CAF decision tree is the right starting point.
Plan hybrid for failure, not for the sunny day. ExpressRoute with Metro by default. Multiple circuits for the workloads that genuinely cannot go down. Test the failover.

Resources

Watch the Rest of the Summit

This was one of many great sessions at the Microsoft Azure Infra Summit 2026. If you want to catch the keynotes, the deep dives on storage and AKS, and everything in between, the full playlist is here:

Microsoft Azure Infra Summit 2026 Playlist

Big thanks to Jon Ormond for moderating, and to Jay Li and Jeff Lovett for the practical, no-fluff walk through what actually breaks at scale and how to design ahead of it.

Cheers!

Pierre Roman

Digital Takeover/Lockdown

BHamm — Sat, 01 Aug 2026 15:30:04 GMT

My web developer has taken over my M365 & Copilot (along with my domain, google workspace, GitHub, Manus.im account, Stripe, Shopify, my financial accounts, and so on) and made has made himself Super admin and/or created an enterprise hierarchy that then turns myself, THE OWNER, into a USER; if he allows me access at all. I have been in an active digital lockout for going on 5 months now. I am at the local library currently trying to find a solution to regaining control. I have been dealing with redirected and limited browsers, blocked accounts, email accounts forwarded and new emails created, and then, even my calls and texts are being forwarded and/or blocked. From taking over my account's admin, a malicious DNS change, using rootkit malware, harmful scripts, injected code, utilizing my API's and tokens to gain access and then lock me out, to deploying autonomous ai agents onto my desktop...It only gets worse! He is also a third-party service provider and has led this persistent attack on my business by hacking EVERY mobile device I have purchased by using my location, Bluetooth, and sharing apps to hack my network and take control. No, this is not a joke. This is my VERY REAL AND VERY CURRENT NIGHTMARE! PLEASE, HELP ME!

-Brittany Hamm

Diary of a Momtrepreneur/Cullmanspaces.com/brittanyhamm.base44.app

Azure Files, Reimagined: Top-Level Shares with Per-Share Networking, Billing, and Scale

Pierre_Roman — Thu, 30 Jul 2026 19:57:34 GMT

Hello Folks!

If you have ever wrestled with Azure Files inside a storage account, juggling shared RBAC, shared networking, and shared IOPS across a pile of shares that really should not live together, this session is going to address all that. During Microsoft Azure Infra Summit 2026, Vincent Du and Will Gries (both Product Managers on the Azure Files team) walked us through the new Microsoft.FileShares resource provider, a management model that promotes the file share itself to a top-level Azure resource.

Why IT Pros Should Care

For years, file shares lived inside a storage account, and that storage account dictated a lot of decisions for you. If one team needed a private endpoint and another needed a service endpoint, you either compromised or you created another storage account. If one share got hot and consumed all the IOPS, the other shares felt it too. Vincent and Will are on the team that built the new model to remove that compromise.

Here is what changes for you as an IT pro:

Each file share is its own Azure resource with its own RBAC, networking, billing, IOPS, and throughput.
Per-share cost shows up directly in Azure Cost Management’s per-resource view, no more Excel guesswork.
Encryption in transit is on by default for NFS shares, at no extra cost.
Provisioning is dramatically faster. In their head-to-head demo, 200 shares finished in about 50 seconds on the new model versus about 720 seconds with the classic flow.
A new MCP server lets you create and manage shares from GitHub Copilot in VS Code with natural language.

In short, the new model trades the storage-account-as-gatekeeper pattern for something that feels a lot more like the rest of Azure (think VMs and disks, where the resource you care about is the resource you actually manage).

What Microsoft.FileShares Does, a Technical Overview

The new Microsoft.FileShares resource provider lets you deploy a file share without first standing up a storage account. When you go into the Azure portal, search for “File share,” and click create, you fill out a single create blade with the things that actually matter for that share: name, region, redundancy (LRS or ZRS), provisioned capacity, IOPS and throughput, networking, and tags. Microsoft Learn confirms the provisioned capacity range is 32 GiB to 262,144 GiB, and only LRS and ZRS redundancy are available at launch (see the Create a file share doc linked below).

At GA, the new experience supports NFS 4.1 on the SSD media tier. SMB support, HDD support, customer-managed key encryption at rest, soft delete, and the AKS CSI driver integration are all on the roadmap and called out as the most-requested follow-ups. If you need those features today, the classic file share inside a storage account is still there for you.

In the portal, Vincent showed off a small but meaningful detail: the icon color changed from blue (classic) to purple (new). It is a small thing, but when you are scanning a resource group, that visual cue saves you a click.

How It Works Under the Hood

The new model is built on the provisioned v2 billing structure. Microsoft Learn describes provisioned v2 as a billing model where you independently provision storage, IOPS, and throughput, and you pay for what you provision regardless of how much you actually use. This is a real shift from the older provisioned v1 model, where IOPS and throughput were a function of how much storage you provisioned.

Will walked through the math. In his example, provisioning 14 TiB of storage on v1 gave 17,000 IOPS, about 1.5 GB/s throughput, and a bill of roughly $2,297. Moving to v2 with the exact same numbers was already noticeably cheaper. Then, because v2 lets you tune storage, IOPS, and throughput separately, he provisioned the exact storage he needed with slightly less IOPS and throughput, dropping the bill to roughly a third. For database-hot workloads you can dial IOPS up; for hot archive scenarios you can dial them down to the minimum. That kind of flexibility is genuinely useful.

Encryption in transit deserves its own callout. The new shares default to encrypted NFS mounts using the AZNFS mount helper. Microsoft Learn explains that AZNFS wraps the NFS connection in a Stunnel-based TLS tunnel using AES-GCM, so you get TLS protection without needing Kerberos or external authentication. The helper installs cleanly on Ubuntu, RHEL, SUSE, Rocky, Oracle Linux, Alma Linux, and Azure Linux. If a workload genuinely cannot use the encrypted mount, you can uncheck the box and fall back to a traditional NFS mount.

Networking is per share. You can attach a service endpoint or a private endpoint to each individual share, which means you can put a strict private-endpoint-only share next to a service-endpoint share for dev/test, all in the same resource group, without compromise.

On the request side, classic shares throttle with a fixed window (you can burst, then you are locked out for the rest of the window). The new model uses a token-bucket algorithm (the same one Azure Resource Manager itself uses), which means you get a sustained refill rate. The team also gave you a separate delete bucket, so a big cleanup operation does not starve writes. That detail matters more than it sounds: batch cleanups against the classic model regularly crowd out new share creation.

Real-World Value

Where does this actually pay off? A few honest scenarios:

Mission-critical and regulated workloads. A healthcare org with workloads at different sensitivity levels can put strict private-endpoint-only shares next to less sensitive service-endpoint shares without the storage-account ceiling.
Chargeback and showback. With per-share resources, finance can pull a cost report that lines up to the team or project that owns each share. No more saying “we cannot itemize, the storage account is shared.”
High-density tenants. The classic model effectively caps you at 34 file shares on an SSD provisioned v2 storage account (because of IOPS minimums) and 50 absolute. The new model goes up to 10,000 shares per subscription per region. That is a different game.
Tuned database and analytics shares. Provisioned v2 lets you right-size IOPS to the workload. As Will showed, that can drop the bill to roughly a third for the right shape of workload.
Faster deployment automation. A 14x improvement on a 200-share deployment is not a micro-optimization. If you spin up environments for CI, training, or per-customer tenants, that adds up quickly.

The honest tradeoff: today, the new model is NFS-only on SSD. If you need SMB, HDD, customer-managed keys for NFS, or AKS CSI driver support, stay on the classic model for now. The team was upfront about that, and the GA-and-then-iterate roadmap is clear.

Getting Started

Here is the concrete path:

Register the Microsoft.FileShares and Microsoft.Storage resource providers on your subscription (Subscriptions, Resource providers, Register).
From the Azure portal, search for “File share” in the marketplace and click Create. Pick LRS or ZRS, set the capacity between 32 GiB and 262 TiB, and either accept the recommended IOPS/throughput or set them manually.
On the Advanced tab, leave “Require encryption in transit” enabled (it is on by default) and pick a custom mount name if you want one distinct from the resource name.
On the Networking tab, attach a service endpoint or a private endpoint, per share.
Mount it on your Linux VM with the AZNFS mount helper. The portal generates the exact command for your distribution.
If you live in IaC land, the Microsoft.FileShares ARM and Bicep types are available, and Terraform support is coming.
If you live in AI-assisted dev land, install the Azure MCP server and ask Copilot in VS Code to create a share for you, pointing at an existing VNet.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here.

Cheers!

Pierre Roman

Some tools and techniques for hardening Windows Server

OrinThomas — Wed, 22 Jul 2026 20:30:09 GMT

In this post I go over some tools and techniques exist for hardening Windows Server. As always, apply controls according to the server's role, test them against representative workloads before production rollout, document approved exceptions, and maintain tested console and recovery access in case a security control affects management or application compatibility.

Apply the role-specific Windows Server 2025 baseline with OSConfig

Security baselines turn hundreds of individual security decisions into a consistent, role-aware desired state. Using OSConfig reduces exposure caused by insecure defaults, legacy protocols, inconsistent administrator choices, and configuration drift that attackers can exploit for credential theft, lateral movement, or persistence.

You can use use OSConfig at build time to apply the Microsoft security baseline that matches the server role: SecurityBaseline/WindowsServer/2025/MemberServer, SecurityBaseline/WindowsServer/2025/DomainController, or SecurityBaseline/WindowsServer/2025/WorkgroupMember. The baseline contains more than 300 settings covering network exposure, credentials, lateral movement, persistence resistance, and auditing. It can be managed through PowerShell, Windows Admin Center, or Azure Policy for Azure Arc-enabled servers.

You can keep OSConfig drift control enabled so unauthorized or accidental changes are detected and corrected. Pilot the baseline with each workload, record required exceptions, and manage those exceptions centrally rather than weakening the baseline broadly.

Implementation steps: Identify the server's role and the management authority that will own its settings, install the OSConfig PowerShell module, review the matching scenario, and apply it first to a representative test server. Validate application and management access, deploy the scenario in controlled rings, schedule and complete the restart required after applying the baseline, verify the desired configuration and compliance results, enable drift control, and record any approved exceptions and recovery procedures.

Possible drawbacks: A baseline can disrupt legacy applications, authentication methods, network flows, or management tools that depend on weaker settings. Drift control can also reverse intentional emergency changes if they aren't recorded through the correct authority, so staged testing, documented exceptions, and tested recovery access are essential.

Documentation on Learn: OSConfig security configuration for Windows Server | Deploy Windows Server 2025 security baselines with OSConfig | OSConfig security settings repository

Use Secured-core hardware and enable platform security

Windows Server secured-core combines hardware, firmware, virtualization, and operating-system protections to establish trust before Windows starts and preserve that trust while it runs. These controls mitigate bootkits, malicious or vulnerable kernel drivers, direct memory access attacks, firmware tampering, and attempts to extract credentials from the operating system.

You deploy on hardware or virtual machines that support TPM 2.0, UEFI Secure Boot, virtualization-based security, DMA protection, and the other Secured-core requirements. Enable the OSConfig SecuredCore scenario and verify that Credential Guard, hypervisor-protected code integrity, kernel protections, and the signed boot chain are active.

You need to keep system firmware, TPM firmware, hypervisor components, and hardware drivers current. Test older drivers before enabling enforcement because incompatible kernel drivers can prevent security features from activating or can affect boot reliability.

Implementation steps: Confirm that the physical server or virtual-machine platform meets the Secured-core requirements, update firmware and drivers, and enable TPM 2.0, Secure Boot, virtualization extensions, and DMA or IOMMU protection in the platform configuration. Apply the OSConfig SecuredCore scenario or configure the features through Windows Admin Center, restart as required, verify that each protection is active, record evidence of the hardware capabilities and running Windows protections rather than only the assigned policy, and monitor for driver or workload compatibility issues.

Possible drawbacks: Secured-core features require compatible hardware, firmware, hypervisors, and signed drivers, which can increase procurement costs or rule out older systems. Virtualization-based protections can introduce a workload-dependent performance impact, and incompatible drivers or firmware can cause application failures, feature activation problems, or difficult boot recovery.

Documentation: What is Secured-core server? | Configure Secured-core server | Windows Server 2025 secured-core hardware requirements

Deploy Server Core and minimize installed components

Attack-surface reduction removes code, services, interfaces, and utilities that an attacker could exploit or misuse after gaining access. A minimal Server Core deployment lowers the number of vulnerabilities that require patching and reduces opportunities for interactive attacks, malicious browsing, persistence, and abuse of unnecessary administrative tools.

Install Server Core unless a supported workload specifically requires Desktop Experience. Server Core has a smaller local interface and component footprint, reducing exposed code, maintenance requirements, and opportunities for interactive misuse. Windows Server 2025 can't convert between Server Core and Server with Desktop Experience after installation, so changing this choice later requires a clean installation.

Install only the roles, features, management agents, and application components required for the server's purpose. Remove obsolete utilities and unused software, avoid browsing the web from servers, and disable unnecessary services only after confirming role and application dependencies. Where practical, dedicate each server to a single security or workload role.

Implementation steps: Confirm that the workload and vendor support Server Core, formally record the installation-option decision before deployment, select Server Core during installation, and define the minimum roles, features, agents, and software required for the server's purpose. Install only those components, configure remote management and recovery access, remove or disable unused components after dependency testing, and verify that the application, monitoring, backup, patching, and support processes still function.

Possible drawbacks: Server Core can make local troubleshooting less familiar and increases reliance on remote management, automation, and command-line skills. Some vendor applications, support tools, or administrators require Desktop Experience, and removing roles or disabling services without dependency testing can break workloads, monitoring, backup, or recovery operations.

Documentation: What is the Server Core installation option? | Server Core and Desktop Experience installation options

Ensure rapid patching and continuous vulnerability management

Patching and vulnerability management identify and close known weaknesses before attackers can reliably exploit them. This practice reduces exposure to remote-code execution, privilege escalation, ransomware, vulnerable drivers, compromised third-party components, and attacks that target publicly documented vulnerabilities soon after disclosure. Make sure you are aware if any of your server workloads have not got the latest security updates deployed

Maintain an inventory of operating-system, application, driver, firmware, and management-agent versions. Use deployment rings to test updates quickly, meet defined remediation deadlines, install out-of-band security updates when required, and monitor update compliance and pending restarts. Azure Update Manager can provide centralized assessment and orchestration for Azure and Azure Arc-enabled servers.

Use Microsoft Defender Vulnerability Management or an equivalent platform to discover exposures, prioritize remediation by exploitability and business impact, and verify that fixes actually remove the vulnerability. Patching Windows while leaving internet-facing applications, drivers, or firmware obsolete does not adequately harden the server.

Implementation steps: Inventory servers and every supported update source, define remediation deadlines and deployment rings, and configure Azure Update Manager or another actively developed orchestration platform. Windows Server Update Services remains supported and available but is deprecated and should be treated as a legacy option rather than the preferred platform for a new long-term design. Run vulnerability assessments, prioritize exposed and actively exploited weaknesses, test updates, deploy them with coordinated reboots, verify compliance after installation, and maintain rollback and exception procedures.

Possible drawbacks: Updates can require reboots, consume maintenance windows, or introduce application, driver, and performance regressions. Vulnerability scanners and management agents also consume resources and can generate false positives, so organizations need test rings, rollback procedures, maintenance coordination, and a risk-based process for temporary deferrals.

Documentation: Azure Update Manager overview | Cloud-native patch management for Azure Arc-enabled servers | Microsoft Defender Vulnerability Management | Deprecated Windows Server features

Implement Microsoft Defender Antivirus and endpoint detection and response

Antivirus and endpoint detection and response combine prevention with behavioral monitoring and investigation. They mitigate malicious files, ransomware, web and network-delivered payloads, suspicious process activity, persistence mechanisms, credential theft, and attacks that evade simple signature-based detection.

Run Microsoft Defender Antivirus in active mode unless a documented and tested security architecture requires another antimalware product. Enable real-time protection, behavior monitoring, cloud-delivered protection, automatic sample submission, and frequent security-intelligence updates. Use the OSConfig Defender/Antivirus/WindowsServer/2025 scenario as the recommended Server 2025 configuration starting point.

Onboard servers to Microsoft Defender for Endpoint or Microsoft Defender for Servers for endpoint detection and response, investigation, and centralized visibility. Enable tamper protection and keep exclusions narrow, workload-specific, and regularly reviewed; broad path, process, or extension exclusions create useful hiding places for attackers.

Implementation steps: Confirm licensing, connectivity, proxy, and third-party antivirus requirements, then apply the OSConfig Defender Antivirus scenario or an equivalent centrally managed policy. Enable real-time, behavior, cloud-delivered, sample-submission, and tamper protections; onboard the server to Defender for Endpoint or Defender for Servers; review Microsoft's built-in, automatic server-role, and workload-specific exclusions before adding any manual exclusion; verify sensor health, signature currency, alert delivery, and investigation access; and periodically confirm that every manual exclusion remains necessary.

Possible drawbacks: Real-time scanning and endpoint telemetry can add CPU, memory, disk I/O, network, and licensing costs, particularly on high-throughput workloads. False positives or quarantine actions can interrupt services, while cloud-delivered capabilities can raise connectivity, privacy, or data-residency considerations; performance exclusions must therefore be tested and kept narrowly scoped.

Documentation: Microsoft Defender Antivirus in Windows | Microsoft Defender for Endpoint on Windows | Defender Antivirus exclusions | Protect against security-setting tampering

Deploy attack surface reduction and network protection on your Windows Server workloads

Attack surface reduction rules prevent high-risk behaviors rather than waiting for a specific malicious file to be identified, while network protection blocks access to known or suspicious destinations. Together they mitigate ransomware, credential theft, malicious scripts, abuse of trusted tools, vulnerable drivers, command-and-control traffic, and payload delivery.

Configure Microsoft Defender attack surface reduction rules to block common behaviors used by ransomware, credential theft, malicious scripts, vulnerable signed drivers, and executable content. Begin with audit or warning mode, review telemetry for legitimate workload dependencies, create narrowly scoped exclusions, and then move suitable rules to block mode on a defined schedule.

Enable network protection where supported to prevent processes from reaching malicious or untrusted destinations. Manage these controls centrally through Group Policy, Microsoft Defender for Endpoint security settings management, or another supported policy platform.

Implementation steps: Inventory server workloads and make a rule-by-rule applicability decision for each server role rather than reusing a generic workstation ASR profile unchanged. Create a centrally managed ASR and network-protection policy that initially uses audit or warning mode, collect and review events, confirm business-critical dependencies, create narrowly scoped exclusions, move applicable rules to block mode through deployment rings, verify that protected applications remain functional, and continuously review detections and exception use.

Possible drawbacks: ASR rules can block legitimate automation, administrative tools, installers, scripts, or line-of-business applications that exhibit high-risk behavior. Audit mode can produce substantial telemetry, and broad exclusions can undermine the protection, so successful deployment requires workload testing, event review, careful exception design, and ongoing tuning.

Documentation: Attack surface reduction capabilities | Evaluate Microsoft Defender Antivirus and ASR rules using Group Policy

Allow only trusted code with App Control for Business

Application control changes the execution model from allowing everything except known malware to allowing only code that satisfies an approved policy. This technique mitigates unknown malware, ransomware, unauthorized administrative utilities, malicious scripts, unapproved drivers, and opportunistic payloads that antivirus has not yet classified.

Use App Control for Business to define which executables, scripts, installers, libraries, and drivers may run. Windows Server 2025 includes OSConfig scenarios for Microsoft's default policy and application blocklist. Start in audit mode, collect Code Integrity event ID 3076, create required supplemental allow policies, and move to enforcement only after representative workload testing. There are some good GUI tools written by MVPs published on GitHub that make this very easy. https://github.com/HotCakeX/Harden-Windows-Security

Monitor blocked-code event ID 3077 after enforcement and maintain a controlled process for policy updates and emergency recovery. Application allowlisting is substantially stronger than relying only on malware signatures because unapproved code is prevented from running even when it has not yet been classified as malicious.

Implementation steps: Verify that the device is running a production-signed Windows Server 2025 build because the OSConfig default policy doesn't permit flight-signed binaries. Inventory approved applications, scripts, drivers, publishers, and update mechanisms, then deploy the default policy and application blocklist through OSConfig in audit mode. Collect event ID 3076, build and deploy required supplemental policies, and sign policies only when the additional tamper resistance is required and certificate lifecycle, policy servicing, removal, and offline recovery have been tested. Test application updates and recovery, move the policy to enforcement in stages, and monitor event ID 3077 and policy health after deployment.

Possible drawbacks: Poorly designed policies can block legitimate applications, updates, scripts, drivers, or boot-critical components and can cause a severe service outage. Maintaining allow policies creates operational overhead, especially for frequently changing software, and approved tools can still be abused, so audit-mode deployment, controlled updates, and offline recovery procedures are necessary. Signed policies provide stronger tamper resistance but are intentionally harder to remove, including during recovery.

Documentation: Configure App Control for Business by using OSConfig | App Control for Business

Keep Windows Defender Firewall enabled with restrictive rules

A host firewall limits which systems and applications can communicate with the server, even when upstream network controls are absent or bypassed. Restrictive rules reduce exposure to service exploitation, scanning, lateral movement, remote administration abuse, command-and-control traffic, and accidental publication of listening services.

Enable Windows Defender Firewall on Domain, Private, and Public profiles. Retain the default block for unsolicited inbound traffic and create only the rules required by the server role. Scope rules by program or service, protocol, local port, remote address, interface, and profile rather than creating broad port-based or any-source exceptions.

Log dropped packets and successful connections where operationally appropriate, centrally monitor policy changes, and review stale rules. Apply explicit outbound restrictions to high-value or tightly controlled servers where feasible, especially when they should communicate with only a small set of update, identity, management, and application endpoints.

Implementation steps: Inventory listening services and required inbound and outbound flows, enable the firewall on all profiles, and create narrowly scoped rules for the server role. Decide whether locally created rules may merge with centrally deployed rules for each profile, verify the effective policy on representative servers, remove obsolete or duplicate rules, test application, domain, cluster, backup, and management traffic, enable appropriate logging, deploy the policy centrally, and monitor rule changes and blocked connections before introducing selective outbound restrictions.

Possible drawbacks: Incorrect firewall rules can interrupt application traffic, clustering, domain operations, monitoring, backup, or remote management and can make diagnosis difficult. Detailed connection logging consumes storage, while restrictive outbound policies require continuous maintenance as service endpoints change, so rules should be documented, tested, and deployed with recovery access.

Documentation: Windows Firewall rule recommendations | OSConfig baseline network protections

Harden Remote Desktop and remote administration

Remote administration exposes privileged authentication and interactive control paths that are attractive targets for brute-force attacks, credential theft, session hijacking, and exploitation of internet-facing services. Gateways, multifactor authentication, encrypted sessions, restricted source networks, and credential isolation reduce the likelihood that a stolen password or exposed management port leads directly to server compromise.

Disable Remote Desktop Services when it is not required. When it is required, use a VPN or Remote Desktop Gateway, require multifactor authentication and Network Level Authentication, restrict source networks and authorized groups, use trusted TLS certificates, and configure sensible idle and disconnected-session limits. Disable clipboard, drive, printer, port, and device redirection unless the operational need outweighs the data-transfer risk.

Use Remote Credential Guard only for compatible direct RDP administration of Active Directory-joined targets using Kerberos so credentials aren't sent to the remote host. Remote Credential Guard isn't supported through Remote Desktop Gateway or Remote Desktop Connection Broker. For helpdesk access to a potentially compromised host, use Restricted Admin mode instead of Remote Credential Guard. Never expose TCP port 3389 directly to the internet, and avoid using saved privileged credentials on ordinary administrator workstations.

Implementation steps: Disable RDP on servers that don't require it. For brokered or externally initiated access, place RDP behind a VPN or MFA-protected Remote Desktop Gateway and restrict permitted users and source networks. For compatible direct RDP administration of Active Directory-joined targets, configure Remote Credential Guard separately; use Restricted Admin mode for appropriate helpdesk scenarios. Configure Network Level Authentication, trusted TLS certificates, session limits, and required redirection controls, test routine and emergency access, and monitor remote logons and gateway activity.

Possible drawbacks: Gateways, VPNs, MFA services, and secure administrative hosts add licensing, infrastructure, and support dependencies, and their outage can block legitimate administration. Device-redirection restrictions can hinder support workflows, while Network Level Authentication and Remote Credential Guard have compatibility and delegation limitations; a separately secured emergency access path is therefore required.

Documentation: Plan multifactor authentication for Remote Desktop Services | Remote Credential Guard

Enforce least privilege and separate administrative identities

Least privilege limits each identity and session to the minimum actions required for its task. Separating standard and privileged accounts constrains the damage caused by phishing, token or password theft, malicious insiders, vulnerable administrative tools, and compromised lower-trust devices, while reducing opportunities for privilege escalation and persistence.

Give administrators standard user accounts for routine work and separate privileged accounts for administrative duties. Minimize membership of local Administrators, Domain Admins, Enterprise Admins, and other powerful groups; review membership and assigned user rights regularly; and prevent highly privileged identities from signing in to lower-trust servers and workstations.

Use Just Enough Administration endpoints, Windows Admin Center role-based access control, and time-limited elevation where possible. Delegate specific tasks rather than granting unrestricted interactive or PowerShell access, and maintain separately protected emergency accounts for identity-service outages.

Implementation steps: Inventory privileged human accounts, service principals, managed identities, service and automation credentials, scheduled tasks, local group membership, duties, and logon locations. Create separate standard and administrative identities, remove unnecessary standing memberships, delegate tasks through role groups, JEA endpoints, Windows Admin Center RBAC, or time-limited elevation, restrict high-tier logons to secured administrative hosts, test that each role can perform its approved duties, and monitor privileged-group, role, automation, and emergency-account use.

Possible drawbacks: Designing roles, JEA endpoints, approval processes, and time-limited access requires ongoing engineering and governance. Excessively narrow delegation can delay troubleshooting or incident response, while separate accounts add friction for administrators, so permissions should be tested against real duties and emergency access should remain tightly controlled but usable.

Documentation: Just Enough Administration | Windows Admin Center user access options | Enterprise access model

Deploy Windows LAPS for local administrator credentials

Windows LAPS replaces shared or manually maintained local administrator passwords with unique, random, automatically rotated credentials. It mitigates password reuse, pass-the-hash attacks, credential dumping, and broad lateral movement in which compromise of one server's local administrator credential grants access to many others.

Use Windows Local Administrator Password Solution to assign a unique, random, automatically rotated local administrator password to every server. The backup destination depends on join state: Active Directory-only devices can use only Active Directory, Microsoft Entra-only devices can use only Microsoft Entra ID, and hybrid-joined devices can use either destination but not both simultaneously. Tightly restrict and audit password retrieval, configure password history and post-authentication rotation, and monitor policy-processing failures.

Never reuse a common local administrator password across servers because one compromised password or hash can enable broad lateral movement. OSConfig provides the LAPS/WindowsServer/2025/MemberServer scenario for member servers. Workgroup systems can be managed through LAPS for Azure Arc, which Microsoft currently documents as a preview feature. On domain controllers, use Windows LAPS to manage the Directory Services Restore Mode password where appropriate.

Implementation steps: Select the password-backup destination permitted by the device's join state, prepare Active Directory or Microsoft Entra ID, and identify the local account to manage. For workgroup systems, evaluate the operational and support implications of the preview LAPS for Azure Arc service before adoption. Configure password length, complexity, age, history, and post-authentication actions through policy or OSConfig; configure DSRM password management for applicable domain controllers; delegate password read and reset permissions to a small approved group; pilot the policy; verify password backup and rotation; test authorized recovery; and monitor LAPS processing and retrieval events.

Possible drawbacks: LAPS introduces directory, policy, permissions, auditing, and recovery dependencies that must be designed correctly. Scripts or applications that rely on a fixed local password can fail, password rotation can disrupt active sessions or automation, and overly broad rights to retrieve stored passwords can create a new privileged credential repository for attackers to target.

Documentation: What is Windows LAPS? | OSConfig Windows LAPS scenario | LAPS for Azure Arc

Replace static service-account passwords with managed service accounts

Managed service accounts replace human-managed, long-lived service passwords with complex credentials that Active Directory changes automatically. This reduces exposure to password theft, reuse, weak password selection, expired credentials, secrets embedded in scripts, and persistence based on service accounts whose passwords are rarely rotated.

Use group managed service accounts for supported Windows services, scheduled tasks, and application pools in Active Directory environments. gMSAs provide automatic password management and reduce the need to store or manually rotate long-lived service credentials.

Windows Server 2025 also introduces delegated Managed Service Accounts for supported migrations from traditional service accounts. A dMSA binds authentication to approved machine identities, uses managed randomized keys, and disables use of the original service-account password. dMSA deployment requires a discoverable Windows Server 2025 domain controller, and an existing gMSA can't be migrated to a dMSA.

Grant each gMSA only the logon rights, resource permissions, and password-retrieval scope it requires. Do not make service accounts members of privileged groups unless unavoidable, prohibit interactive sign-in, remove obsolete accounts promptly, and monitor changes to the hosts permitted to retrieve each managed password.

Implementation steps: Inventory service identities and application dependencies, then select a gMSA for supported services that can directly use a managed account or evaluate a dMSA for a supported Windows Server 2025 migration from a traditional service account. For a gMSA, confirm Active Directory and key-distribution prerequisites, limit which hosts may retrieve its password, assign only required logon rights, permissions, and service principal names, install and test the account on approved hosts, migrate the service or task, and disable or remove the former static-password account. For a dMSA, confirm a discoverable Windows Server 2025 domain controller and follow the documented migration and rollback process.

Possible drawbacks: Managed service accounts depend on Active Directory and are not supported by every application, installer, or cross-platform workload. Migration can involve service-principal-name, delegation, permission, and clustering changes, while an overly broad password-retrieval scope allows additional hosts to use the identity. dMSA also requires Windows Server 2025 domain-controller availability and has migration rules that differ from gMSA, so compatibility, rollback, and access boundaries require careful testing.

Documentation: Secure group managed service accounts | Delegated Managed Service Accounts overview | Delegated Managed Service Accounts FAQ

Protect credentials and phase out legacy authentication

Credential isolation and modern authentication reduce the value of secrets that an attacker can extract or relay. Credential Guard, LSA protection, Kerberos AES, and retirement of weak authentication mitigate memory scraping, pass-the-hash, pass-the-ticket, NTLM relay, downgrade attacks, and cracking of obsolete password representations.

Verify that Credential Guard and Local Security Authority protection are active where hardware and workload compatibility permit. Windows Server 2025 enables Credential Guard by default on eligible domain-joined systems that aren't domain controllers, but the state should still be verified and centrally enforced where required. Use Negotiate with Kerberos and modern AES encryption for domain authentication, prevent storage of LM hashes or reversibly encrypted passwords, and keep delegated credentials non-exportable. NTLMv1 is removed in Windows Server 2025, and deprecated NTLMv2 should be treated only as a temporary compatibility fallback rather than an end state.

Audit NTLM and other legacy authentication dependencies before restricting or disabling them, then remove those dependencies in a controlled sequence. Do not disable legacy protocols blindly on production servers, but do not leave them enabled indefinitely solely because their consumers have not been inventoried.

Implementation steps: Confirm hardware and driver support, verify the default Credential Guard state, and use OSConfig or centrally managed policy to enforce Credential Guard and LSA protection where required. Enable NTLM auditing, inventory clients and services using legacy authentication, configure Negotiate and Kerberos AES, update affected service accounts, remediate dependencies, assign an owner and retirement date to every NTLMv2 exception, introduce NTLM restrictions in stages, and monitor authentication failures before broader enforcement.

Possible drawbacks: Virtualization-based credential protection requires compatible hardware and can have a workload-dependent performance or compatibility impact. Legacy devices, applications, trusts, or service configurations may still depend on NTLM or weaker cryptography, and disabling them without complete auditing can cause widespread authentication failures or outages.

Documentation: Credential Guard overview | OSConfig baseline credential protections | Deprecated Windows Server features

Harden SMB and file-server access

SMB hardening protects Windows file sharing and related management traffic against protocol downgrade, relay attacks, on-path tampering, brute-force authentication, guest access, data disclosure, and exploitation of obsolete implementations such as SMBv1. Signing verifies message integrity, while encryption protects sensitive content in transit.

Remove SMBv1, prevent insecure guest logons, retain and verify the Windows Server 2025 default requirement for inbound and outbound SMB signing, use SMB encryption for sensitive or untrusted network paths, and use SMB 3.x for modern file services. Treat any relaxation of signing for an incompatible third-party device as a documented, isolated, and time-bound exception. Windows Server 2025 also provides SMB authentication rate limiting and stronger signing and encryption capabilities that should be retained unless a documented compatibility requirement exists.

Restrict TCP port 445 to approved clients and servers, apply share and NTFS permissions according to least privilege, enable access-based enumeration where appropriate, and audit access to sensitive shares. Do not publish traditional SMB directly to the internet; use a supported secure access design such as SMB over QUIC when its requirements and threat model fit.

Implementation steps: Inventory SMB clients, servers, protocol versions, shares, and access requirements, then remove SMBv1 and insecure guest access. Verify that inbound and outbound signing remain required, document and isolate any temporary third-party compatibility exception, configure encryption, authentication rate limiting, and firewall scope according to the workload, review share and NTFS permissions, pilot changes with older clients and high-throughput workloads, and monitor SMB security, authentication, and performance events after enforcement.

Possible drawbacks: Mandatory SMB signing and encryption consume processor resources and can reduce throughput or increase latency on demanding file workloads. Older storage appliances, scanners, applications, or clients might not support modern SMB requirements, and overly restrictive port or permission changes can disrupt file access, administration, Group Policy, or backup operations.

Documentation: SMB security hardening | Secure SMB traffic in Windows Server

Require modern TLS and manage certificates securely

Modern TLS protects application and management traffic by authenticating endpoints and encrypting data in transit. Requiring current protocol versions, strong cipher suites, and trusted certificates mitigates eavesdropping, man-in-the-middle attacks, protocol downgrade, weak-cryptography attacks, and impersonation using invalid or compromised certificates.

Require TLS 1.2 or later and prefer TLS 1.3 where the application stack supports it. Windows Server 2025 disables TLS 1.0 and TLS 1.1 by default; verify that these protocols and obsolete SSL versions remain disabled and prevent unauthorized re-enablement. Disable weak cipher suites and obsolete hashes through a tested baseline rather than ad hoc registry changes. Inventory old agents, middleware, and network appliances first so incompatible dependencies can be upgraded instead of becoming permanent exceptions.

Use certificates from a trusted public or enterprise certification authority, protect private keys with restrictive access control, select appropriate key sizes and algorithms, monitor expiration, and automate renewal. After dependency review, remove expired, untrusted, orphaned, or unnecessary certificates from server stores.

Implementation steps: Inventory listening services, clients, protocol versions, cipher dependencies, and installed certificates, then replace weak or expiring certificates and confirm application support for modern TLS. Verify that TLS 1.0 and TLS 1.1 remain disabled, apply tested Schannel or OSConfig settings in stages, disable other legacy protocols and weak ciphers, validate every client and integration, rescan the endpoints, remove only certificates confirmed to be unnecessary, and implement automated certificate enrollment, renewal, expiration alerting, and private-key access review.

Possible drawbacks: Disabling old protocols and ciphers can break legacy clients, middleware, monitoring agents, or network devices with no modern TLS support. Certificate issuance, private-key protection, renewal automation, and revocation checking add operational complexity, and an expired or incorrectly deployed certificate can cause a complete service outage.

Documentation: TLS/SSL and Schannel overview | OSConfig baseline protocol protections | Deprecated Windows Server features

Encrypt operating-system and data volumes with BitLocker

BitLocker encrypts data at rest so possession of a disk or offline copy does not provide immediate access to its contents. It mitigates data theft from lost or stolen servers, removed drives, improperly decommissioned hardware, offline password-reset attacks, and attempts to read files by booting an alternate operating system.

Enable BitLocker on operating-system and data volumes, using TPM-backed protectors and additional startup authentication where the physical threat model and availability requirements justify it. Use virtual TPMs and supported host or cloud protections for virtual machines. Encryption protects data on removed drives, decommissioned hardware, stolen systems, and offline copies.

Escrow recovery information in a protected, recoverable directory or management service before enforcement. Limit access to recovery keys, audit retrieval, include key recovery in incident procedures, and test recovery on representative systems so encryption does not become an availability risk.

Implementation steps: Inventory operating-system and data volumes, confirm TPM or virtual TPM readiness, select protectors that meet the physical and availability threat model, and configure a protected recovery-key escrow location. Enable BitLocker in controlled stages, verify encryption and key backup, test normal reboot and recovery scenarios, document break-glass procedures, and continuously monitor encryption and protector compliance. Suspend protection for firmware or boot-chain maintenance only through an approved procedure, then verify that BitLocker protection resumes afterward.

Possible drawbacks: Lost recovery material can make encrypted data permanently inaccessible, while firmware, TPM, boot, or hardware changes can unexpectedly trigger recovery. Encryption can add some performance and operational overhead, and startup PINs can conflict with unattended reboot requirements, so protector selection, key escrow, and recovery testing must reflect the server's availability needs.

Documentation: BitLocker planning guide | BitLocker operations guide | BitLocker recovery overview

Configure detailed auditing and protect local logs

Detailed auditing records security-relevant activity so suspicious behavior can be detected, investigated, and attributed. Authentication, privilege, process, PowerShell, policy, and firewall logs help expose brute-force attempts, credential misuse, privilege escalation, persistence, defense evasion, and attacker efforts to alter system configuration.

Enable advanced audit policy for successful and failed logons, credential validation, account and group changes, sensitive privilege use, process creation with command-line capture, policy changes, removable storage, file shares, firewall activity, and other events relevant to the server role. The OSConfig baseline enables a broad audit configuration and increases important log sizes to improve forensic coverage.

Enable PowerShell module and script block logging, and use protected event logging where appropriate because command content can contain sensitive data. Increase log capacity and retention for the expected event volume, restrict permissions to clear or modify logs, monitor audit-policy changes, and synchronize time with trusted sources.

Implementation steps: Define the activities and events required for detection, investigation, and compliance, then apply advanced audit policy through OSConfig or Group Policy. Enable process command-line and PowerShell logging, measure event volume during a representative pilot, size and protect each log and forwarding path from the observed rates, configure trusted time synchronization, generate representative test events to confirm collection, and review event volume, retention, and policy health regularly.

Possible drawbacks: Detailed auditing can generate large volumes of events, consume storage and processing resources, and overwhelm analysts with noise if collection isn't tuned. Command-line and PowerShell logs can contain credentials or other sensitive data, while undersized logs may overwrite useful evidence, so access, retention, filtering, and capacity require deliberate design.

Documentation: OSConfig baseline auditing and visibility | Recommended audit policy for Windows Event Forwarding | PowerShell logging on Windows

Centralize security telemetry and alert on suspicious activity

Centralized telemetry moves evidence away from the system that generated it and correlates activity across servers, identities, and networks. This improves detection of distributed attacks, limits an intruder's ability to erase local evidence, and shortens response time for credential attacks, lateral movement, persistence, defense evasion, and destructive actions.

Forward security-relevant logs away from each server using Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM such as Microsoft Sentinel, or another protected collection platform. Include Security, System, Windows Defender, PowerShell, Code Integrity, Windows Firewall, Windows LAPS, and role-specific operational logs.

Create actionable alerts for repeated authentication failures, new or changed administrators, unexpected service or scheduled-task creation, security-control changes, Defender detections, App Control blocks, log clearing, unusual remote administration, and backup deletion. Restrict access to collectors and retention systems so an attacker who compromises a server cannot erase the centralized evidence.

Implementation steps: Select Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM, or a combination; define prioritized detection use cases and role-specific retention before selecting log channels and verbosity; design resilient collectors, access control, and capacity; and deploy the required agents or subscriptions. Onboard the prioritized channels, verify end-to-end ingestion and timestamps, create and test high-value detections and notifications, restrict access to the monitoring platform, and continuously monitor collection health and tune noisy rules.

Possible drawbacks: Central collection introduces bandwidth, storage, ingestion, licensing, retention, and analyst costs and can expose sensitive operational data if the monitoring platform is poorly secured. Collector failures create visibility gaps, while poorly tuned rules produce false positives and alert fatigue, so the design needs resilience, health monitoring, access controls, and continuous tuning.

Documentation: Use Windows Event Forwarding for intrusion detection | Microsoft Defender for Endpoint security capabilities

Maintain ransomware-resilient backups and test recovery

Ransomware-resilient backups preserve a trustworthy recovery path when production data, operating systems, or identity services are encrypted, deleted, or corrupted. Isolated and immutable copies mitigate ransomware, destructive administrators, compromised backup credentials, accidental deletion, hardware failure, and attacks intended to eliminate both systems and their recovery data.

Keep multiple protected backup copies, including a copy that is offline, immutable, or otherwise isolated from normal server and domain administrator credentials. Use separate backup administration identities, multifactor authorization for destructive operations, encryption, soft delete or immutability controls, and alerts for policy changes or mass deletion. Hypervisor snapshots alone are not an adequate backup strategy.

Back up application data and configuration as well as system state and bare-metal recovery data where required by the server role. Define recovery-point and recovery-time objectives, test file, application, system-state, and full-server restoration regularly, and record the evidence. Domain controllers, certificate authorities, and other identity infrastructure require workload-aware recovery procedures.

Implementation steps: Classify workloads and define recovery-point and recovery-time objectives, then select local, offsite, offline, and immutable backup targets appropriate to the risk. Use separate backup identities and MFA, schedule application data, configuration, system-state, and bare-metal backups as required, enable encryption and deletion protections, and monitor every job and policy change. Perform regular isolated restore tests that verify application consistency and role-specific recovery semantics for identity systems, not only successful restoration of files or virtual disks, and maintain documented recovery runbooks.

Possible drawbacks: Multiple isolated copies, immutable storage, long retention, and regular restore exercises increase storage, network, licensing, staffing, and operational costs. Backups can create false confidence when they are incomplete, stale, infected, or untested, and strong credential separation can slow routine administration, so restore validation and lifecycle management are as important as backup creation.

Documentation: Design a ransomware-resilient backup architecture | Azure Backup security best practices | Back up Windows Server system state

---

This isn't everything you can do, but it's a start. What other techniques do you use to harden your Windows Server deployments?

Cut Your Azure Blob Storage Bill in Half: A Practical Walkthrough of Object Storage TCO

Pierre_Roman — Wed, 22 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever opened your monthly Azure invoice, stared at the object storage line, and quietly wondered how it grew so much, this one is for you. At the Microsoft Azure Infra Summit 2026, Benedict Berger and George Trossell from the Azure Storage Engineering team walked through a real customer scenario and showed how to bring that bill down without touching a single application.

📺 Watch the session:

Why IT Pros Should Care

Storage is one of those services we configure once at account creation, then never revisit. Redundancy, default tier, lifecycle rules. All decided on day one, then forgotten. Meanwhile, applications get built on top, dashboards get wired up, and the bill keeps climbing in a department nobody really audits.

Here is what you get when you make storage TCO a first-class part of your operating model:

A defensible understanding of capacity, transactions, and data retrieval charges (the three real cost drivers).
Fewer surprise spikes when a cool tier read pattern runs hotter than expected.
Cost optimization that runs on its own, instead of a quarterly cleanup project nobody volunteers for.
Storage standards baked into your Infrastructure as Code, so cost-efficient defaults travel with every new account.

In short, this is one of the highest-leverage cost levers you have in Azure. And unlike compute right-sizing, you can act on most of it from the portal in an afternoon.

What Storage TCO Actually Means on Object Storage, a Technical Overview

When Benedict and George talk about Total Cost of Ownership on Azure Blob Storage, they mean four moving parts:

Capacity. The per-gigabyte cost of the data you store, which varies by access tier and by redundancy.
Transactions. Every read, write, list, and metadata call against the storage account. Priced in packages of 10,000 operations.
Data retrieval. A per-gigabyte fee that applies when you read from cool or cold tiers. It is free on hot.
Network egress. The charge for moving data out of an Azure region.

The trap most teams fall into is looking only at the per-gigabyte capacity column and picking the cheapest tier they see. That ignores the fact that as data gets cooler, transaction and retrieval costs climb sharply, and cold has a 90-day early deletion penalty that can erase your savings outright. Microsoft Learn documents this trade-off clearly in the access tiers overview, where you can see the minimum retention windows and the relationship between storage cost and access cost across hot, cool, cold, and archive.

Redundancy is the other dial. LRS keeps three copies in a single zone. ZRS spreads three copies across three zones in the region. GRS adds an asynchronous secondary in a paired region. The honest tradeoff George highlighted: redundancy protects your data, not your application. If your app is not zone-aware, ZRS alone will not keep you running through a zone outage. And GRS failover is a manual operation in most cases, with the secondary in read-only mode until you stand up new accounts to write into.

How It Works, Under the Hood

The session walked through a worked transaction example that finally made the math click for me. Picture a Spark job uploading 1,000 parquet files of 5 GB each into the hot tier, using an 8 MB block size.

Each 5 GB file is roughly 5,120 MB, divided by 8 MB blocks, which gives 640 put block operations.
One additional put block list call commits the upload, so each object costs 641 write operations.
Times 1,000 files, that is 641,000 operations, which works out to about 3.52 US dollars in that hour just for writes.

Now flip it. Read those same 1,000 files from the cool tier. The transaction count is similar, but you also pay a data retrieval fee on every gigabyte you pull back. That retrieval fee is where most teams get blindsided, because it does not show up on the hot tier at all.

Block size matters too. Larger blocks mean fewer transactions per upload. And for small objects (under 128 KB), there is a new wrinkle to plan for: starting July 2026 for existing accounts and already in effect for new accounts created from July 2025, cooler tiers bill a 128 KB minimum object size. That means a 4 KB log file moved to cool gets charged as if it were 128 KB. The fix is either to leave small objects in hot, or bin-pack them into larger objects (a TAR or ZIP, for example) before tiering them down. The Microsoft Learn page on access tier best practices covers packing strategies in detail.

Real-World Value, Use Cases, and ROI

The customer in the session went from roughly 65,000 US dollars a month to around 25,000. That is not a marketing number, it is what happens when you apply the levers in order:

Right-size redundancy. Move non-production and easily reproducible data off LRS in production. Reserve GRS for the workloads where a compliance regulation actually requires a second region.
Match tiers to access patterns. Use premium for bursty, latency-sensitive workloads. Hot for active reads and writes. Cool and cold only when you genuinely access the data infrequently and have budgeted for the retrieval fees.
Buy reserved capacity for the steady-state portion of your footprint. A one or three year commitment unlocks a discount on block blob capacity. See reserved capacity for Blob storage for terms and tier coverage.
Kill wasteful transactions. Replace polling-for-changes with change feed. Replace recurring list-blob loops with a daily or weekly blob inventory report. Use conditional request headers (If-Modified-Since and friends) so reads skip unchanged objects.
Pack small objects, or leave them in hot. Either is fine; tiering them down without packing is not.

In short, the same scenario, with the same applications, runs at less than half the cost once you actually look at it.

Getting Started

Here is the order of operations I would follow tomorrow morning:

Pull a blob inventory report on your largest storage accounts to see what is actually there: tier mix, object sizes, last modified dates, snapshots, versions.
Open the Azure pricing calculator and model your scenario with realistic transaction counts and retrieval volumes. Do not just compare per-GB prices.
Audit your redundancy choices against the workload. If an account is LRS in production with no easy way to rebuild the data, change it.
Enable Smart Tier on your zone-redundant accounts. New objects start in hot, get demoted to cool after 30 days of inactivity, and to cold after 90, with no charges for tier transitions, early deletions, or data retrieval. Anything accessed gets instantly promoted back to hot.
For accounts that cannot use Smart Tier, write a lifecycle management policy. Keep the rules simple at first: tier down after 30 days, archive after 180, expire snapshots and versions on a schedule.
Convert one of your existing lifecycle policies to ARM or Bicep, then commit it to source control. Add an Azure Policy that flags any new storage account that does not match your standard.

That last step is the one that sticks. As Benedict put it, cost optimization must become part of your system, not an afterthought.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Feeding the GPUs: File Storage for AI and Cloud-Native Workloads on Azure

Pierre_Roman — Tue, 21 Jul 2026 07:00:00 GMT

Hello Folks!

If you are running AI workloads on Azure, you have probably learned the hard way that the wrong storage choice can leave a rack of very expensive GPUs sitting idle, waiting for data. In this session during the Microsoft Azure Infra Summit 2026, Wolfgang de Salvador and Reena Shah from the Azure Storage team walked through how Azure Managed Lustre and Azure Files map to the distinct stages of the AI pipeline, and why picking the right file system per stage is one of the highest leverage decisions you will make.

📺 Watch the session:

Why IT Pros Should Care

You probably did not get into IT to babysit checkpoint writes or debug Hugging Face egress bills at 2 a.m. But that is exactly the kind of work that lands on your plate when storage is not matched to the workload. Here is why MAIS28 matters for the IT pros, platform engineers, and Azure architects in the room:

GPU time is the most expensive compute you will ever buy. Slow data loading and slow checkpoints turn that into burned cash.
AI workloads are not one workload. Data prep, training, fine-tuning, and inferencing each have a different storage profile.
Cloud-native AI on AKS and Azure Container Apps lives or dies on the ReadWriteMany experience. If model loading is slow or shared model caches do not exist, every cold start re-downloads hundreds of gigabytes.
Storage choices ripple into security and compliance. Encryption in transit, redundancy, and snapshots are not optional in 2026.

In short, this session is for anyone who has to answer the question, “What persistent volume should we use for this AI workload?” and wants a defensible answer.

What Azure Brings to the Table, Technical Overview

Wolfgang opened with the storage profile of every stage of an AI workflow. Data preparation needs hundreds of petabytes at the best TCO (think Azure Blob Storage as the durable core). Training and fine-tuning need extreme throughput so GPUs stay fed during data loading and so checkpoint writes complete fast. Inferencing needs fast model loads, low-latency KV cache, and grounded data for RAG. One filesystem does not fit all of those at once, and trying to make it fit is where teams overspend.

Azure’s answer is a tiered, file-based portfolio that lines up with those stages:

Azure Managed Lustre (AMLFS) is a fully managed, accelerator-tier filesystem. It scales to 25 PB of capacity and up to 512 GB/s of throughput, integrates with Azure Blob Storage as the durable core, and exposes a standard Lustre client plus a CSI driver for AKS.
Azure Files is the natural ReadWriteMany choice for cloud-native AI on AKS and Azure Container Apps. It tops out at 256 TB of capacity and 10.4 GB/s of throughput, offers LRS and ZRS redundancy with snapshots and soft delete, and ships with a 99.99% SLA.
Azure Blob Storage sits underneath both of these as the cheap, durable core for data prep and long-term retention.

The mental model the speakers used is “accelerator and core”. Blob is the core, durable and economical. AMLFS is the accelerator for training. Azure Files is the accelerator for inferencing and shared state. Pick the right pair for the stage you are running.

How It Works, Under the Hood

For training, Wolfgang showed the demo most folks came to see: a 32 x H100 ND H100 v5 AKS cluster deployed from the Azure AI Infrastructure repository, running a 30B-parameter GPT-3 training job backed by AMLFS. Two things matter here.

First, AMLFS absorbs checkpoint write bursts. When 32 H100s flush state at the same time, you need a filesystem that can take the punch without stalling. AMLFS does, which keeps GPU utilization drops short and contained.

Second, the AMLFS Lustre CSI driver for AKS supports both static and dynamic provisioning with availability-zone placement, and there are five SKU tiers from MLFS20 (cheapest by capacity) to MLFS500 (cheapest by bandwidth). That means you can pick a cost-performance point that matches your training budget instead of buying the top SKU and hoping for the best.

For inferencing, Reena’s half of the session was just as practical. Five reasons Azure Files fits AKS ReadWriteMany workloads:

Standard Kubernetes RWM volume over NFS or SMB.
256 TB capacity ceiling and up to 10.4 GB/s of throughput per share.
LRS or ZRS redundancy with snapshots and soft delete for protection.
99.99% SLA so it shows up in your availability math.
Native support across AKS and Azure Container Apps, including serverless GPU.

The headline feature is Azure Files Provisioned v2. In the old model, IOPS and throughput were a function of how much capacity you provisioned, which is wrong for AI shapes that need small capacity but very high IOPS and bandwidth. Provisioned v2 splits capacity, IOPS, and throughput into three independent knobs you can dial without downtime or remount. That alone changes the economics for a lot of inferencing patterns.

The other big inferencing feature is NFS v4.1 encryption in transit, delivered with the az-nfs utility and stunnel. You get AES-GCM TLS protection on the wire, with no Kerberos and no Active Directory needed, and the application has no idea it is happening. Reena’s live demo showed an AKS pod with an encrypted NFS mount, transparent to the workload.

And then the pattern that ties it together: the shared model cache. Download the model once into Azure Files, mount it across every replica via ReadWriteMany. No per-pod cold start, no re-download from Hugging Face, no egress bill. The demo used GPT-OSS 120B with VLLM on 32 x H100, and the pattern scales down to small fine-tuned models running on serverless GPU in Azure Container Apps.

Real-World Value

The session closed with the Viton case study. Viton is a Paris-based fashion AI startup. Their image-generation platform runs on Azure Container Apps serverless GPU, with Azure Service Bus for job routing and Azure Files NFS as the shared model store. Workers pull jobs, mount the shared model cache, generate the image, and scale to zero when the queue drains. The economics only work because they are not paying to re-download the model on every cold start, and because they only pay for GPU when there is work to do.

The same pattern shows up across customer scenarios:

Training a foundation model on AKS with AMLFS as the scratch tier and Blob as the durable archive.
Fine-tuning smaller models where AMLFS checkpoints absorb the write bursts and the final artifact lands back in Blob.
Inferencing with VLLM on AKS where Azure Files holds the model weights once and every replica reads from the same RWM mount.
Serverless inferencing on Azure Container Apps with the same shared model cache pattern, but with scale-to-zero economics.

Honest tradeoff: Lustre is not the right filesystem for a 10-pod web app, and Azure Files is not the right filesystem for a 32-GPU training run. The whole point of the tiering is that you pick the right one per stage. Do not try to make one filesystem do all four jobs.

Getting Started

If you want to put this into practice this week:

Go to the Azure AI Infrastructure repository on GitHub. Wolfgang’s demo cluster came straight out of it, and you can spin up an AI-ready AKS cluster with GPU and InfiniBand operators in your own dev/test subscription.
Install the Azure Managed Lustre CSI driver on AKS if you are running training or fine-tuning. Start with a smaller MLFS SKU and size up.
Turn on Azure Files Provisioned v2 on a new share, then dial capacity, IOPS, and throughput independently to match your inferencing shape.
Enable NFS v4.1 encryption in transit with az-nfs and stunnel before you put any sensitive workload on the wire.
Try the shared model cache pattern. Pick one VLLM deployment, point it at an Azure Files RWM mount, and measure cold start time before and after.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Premium SSD v2 and Instant Access Snapshots: A Better, Faster, Cheaper Disk for Your Azure VMs

Pierre_Roman — Mon, 20 Jul 2026 07:00:00 GMT

Hello Folks!

If you have been running Premium SSD v1 because that is just what you have always done, this session from the Microsoft Azure Infra Summit 2026 is going to be a wake up call. Raymond Lui and Adam Li from the Azure Disk Storage team walked us through Premium SSD v2 (PV2 for short) and the new Instant Access Snapshots, and the punchline is simple. PV2 is faster, it is cheaper, and the operational story around it just keeps getting better.

📺 Watch the session:

Why IT Pros Should Care

If you are an infrastructure person, a SQL DBA, an SAP Basis admin, or anyone who has ever had to right-size a VM around its storage tier, this matters to you. In short, Premium SSD v2 changes the rules around how you provision block storage in Azure. Here is what stood out from the session:

4x more IOPS and 2x more throughput compared to Premium SSD v1, on a matched configuration that costs 42% less.
Sub-millisecond average latency, with a top configuration of 800,000 IOPS and 20 GB/s of throughput on a single VM.
Capacity, IOPS, and throughput are decoupled. You dial each one independently, in 1 GB increments, instead of buying a tiered SKU.
3,000 baseline IOPS and 125 MB/s throughput included on every disk, with no extra cost.
Live Resize. You can grow disk size, IOPS, or throughput on a running VM with no restart required.
Instant Access Snapshots make restores feel actually instant, with up to 10x faster hydration and 90% lower read latency during hydration.

That is a lot of wins on one slide. Let’s break it down.

What Premium SSD v2 Is, Technical Overview

Premium SSD v2 is Azure’s purpose-built block storage for I/O-intensive enterprise workloads. Microsoft Learn describes it as designed for workloads that need sub-millisecond disk latency, high IOPS, and high throughput at a low cost. The target list is broad: SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data and analytics, gaming, and stateful containers running on AKS.

The architectural shift that Raymond highlighted is independent scaling. With Premium SSD v1, you bought a fixed SKU. If you wanted more IOPS, you had to buy more capacity, even if you did not need it. With PV2, capacity, IOPS, and throughput are three separate dials. You provision capacity in 1 GB increments, then you set IOPS and throughput to match what your workload actually needs. If you over-provisioned, you tune it down. If you under-provisioned, you tune it up, and the VM keeps running.

Raymond highlighted three primary use cases in the session:

SAP workloads, including SAP application VMs, SAP HANA databases, and non-HANA databases like Oracle, DB2, and SQL Server in SAP environments.
SQL Server. According to a GigaOM benchmark cited in the session, SQL Server on PV2 delivered 51% more transactions per second and 39% lower cost per transaction compared to AWS EC2, with a 9% lower 3-year TCO.
Big data and analytics replacing local SSD. This one is a bit of a surprise. On D-series VMs, PV2 delivered over 1,400 MB/s of throughput compared to 720 MB/s from local SSD. That means you can run Spark or Databricks workloads on cheaper VM SKUs (without local storage) and still get more performance than you had before.

Premium SSD v2 supports a 4k physical sector size by default, with 512E available for legacy applications. There are a few honest tradeoffs to know about. PV2 disks cannot be used as an OS disk, and they cannot be used with Azure Compute Gallery. PV2 also does not support host caching. For regions with availability zones, PV2 disks can only be attached to zonal VMs, so plan your VM placement accordingly.

How It Works, Under the Hood

Raymond covered the architecture briefly, and it is worth understanding. PV2 uses direct VM-to-storage-node communication, with 3-replica durability behind the scenes. That direct path is part of how it gets sub-millisecond latency consistently.

For Instant Access Snapshots, Adam walked through the architectural difference between the classic incremental snapshot path and the new Instant Access path. With classic incremental snapshots for PV2 and Ultra Disk, the snapshot is created, then the data has to copy in the background to Standard HDD before the snapshot is usable for restore. That copy could take a while on a large disk, and restored disks would then hydrate slowly, which dragged down read latency until hydration finished.

With Instant Access, the snapshot is usable the moment it exists. The data stays in the same high-performance storage as the source disk for a configurable duration (60 to 300 minutes, controlled by the InstantAccessDurationMins parameter). At the same time, Azure copies the snapshot data to Standard ZRS in the background for long-term retention. When the Instant Access window expires, the snapshot transitions to a regular incremental snapshot, sitting on cheap durable storage. You get the speed and the long-term durability without running two separate workflows.

In short, your VM can boot and run at near-full performance while the data hydrates in the background. There are some limits to keep in mind. Instant Access counts toward the existing limit of three in-progress snapshots per disk, and you can create up to 15 disks concurrently from all instant access snapshots of a single disk.

Real-World Value (Use Cases, ROI, Scenarios)

Adam closed his portion of the session with a BCDR demo. He cloned 12 disks of an M-series production database into a recovery VM, attached them, and was immediately running roughly 500,000 IOPS at single-digit-millisecond latency. No waiting for hydration. No degraded performance window. That is a meaningful improvement to your Recovery Time Objective (RTO).

A few scenarios where this combination really pays off:

Pre-deployment safety nets. Take an instant access snapshot before a big upgrade. If something goes sideways, roll back in seconds instead of hours.
Rapid scale-out for stateful apps. Spin up multiple disk copies of a primary instance in seconds. You can even place them across availability zones in the same region.
Dev/test environment refresh. Clone production into dev or test on demand, with full performance from the first I/O. No more “we’ll refresh dev next quarter” because the restore takes too long.
SAP HANA always-on operations. Live Resize means you can scale IOPS or throughput up on a running database during a load spike, without a maintenance window.
Right-sizing to cut spend. If you have been paying for VM SKUs purely to get local SSD throughput, PV2 may let you drop to a smaller, cheaper VM and still hit higher numbers.

One nuance came up in the live Q&A. Jens asked a great question about profiling: how do you know when PV2 is the right choice versus Standard SSD? Raymond’s guidance was direct. If the workload needs high IOPS or high throughput, PV2 is generally the right call. The VM SKU also needs to support “Premium Disk” capability for PV2 to attach, so check that compatibility first.

Getting Started

Concrete first steps so you can start kicking the tires:

Confirm region and zone support. Use az vm list-skus --resource-type disks --query "[?name=='PremiumV2_LRS']" to see which regions and availability zones are supported in your subscription.
Pick a Premium-capable VM in a supported zone. Remember, PV2 is zonal in AZ regions. Decide on the zone before you create the VM.
Provision a disk. Start with default performance (3,000 IOPS, 125 MB/s) and a small capacity. You are paying for the dials you turn up; defaults are reasonable for most starting points.
Plan your v1 to v2 migration. Raymond demoed two paths. Option A: detach the disk from a running VM and convert it (the VM keeps running on its other disks). Option B: stop and deallocate the VM, then convert in place. Both preserve data, and you can raise IOPS and throughput as part of the conversion.
Try Instant Access Snapshots. Add --instant-access-duration-in-minutes (or the equivalent ARM/PowerShell parameter) to your existing snapshot command. That is all the change you need to enable it.
For AKS users, define a storage class with skuName: PremiumV2_LRS and let dynamic provisioning take it from there.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Network Security Perimeter for Azure Event Hubs: Hardening Your Data Streams

Pierre_Roman — Fri, 17 Jul 2026 20:26:45 GMT

What is Network Security Perimeter for Azure Event Hubs?

Azure Event Hubs now supports Network Security Perimeter (NSP), a logical network isolation boundary that lets you define a security perimeter around your PaaS resources and control public network access through perimeter-based access rules.

In practical terms, this means you can now group Event Hubs resources within a perimeter, apply consistent network access policies across them, and prevent unauthorized inbound traffic at the PaaS boundary level. It's not a firewall replacement, it's a compliance and segmentation tool that works alongside your existing NSGs and private endpoints.

Before NSP, managing network access to Event Hubs involved:

Private endpoints (which route traffic over private networks)
IP firewall rules (which block public access from specific CIDR blocks)
Virtual Network Service Endpoints (which restrict traffic to VNets)

Network Security Perimeter adds a declarative, organization-wide layer: you define which resources belong inside the perimeter, and then manage access rules once, and those policies apply consistently across all perimeter members. Changes to the perimeter automatically cascade to all enrolled resources.

Why ITPros Should Care

If you're managing Event Hubs in a regulated industry like healthcare, finance, or government, you know the pressure. Compliance auditors want proof that data pipelines are segmented, isolated, and protected from lateral movement. Network Security Perimeter directly addresses that.

Operational Value

Network Security Perimeter delivers three immediate operational wins:

Single Source of Truth for Access Rules. Instead of managing firewall rules on each Event Hubs namespace independently, you manage rules once at the perimeter level. Reduce configuration drift, reduce the attack surface, reduce human error.
Compliance and Audit Readiness. Demonstrate network isolation to auditors with a clear diagram: "All Event Hubs in the perimeter are protected by these rules." That narrative matters for SOC 2, FedRAMP, HIPAA, and PCI-DSS compliance. You can export perimeter configurations and attach them to compliance documentation.
Simplified Onboarding. When a new Event Hubs namespace joins the organization, add it to the perimeter and it inherits all access rules automatically. No manual rule-by-rule configuration. No weeks of back-and-forth with security teams.

Secondary benefits include:

Reduced blast radius during incidents, if an application is compromised, perimeter rules limit what it can access.
Simplified network topology diagrams for architecture reviews.
Faster mean time to remediation (MTTR) when security issues arise.

Real-World Example: Securing a Multi-Tenant Event Hub Deployment

Let's walk through a practical scenario. You're an ITPro at a financial services firm. You have three Event Hubs namespaces:

hubs-prod-transactions (production trading data)
hubs-prod-compliance (regulatory event streams)
hubs-staging-dev (development and testing)

Your security policy mandates:

Production namespaces should only accept traffic from specific applications (IP-restricted).
Staging can accept traffic from developer VNets but not from the internet.
All outbound access to external services must be logged and monitored.

Step 1: Define Your Perimeter

First, create a Network Security Perimeter in the Azure Portal or via Azure CLI:

az network perimeter create --resource-group rg-security --name nsp-financialservices --location eastus

This creates the perimeter container. Think of it as a logical security zone.

Step 2: Enroll Event Hubs Resources

Add your Event Hubs namespaces to the perimeter:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-prod-apps --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.0.0.0/8 --destination-port-range 5671-5672

Enroll the Event Hubs namespace:

az network perimeter resource create --resource-group rg-security --perimeter-name nsp-financialservices --resource-name hubs-prod-transactions --resource-type "Microsoft.EventHub/namespaces"

You've now enrolled your production Event Hubs namespace. It inherits the "allow-prod-apps" rule, only traffic from your internal VNET (10.0.0.0/8) is permitted.

Step 3: Define Access Rules

$ns = "hubs-prod-transactions" $hub = "transactions-hub" $key = (az eventhubs namespace authorization-rule keys list --resource-group rg-prod --namespace-name $ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv)

Create rules that reflect your security policy. Allow internal compliance applications:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-compliance-writers --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.50.0.0/16 --destination-port-range 5671-5672

Deny all other public traffic:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name deny-internet --direction Inbound --access Deny --protocols "*" --source-address-prefix "*" --destination-port-range "*"

Now your Event Hubs accept traffic only from specific internal subnets. Everything else is rejected at the PaaS boundary.

Step 4: Validate Connectivity

Test that legitimate applications can still reach Event Hubs:

Check logs in Azure Monitor:

az monitor log-analytics query --workspace $(az monitor log-analytics workspace list --query "[0].id" -o tsv) --analytics-query "AzureDiagnostics | where ResourceProvider=='MICROSOFT.EVENTHUB' | summarize by NetworkSecurityPerimeter_s"

If you see accepted connections logged with your perimeter name, you're good. If you see denied connections from unexpected IPs, you've caught a security issue before it impacts production.

Step 5: Monitor and Alert

Set up alerts for denied traffic:

az monitor metrics alert create --name "NSP-Denied-Connections" --resource-group rg-security --scopes /subscriptions/{subId}/resourceGroups/rg-security/providers/Microsoft.Network/networkSecurityPerimeters/nsp-financialservices --condition "avg ConnectionRejectedCount > 5" --window-size 5m --evaluation-frequency 1m --action email-admin@company.com

Now you'll be notified if someone attempts to access Event Hubs from an unauthorized source. Your security posture just went from reactive to proactive.

Technical Details: How NSP Works Under the Hood

Perimeter Architecture

Network Security Perimeter operates at the Azure platform level, not in your VNets. Here's the flow:

Connection arrives at Event Hubs public IP.
Azure evaluates the source IP/protocol against NSP rules.
If allowed, connection is routed to the namespace.
If denied, connection is dropped and logged.

This happens before TLS handshake, reducing CPU overhead and improving response times. Denied connections generate zero namespace load.

Rule Evaluation Order

NSP rules are evaluated in this order:

Explicit Allow rules (matched first wins)
Explicit Deny rules
Implicit Deny (default action)

Best practice: Create your Allow rules first (be specific about what you permit), then add Deny rules for anything not explicitly allowed. This ensures you don't accidentally block legitimate traffic.

Integration with Existing Security Tools

NSP works alongside (not instead of):

Private Endpoints: NSP adds a policy layer; private endpoints route traffic over Azure backbone. Use both.
IP Firewall: NSP provides namespace-level access control; IP firewall is still available for per-namespace rules.
VNet Service Endpoints: NSP complements VNet endpoints by adding perimeter-wide policies.
Managed Identity + RBAC: NSP is transport-layer security; identity-based access control remains separate.

Performance Considerations

NSP introduces minimal latency (<1ms typically). Azure evaluates rules in parallel and caches common decisions. For high-throughput Event Hubs:

Keep rules simple and specific (avoid wildcard ranges if possible).
Use CIDR blocks instead of individual IPs where applicable.
Monitor connection acceptance rates in Azure Monitor.

Comprehensive Resources

Official Microsoft Documentation:

Closing: Perimeter Security for Modern Data Streams

Network Security Perimeter for Event Hubs is a quiet but powerful addition to Azure's security toolkit. You get the ability to enforce organization-wide network policies without having to reconfigure every namespace individually. You can demonstrate perimeter-based isolation to auditors. You can catch lateral-movement attacks before they happen.

For ITPros managing event-driven architectures, message processors, IoT data streams, financial transactions, this capability directly improves your security posture and reduces operational overhead.

I encourage you to:

Audit your current Event Hubs deployments. How many namespaces? How many security policies are you managing today?
Design your perimeter boundaries. Group namespaces by security zone (prod, staging, dev) or by business unit.
Start with one perimeter in a dev environment. Define rules. Validate connectivity. Then expand to staging and production.
Document your perimeter architecture and rules. Include it in your security runbook and architecture reviews.
Set up monitoring and alerting. Denied connections are a leading indicator of either misconfiguration or attack attempts.

The networking challenges in cloud are complex. Network Security Perimeter gives you a declarative, policy-driven way to solve them at scale. Take advantage of it, and let me know how it changes your security workflows.

Keep your networks hardened, and your data flowing safe.

Cheers!

Pierre Roman

Az Update - Week 2 of the return editions

Pierre_Roman — Fri, 17 Jul 2026 18:37:42 GMT

Hello Folks!

This week's updates all focus on something we hear from IT pros and platform engineers all the time:

How do we make our environments more secure, more manageable, and easier to modernize without adding more complexity?

Whether you're running PostgreSQL workloads in Azure, securing Kubernetes storage, or planning your next wave of SQL Server migrations, this week's announcements bring practical improvements that can help reduce operational overhead while strengthening your overall platform strategy.

We'll look at three newly available capabilities:

Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server
Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)
Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

As always, I'm approaching these updates from an infrastructure and operations perspective. I'll cover why each capability matters, what to watch out for before production deployment, and some practical steps you can take to start evaluating them in your own environment.

Let's dig in.

Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server

Why ITPros should care

This release brings automated security posture assessment directly into managed PostgreSQL environments. For ITPros, this matters because database security is often treated separately from infrastructure security tooling, creating blind spots and silos.

What changed is that Defender now runs native vulnerability scanning and compliance checks against PostgreSQL configurations, patches, and the ways a database could be exposed to security risks or attack opportunities. Instead of relying on external scanners or manual audits, you get platform-native assessments integrated with your existing Defender workflows.

The operational impact is significant: you can now enforce security baselines at the database layer with the same consistency you apply to VMs and network resources, reducing the gap between infrastructure and data security accountability.

Operational value

Operationally, this improves your security baseline enforcement and reduces the need for separate database security assessment tools. It also strengthens how well you can demonstrate and prove that security controls are in place and working for compliance reviews where regulators expect consistent, documented security controls.

Before production rollout, validate that Defender cost models fit your budget, that assessment frequency aligns with your change windows, and that remediation guidance maps to your patch and maintenance processes.

Prerequisites include enabling Microsoft Defender for Cloud, registering the PostgreSQL Flexible Server provider, and ensuring network connectivity so assessments can reach the database endpoint.

Real-world example with step-by-step guidance

Enable Microsoft Defender for Cloud if not already active, and ensure PostgreSQL Flexible Server subscription coverage.
Register the target PostgreSQL Flexible Server instances and confirm Defender has network visibility to the database endpoints.
Run a baseline assessment and review initial findings to understand current security posture and common remediation patterns.
Prioritise findings by severity and business impact, then schedule patches and configuration changes in maintenance windows.
Monitor ongoing assessments and track remediation progress through Defender dashboards, validating that fixes reduce exposure scores.

Technical details including code examples

This example validates that Defender is actively assessing your PostgreSQL estate. The sequence checks Defender status, confirms PostgreSQL registration, and retrieves current assessment scores.

Run these queries in a pilot subscription first to understand data structure and expected output before scaling to production databases.

az account set --subscription <subscriptionId> az security sql-vulnerability-assessment baseline show --resource-group <rg> --server-name <postgresServer> --database-name <databaseName> az security pricing show --subscription <subscriptionId> --query "[?name=='VirtualMachines' || name=='SqlServers' || name=='StorageAccounts'].[name,pricingTier]" -o table az provider show --namespace Microsoft.DBforPostgreSQL --query "registrationState" -o tsv

Expected behaviour: Defender status shows active, PostgreSQL instances are registered with the provider, and pricing tier reflects your coverage level. If assessments do not run, check network rules, managed identity permissions, and Defender plan activation. If baseline data is missing, trigger a manual scan and wait for completion.

Comprehensive Resources

Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)

Why ITPros should care

This release closes a significant gap in data protection for Kubernetes workloads consuming NFS shares from Azure Files. Previously, NFS traffic between AKS nodes and Azure Files was unencrypted, creating compliance and security risks for sensitive workloads.

What changed is that you can now enforce encryption for NFS communication at the Azure Files layer, not just at the application layer. This is important because traditional NFS lacks built-in encryption, and relying on network isolation alone is increasingly insufficient.

For ITPros managing regulated workloads (healthcare, finance, PII-sensitive data), this removes a control gap. Encryption in transit now becomes a platform-native feature instead of a workaround, reducing architecture complexity and improving auditability.

Operational value

The operational value is stronger compliance posture and reduced attack surface for data in motion between containers and storage. It also simplifies the security story when auditors ask about data protection controls.

Before enabling in production, validate that NFS-over-TLS introduces acceptable latency overhead for your workload patterns, test failover and reconnection behaviour under encryption, and confirm that monitoring and logging still work correctly.

Prerequisites include running AKS with Azure CNI or Kubenet networking, having Azure Files with NFS 4.1 enabled, and ensuring the NFS client libraries on container images support TLS.

Real-world example with step-by-step guidance

Create an Azure Files NFS share with encryption in transit enabled and confirm TLS version alignment with your security standards.
Deploy a test AKS workload that mounts the NFS share and validate that pods mount successfully with encrypted traffic.
Run performance baselines (throughput, latency, CPU overhead) before and after enabling encryption to document operational expectations.
Monitor pod logs and Azure Files metrics during the test to confirm no silent failures or unexpected throttling occurs.
Roll out to production workloads in stages, with clear rollback criteria tied to application latency and error rates.

Technical details including code examples

This example validates that your AKS cluster can successfully mount NFS shares with encryption enabled. The sequence checks cluster networking, confirms NFS connectivity, and tests mount success.

Run these commands in a non-production cluster first to validate environment readiness before touching production storage.

az aks show --resource-group <rg> --name <clusterName> --query "networkProfile.{networkPlugin:networkPlugin,networkPolicy:networkPolicy,podCidr:podCidr}" -o jsonc az storage account show --resource-group <rg> --name <storageAccount> --query "{name:name,kind:kind,accessTier:accessTier}" -o jsonc kubectl get pvc -A --all-namespaces -o wide kubectl describe pv <pvName> | grep -i nfs

Expected behaviour: cluster networking is properly configured, storage account kind supports NFS, and PVC/PV resources show NFS mount points. If mounts fail, check network security group rules, storage account firewall allowances, and subnet delegation. If latency increases, monitor resource utilisation and adjust workload placement if needed.

Comprehensive Resources

Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

Why ITPros should care

This capability brings SQL Server migration into the Azure Arc operational footprint, creating a unified migration and inventory experience. For ITPros, this matters because SQL Server modernisation is often fragmented across multiple tools and teams.

What changed is that you can now discover, assess, and execute SQL migrations through Arc-native workflows, using the same permissions and governance model you already have for infrastructure and hybrid resources.

The operational gain is consistency: discovery data feeds migration planning, assessments surface blockers early, and rollout can be controlled through the same change and approvals processes you use for other infrastructure migrations.

Operational value

Operationally, this reduces tooling sprawl and improves coordination between infrastructure and database teams. Arc becomes your single control plane for tracking migration progress, managing runbooks, and collecting audit evidence.

Before production use, validate that your SQL Server inventory is complete, that migration blockers are understood and addressed, and that your maintenance windows can accommodate expected cutover timings.

Prerequisites include Azure Arc agent deployment on source VMs, Azure Database Migration Service readiness, and network connectivity to target Azure SQL resources.

Real-world example with step-by-step guidance

Deploy Azure Arc agents to SQL Server VMs and confirm all instances report healthy status with complete inventory data.
Run Arc-integrated SQL Server assessments to identify compatibility issues, dependencies, and recommended migration targets.
Pilot migration for a non-critical workload to establish runbook patterns, measure cutover time, and validate post-migration validation procedures.
Execute validation tests: connectivity, login success, database consistency checks, job execution, and application integration tests.
Scale migration in waves using documented runbooks, with gates for monitoring data health and application performance after each cutover.

Technical details including code examples

This example validates Arc agent health and SQL Server discovery completeness. The sequence ensures your Arc infrastructure is ready for migration workflows.

Run these commands as part of your pre-migration checklist to catch configuration gaps before committing to migration timelines.

az account show --output table az connectedmachine list --resource-group <rg> --query "[].{name:name,status:status,osName:osName}" -o table az resource list --resource-type Microsoft.AzureArcData/sqlServerInstances --query "[].{name:name,resourceGroup:resourceGroup,location:location}" -o table az connectedmachine machine extension list --resource-group <rg> --machine-name <vmName> --query "[].{name:name,provisioningState:provisioningState}" -o table

Expected behaviour: Arc agents report healthy status, SQL Server instances are fully discovered with accurate inventory, and required extensions are provisioned successfully. If discovery is incomplete, check Arc agent connectivity, extension deployment, and SQL service running status on source VMs. If migration pre-checks fail, verify SQL Server version compatibility and review Defender logs for blocking issues.

Comprehensive Resources

For any new capability this week, if they map to your operational roadmap, run a controlled pilot, measure the impact, and then scale with confidence. That is how you move the needle on modernisation while managing risk.

Cheers!

Pierre Roman

Azure Elastic SAN: Pooled, Cloud-Native Block Storage That Actually Acts Like a SAN

Pierre_Roman — Fri, 17 Jul 2026 07:15:00 GMT

Hello Folks!

If you have ever lived through a Friday night SAN expansion, racking new shelves and praying the zoning held together, the idea of getting that same shared block storage model in Azure (without owning a single fibre channel cable) sounds almost too good to be true. In his session at the Microsoft Azure Infra Summit 2026, Kiran Cherukuwada, Principal PM in Azure Storage, walked us through exactly how Azure Elastic SAN does that, and where it fits next to the other block storage options on Azure.

📺 Watch the session:

Why IT Pros Should Care

Most of us were taught a simple rule. One workload, one disk, size it for peak, move on. That rule has been kind to managed disks, but it gets expensive fast when you have dozens or hundreds of workloads that all peak at different times. Elastic SAN flips the model. You provision a pool of capacity and performance once, then carve volumes out of it for many workloads.

Here is why that matters for IT pros:

You stop over-provisioning each workload to its own peak; the SAN absorbs the bursts.
You get a SAN-style resource hierarchy (SAN, volume groups, volumes) that looks and behaves like the on-prem model you already know.
iSCSI connectivity means a wide compute footprint, including Azure Virtual Machines, Azure Kubernetes Service, Azure Container Instances, Azure VMware Solution, and Nutanix Cloud Clusters.
You can drive storage throughput over VM network bandwidth, which often lets you keep a smaller (and cheaper) VM SKU.

In short, if you have many IO-intensive workloads sharing one region, Elastic SAN is the lever that turns “buy peak for every workload” into “buy combined peak for the group.”

What Azure Elastic SAN Is, Technical Overview

Azure Elastic SAN is the industry’s first fully managed SAN storage service in the cloud. It brings the on-prem SAN consumption model to Azure as a single managed pool of block storage, shared across many workloads, accessed over the industry-standard iSCSI protocol.

Inside the service you get three resources, matching the on-prem mental model:

The Elastic SAN itself. Top-level resource. This is where you provision overall capacity and performance, and where billing happens.
Volume groups. Where you set network rules (service or private endpoints) and security policies. Any policy you apply here is inherited by every volume in the group, so a volume group is effectively your workload boundary.
Volumes. The LUNs that you mount on compute. They show up as raw block devices on a VM, as iSCSI targets to a Kubernetes node, or as VMware data stores on AVS.

A single SAN can scale to a petabyte of capacity, 2 million IOPS, and 80 GB/s of throughput. It is locally redundant by default, with a zone-redundant option, and shared volume support is there for clustered solutions like SQL Server Failover Cluster Instances and Azure VMware Solution. Network isolation is delivered via service endpoints and private endpoints, and data is encrypted at rest. Incremental snapshots are supported for fast point-in-time restore, and snapshots can be exported to managed disk snapshots when you need a hardened copy for backup or DR purposes.

Where does it land in the block storage portfolio? Kiran framed it simply. Premium SSD v2 is the best price/performance for dedicated per-workload performance. Ultra Disk is for the mission-critical, every-microsecond-matters workloads. Elastic SAN is the best price/performance option at scale, when you have many workloads that can share a storage pool.

How It Works, Under the Hood

The economics live in the provisioning model. You buy two types of units:

Base unit. Each base unit gives you 1 TiB of capacity plus 5,000 IOPS and 200 MB/s. Roughly 8 cents per GiB per month in East US.
Capacity-only unit. Each capacity-only unit gives you 1 TiB of capacity but no extra performance. About 25 percent cheaper, around 6 cents per GiB per month in East US.

The pattern Kiran showed is “size for performance first, then top up capacity.” A 250 TiB SAN delivering 1 million IOPS and 40 GB/s came out to roughly 200 base units plus 50 capacity-only units, landing around 20 grand per month for the whole pool.

The magic ingredient is dynamic performance sharing. With traditional disks you provision each workload to its own peak. With Elastic SAN, you provision the combined peak. So a SQL Server needing 60,000 IOPS, an AVS cluster needing 40,000, and an Oracle workload needing 100,000 IOPS look like 200,000 IOPS of dedicated disk. But if they never peak simultaneously, you can land a 150,000 IOPS SAN and let each workload hit its peak on demand. That is real money back.

The second lever is throughput over network bandwidth. Because Elastic SAN connects over iSCSI, storage I/O flows through the VM’s network pipe, not the VM’s disk throughput cap. Most VMs have far more network bandwidth than disk bandwidth, so you can drive higher storage throughput from a smaller VM SKU. That smaller SKU is cheaper to run, and (this is the quiet win) it can also cut per-core database licensing costs. As one attendee asked in the live Q&A, “Why is it possible to go beyond the VM disk throughput limit with SAN?” The answer: iSCSI traffic uses VM network bandwidth like any other VM-to-VM traffic, so the disk throttle does not apply.

One honest tradeoff: that same network bandwidth is also used by your app-tier-to-database traffic. So if you are planning to push storage hard, size the VM with both flows in mind.

Real-World Value

Where does this actually pay off?

Mixed enterprise workloads on Azure VMs. SQL Server, Oracle, custom OLTP, sharing one SAN. Kiran’s demo ran SQL TPCC, an AVS cluster benchmark, and an Oracle OLTP load simultaneously off a single 30-base-unit SAN, and the metrics blade showed exactly how each volume group consumed performance.
Extending Azure VMware Solution storage. Instead of buying expensive vSAN nodes just to grow storage, you connect AVS to an Elastic SAN datastore. Gen2 AVS private clouds skip the ExpressRoute gateway requirement and let you use a single private endpoint on the volume group.
Container Storage. Azure Container Storage v2 with Elastic SAN backing is generally available. The fast attach and detach behavior means that even if a node or cluster goes down, the data sits on the SAN and persists.
Lift and shift from on-prem SAN. Kiran shared one migration example: a workload with 100-plus vCPUs running off a mid-tier all-flash SAN array landed on Elastic SAN with roughly 64 percent TCO savings and performance that exceeded the original array.

In short, this is a “many workloads, one pool” story. If you have one heavy workload, premium SSD v2 may be a better fit.

Getting Started

Here is a practical order of operations:

Size the SAN. Add up the combined peak IOPS and throughput for the workloads you plan to consolidate, then pick base units to cover performance and capacity-only units to top up storage.
Lock down the network. Access is closed by default. Choose service endpoints or private endpoints per volume group, and open them only to the right subnets.
Place compute in the same zone. For best latency, deploy your VMs (or AVS cluster) in the same region and availability zone as the SAN.
Tune the client. Use Gen 5 (D, E, or M series) VMs with Accelerated Networking on, configure the iSCSI initiator, set up native MPIO on Windows or Linux, and use the Connect scripts from the portal which default to 32 sessions per volume.
Watch the metrics. The SAN’s Metrics tab shows transactions, ingress, and egress at the SAN, volume group, and individual volume level. Drop the granularity to one minute when you are troubleshooting.
Plan snapshots. Use Elastic SAN volume snapshots for fast dev/test restores. Export to managed disk snapshots when you need hardened backup or cross-region DR.

If you are coming from on-prem, the partnership with Cirrus Data (free in the Azure Marketplace) is the recommended path to migrate storage at the block level.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

When Compute Sits and Waits: Fixing the Hidden Storage Bottleneck in EDA and HPC with Azure NetApp Files

Pierre_Roman — Thu, 16 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever stared at an HPC pipeline and wondered why the queue depth keeps climbing while every CPU graph looks lazy, this session from the Microsoft Azure Infrastructure Summit 2026 is going to feel very familiar. Ron Hogue from the Azure Storage team and Ranga Sankar from NetApp spend twenty-seven minutes diagnosing the problem that nobody wants to admit out loud, that the bottleneck is not compute, not the scheduler, and not licenses. It is storage. And then they walk through exactly how Azure NetApp Files (ANF) solves it.

📺 Watch the session:

Why IT Pros Should Care

If you support a semiconductor, simulation, rendering, or scientific computing team, you have lived this story. Engineers ask for more cores. You buy them. Wall-clock times barely move. Managers then ask for more tool licenses, because surely that must be the constraint. Spoiler, it usually is not.

Here is why this matters to anyone running shared infrastructure on Azure:

EDA and HPC pipelines hammer storage with millions of tiny reads and writes, metadata operations like file creation, rename, and unlink, all happening concurrently across thousands of processes.
That pattern breaks generic cloud file storage that was tuned for large sequential I/O.
ANF brings the same NetApp ONTAP data services that EDA teams have used on-premises for decades, delivered as a native Azure service.
You can move design environments to Azure without re-architecting tools, schedulers, or scratch path conventions.
The economics changed in the last twelve months with the Flexible service level and Cool Access, so the old “ANF is too expensive for scratch” argument deserves a fresh look.

In short, if your job involves keeping expensive engineers and expensive licenses busy, the storage layer deserves your attention.

What Azure NetApp Files Brings to EDA and HPC, the technical overview

ANF is a first-party Azure service running NetApp ONTAP on bare-metal infrastructure inside Azure datacenters. It speaks NFS v3, NFS v4.1, and SMB, with dual-protocol options, and it preserves the file semantics that EDA tools assume. Things like POSIX permissions, fast metadata operations, snapshots, and consistent low latency.

Ron and Ranga framed the session in eight layers (Problem, Foundation, Accelerator, Scale, AI Ready, Guardrails, Optimize, Proof). Three pieces did most of the heavy lifting.

Foundation, Migration Assistant with SnapMirror. This is how you get the data into Azure without rewriting your inventory. SnapMirror replicates from on-premises ONTAP or Cloud Volumes ONTAP into ANF while preserving metadata, permissions, snapshots, and directory structure, with continuous synchronization and minimal downtime. For EDA flows where a missing ACL can invalidate an entire run, that fidelity is not optional.

Accelerator, Cache Volumes. Built on NetApp FlexCache, these volumes front your authoritative dataset (whether it lives in on-prem ONTAP or in Cloud Volumes ONTAP) and pull hot reads close to your Azure compute. Tool libraries, PDKs, shared reference data, all served at sub-millisecond latency without copying petabytes around. There is still one source of truth, which keeps your data governance story clean.

Scale, Large Volumes with Breakthrough mode. A single ANF large volume in Breakthrough mode scales to 2 PiB and delivers throughput in the tens of GiB per second by fanning I/O across six storage endpoints. That lets you collapse sharded namespaces (the classic /proj1, /proj2, /proj3 split that nobody loves) into fewer high-throughput volumes that behave predictably under contention.

How it works, under the hood

Cache Volumes are the FlexCache pattern most ONTAP customers already know. You peer a cluster, point a cache at an origin, and the cache propagates data on demand. Ron demoed this live: cluster peering with on-prem ONTAP, a cache volume created in ANF, and reads served from cache while the authoritative copy stayed home.

Large Volumes in Breakthrough mode are where the architecture gets interesting. Instead of a single mount point pinned to a single storage endpoint, Breakthrough mode exposes six storage endpoints for one logical volume. Clients can mount, balance I/O, and aggregate throughput across all six. Microsoft published Linux scale-out benchmarks showing a single 50 TiB large volume in Breakthrough mode sustaining roughly 50,000 MiB/s of sequential reads and approaching 1.8 million 8 KiB random read IOPS using twelve VMs (see the Microsoft Learn link in Resources).

For shared environments, ANF added user and group quotas with real-time consumption reporting and hard limits. Ranga demoed quota rules that stopped a runaway simulation generating millions of scratch files from starving the rest of the team. If you have ever had to send the “who filled the scratch volume” email at 2am, this feature alone might justify the trip.

On the cost side, the Flexible service level decouples capacity from throughput. You buy a capacity pool, you pick throughput independently, with 128 MiB/s of baseline throughput included and a ceiling of up to 640 MiB/s per provisioned TiB (which is roughly five times the Ultra service level). Cool Access transparently tiers cold blocks to Azure Blob behind the same file mount point.

In short, you stop paying for throughput you do not need on archival volumes, and you stop overprovisioning capacity to chase throughput on small scratch volumes.

Real-world value, use cases, ROI, scenarios

The Proof section closed with SPEC Storage 2020 EDA Blended results that are worth reading carefully:

A single large volume in Breakthrough mode sustained 2,880 EDA jobsets at about 0.51 ms overall response time.
Six volumes scaled linearly to 17,280 jobsets at about 0.60 ms.
FIO measurements approached 2 million IOPS.

The honest tradeoff: those numbers come from a benchmark, not your environment, and the SPEC tables show latency climbing at the highest load points. So treat the result as evidence that the platform behaves predictably under EDA-style concurrency, not as a guarantee for every workflow. That predictability is the part that matters. EDA leads do not lose sleep over peak throughput, they lose sleep over latency that drifts when concurrency rises.

Practical scenarios where this lands:

Burst regression and verification runs to Azure during tape-out crunches, with Cache Volumes keeping your on-prem golden tree authoritative.
Full migration of EDA environments to Azure for teams whose datacenters are out of capacity or out of lease.
HPC simulation workloads (CFD, weather, seismic, life sciences) that share the same metadata-heavy I/O profile.
AI-adjacent pipelines that need to read design data with file semantics and surface the same bytes as objects to Fabric, OneLake, or Databricks via the dual file and object access pattern Ron mentioned in the AI Ready section.

Getting Started, concrete first steps

You do not need a multi-quarter project to get a useful pilot moving.

Register the Azure NetApp Files resource provider in your target subscription and request quota in the regions you care about.
Stand up a small capacity pool, start with the Flexible service level so you can dial throughput independently.
Create a test volume, mount it from a representative VM (HBv4 or Ev5 family are good starting points for HPC and EDA respectively).
Run your real workload, not just FIO. Use a representative regression batch or simulation job and watch the metadata patterns in the ANF metrics blade.
If you have on-premises ONTAP, peer a Cache Volume against it to test FlexCache behavior with your actual datasets before committing to a full migration.
Layer in user and group quotas before you open the volume to a wider team. Trust me on this one.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here.

Cheers!

Pierre Roman

Modernize VDI with Azure Files and Entra Cloud-Native Identities

Pierre_Roman — Wed, 15 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever run a Virtual Desktop Infrastructure (VDI) estate, you know the recurring riddle. The session hosts are designed to be stateless and pooled, yet every user expects a persistent Outlook profile, their OneDrive cache, their pinned apps, and a sub-ten-second logon. In this session at the Microsoft Azure Infrastructure Summit 2026, Adam Groves and Priyanka Gangal from the Azure Files team showed how Azure Files plus Microsoft Entra ID finally let you deliver that experience without dragging domain controllers along for the ride.

📺 Watch the session:

Why IT Pros Should Care

VDI has always been a balancing act between elasticity and continuity. The compute layer wants to be ephemeral. The user wants to be at home. Bridging those two worlds used to mean a stack of identity plumbing that quietly grew until it became its own platform. This session changes that math.

Here is what jumped out for me:

Cloud-only identity for SMB. Azure Files now authenticates pure Microsoft Entra ID users and groups, including B2B guests, directly over SMB Kerberos. No on-premises Active Directory required, no Entra Connect required, no line of sight to a domain controller.
NTFS ACLs and Kerberos preserved. You keep the security model your apps already understand. Permissions still live on the file system, tickets still come over SMB, and FSLogix does not care that the identity stack underneath is different.
Performance built for the spike. Metadata caching is generally available and rolling out by default. Concurrent file handles per share are moving from 2,000 today to 10,000, with a roadmap toward 30,000 to 50,000. That means fewer storage accounts to shard across when 9 AM hits.
Zonal placement and smarter alerts. Premium LRS now lets you co-locate the share with its session hosts inside the same availability zone, and new percentage-based metrics finally make alert thresholds portable across shares of any size.

In short, the boring identity and storage plumbing that propped up VDI for a decade is being collapsed into something you can actually run as a cloud-native service.

What This Is, A Technical Overview

Let’s set the table. VDI on Azure (whether you run Azure Virtual Desktop, Citrix on Azure, or Omnissa Horizon) uses pooled session hosts. Those hosts are intentionally stateless so they can be patched, scaled, and recycled without ceremony. The user’s identity is “Connie Cloud” today, and on a different host tomorrow.

FSLogix solves the continuity half of the puzzle. It packages the user’s profile and Office data containers (the profile container and the ODFC, the Office Data Folder Container) as VHDX files that get dynamically attached when Connie logs on and detached when she signs out. Those VHDX files need to live somewhere durable, fast, and reachable over SMB from any host in the pool.

That is precisely what Azure Files delivers. It is a fully managed SMB file share service that integrates cleanly with FSLogix profile containers and App Attach image stores for AVD. The reference architecture and sizing guidance are documented on Microsoft Learn for anyone who wants the official map.

The historic friction was identity. Until recently, SMB authentication to Azure Files required either on-premises AD DS joined to the storage account or hybrid identities synced through Entra Connect. That meant keeping domain controllers (and the network paths to reach them) alive purely to satisfy storage authentication. As of this year, Azure Files supports pure Microsoft Entra ID identities for SMB Kerberos, which closes that loop.

How It Works, Under the Hood

Here is the simplified flow Adam and Priyanka walked through during the demo.

The user (an Entra-only account, no on-prem footprint) signs into an Entra-joined AVD session host with single sign-on.
The session host needs to mount the user’s FSLogix profile container from an Azure Files share.
The host requests a Kerberos service ticket. Because the share has Microsoft Entra Kerberos authentication enabled, Entra ID issues that ticket directly, no on-prem KDC involved.
The SMB connection is established, the share-level RBAC role (for example Storage File Data SMB Share Contributor) is checked, and then the directory and file ACLs (standard NTFS) are evaluated.
FSLogix attaches the VHDX, the profile loads, Outlook is happy, OneDrive is happy, and Connie’s pinned taskbar shows up exactly the way she left it.

A few details worth filing away:

Two layers of authorization. Share-level access uses Azure RBAC roles. Item-level access uses NTFS ACLs. Both still apply, which is why your existing permissions model carries over cleanly.
B2B guest support. Vendor and contractor accounts that come in as guests in your tenant can be granted access to file shares without needing a synced shadow account.
Metadata caching is the unlock. VDI is metadata-heavy: directory enumerations, file opens, renames, and closes hammer the share at logon. Metadata caching reduces P50 latency on those operations by roughly 80 to 90% and roughly doubles metadata transaction throughput, which is what makes the higher concurrent handle limits realistic. The full SMB performance reference on Microsoft Learn lays out the knobs.
Zonal placement. Premium LRS lets you pin the share to the same availability zone as your session host pool, so the SMB traffic does not bounce across zones.

Real-World Value

Where does this show up in your operations review?

Retire orphan domain controllers. Plenty of shops have a couple of DCs in Azure that exist only so Azure Files can authenticate. Cloud-native Entra ID lets you turn those off and shrink the identity attack surface.
Simpler M&A and vendor onboarding. Adding a partner organization or a new acquisition no longer requires forest trusts or a sync project. Invite guests, assign them to a group, grant the group access to the share.
Fewer storage accounts and shares to manage. Higher concurrent handle limits mean you can consolidate users that you previously had to spread across many accounts just to dodge the 2,000-handle ceiling. Less sprawl, less monitoring, fewer naming conventions to remember.
Predictable logon times at scale. Metadata caching is the kind of feature you only notice when it is missing. With it on by default, large host pools see flatter logon latency curves during the morning rush.
Operational consistency. Percentage-based metrics let you set a single rule like “alert at 10% remaining capacity” and apply it cleanly to a 5 TiB share and a 100 TiB share without bespoke thresholds.

In short, the ROI conversation moves from “how do we keep VDI running” to “how much of the supporting cast can we delete.”

Getting Started

If you want to kick the tires this week, here is a practical starting path.

Inventory your VDI identity story. Are you running hybrid because the apps need it, or because Azure Files used to need it? If it’s the second one, you have a candidate workload for cloud-only identity.
Spin up a pilot Premium SSD Azure Files share in the same region (and ideally the same availability zone) as a small AVD host pool.
Enable Microsoft Entra Kerberos authentication on the storage account. The configuration is now in the standard Azure portal, no more side trips to the fileperms portal.
Assign Azure RBAC roles at the share level (Storage File Data SMB Share Reader, Contributor, or Elevated Contributor as appropriate) to your Entra groups.
Set NTFS ACLs on the directories that will host FSLogix containers, and point FSLogix at the share’s UNC path.
Test with a cloud-only user (no on-prem identity at all) to confirm the end-to-end flow.
Turn on metadata caching and the new metrics and set percentage-based alerts so you find the limits before your users do.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki

Cheers!

Pierre Roman