Core Infrastructure and Security Blog articles

Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access

SantoshPargi — Mon, 13 Apr 2026 05:43:59 GMT

1) Introduction

In customer environments, Security Operations (SOC) teams and Windows infrastructure teams frequently need to investigate endpoint issues in the Microsoft Defender for Endpoint portal—often under time pressure—while still preserving strong governance over who can change security controls.

Because Troubleshooting Mode can enable temporary modification of Defender Antivirus settings even when devices are governed by organizational policies (for example, when policy protections are in place using Tamper protection settings), granting this capability broadly can introduce configuration drift, increase operational risk, and blur accountability.

To address this, customers typically require a least‑privilege, scoped access model that enforces Segregation of Duties (SoD):

Investigators (Security Reader) retain visibility and investigation capability but cannot create or modify MDE security policies.
Only an explicitly authorized group is granted the minimum permissions required to enable Troubleshooting Mode, and that access is restricted to a defined device scope using device groups—supporting both risk reduction and clear governance.

This approach ensures teams can perform required investigations and controlled troubleshooting while maintaining least privilege, SoD, and predictable operational impact across the customer’s environment.

This document describes an approach to providing controlled access to Troubleshooting Mode on a scoped set of devices.

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

2) Prerequisite & Coverage

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

This setup is necessary to:

- Enforce least privilege (only the permissions needed for Troubleshooting Mode and limited operational actions)

- Scope powerful actions to a defined device group instead of all devices

- Support a split model where one Security Reader group gets Troubleshooting Mode access and another Security Reader group remains view/operate without TS Mode

- Preserve governance: users can investigate and perform limited actions but cannot create or modify MDE policies

- Improve auditability by ensuring key actions are observable via device telemetry and the Action Center (while acknowledging that some telemetry may not include the initiating username).

3) Implementation Steps for Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID)

3.1 Prepare Entra ID User Group

Identify an existing Entra ID user group that contains users (IT Infra Team) with the Security Reader role or create a new dedicated Entra ID user group for this purpose.

- This group will be used consistently for:

- Assigning the custom Defender XDR role

- Scoping access to Defender for Endpoint device groups

3.2 Create and Assign Custom Defender XDR Role

Create a custom Defender XDR role with Microsoft Defender for Endpoint (MDE) Security Settings Management permissions.

- While creating the custom role, select only the minimum required permissions to maintain a least-privilege model.

- Assign this custom Defender XDR role to the Entra ID user group identified in Step 1.

Reference: See screenshots below for role creation, permission selection, and Entra ID group assignment.

3.3: Assign Entra ID User Group to Device Group

Assign the same Entra ID user group (used in Steps 1 and 2) to a Microsoft Defender for Endpoint device group.

- Devices in the device group should be dynamically grouped using supported criteria such as:

- Device tags

- Device name patterns

- Other supported device attributes

- This scoping ensures that the custom role permissions apply only to the intended set of devices.

Reference: See screenshot under below showing device group creation and Entra ID group-to-device group assignment.

3.4 Resulting User Experience and Permissions

After completing Steps 3.1 through 3.3, users who sign in with:

- Security Reader role, and

- Custom Defender XDR role

will observe the following behavior in the Microsoft Defender portal:

- Troubleshooting Mode is available on the scoped devices

- Users cannot create or modify MDE policies

- Users have access only to a controlled set of operational and investigative actions, including:

- Exclude

- Go hunt

- Download force release from isolation script

- Ask Defender Experts

This configuration enables safe troubleshooting while preventing configuration drift or unauthorized security policy changes.

Reference: See screenshot under below illustrating the available actions and the absence of policy creation/modification options.

Reference: See screenshot below where creation of AV policy failed as User will not have access to Intune to create policy.

4. In an alternate scenario, two separate Security Reader groups are maintained: one group requires access to Troubleshooting Mode, while the other should have no Troubleshooting Mode access. Users in the latter group (no TS Mode requirement) can continue to use standard Microsoft Defender for Endpoint (MDE) operational capabilities such as managing tags, setting device criticality, running antivirus scans, collecting an investigation package, reporting device inaccuracy, initiating advanced hunting (Go hunt), triggering policy sync, and running automated investigations. Users in the Troubleshooting Mode-enabled Security Reader group must also be assigned to the appropriate MDE device group to ensure their device-level access and workflows continue to function as expected.

Reference: See the screenshot below, which illustrates the additional MDE capabilities available to users who also have access to the device group

5: Auditing and Event Visibility

- Events related to Tamper Protection changes and Troubleshooting Mode enablement are captured in Microsoft Defender for Endpoint telemetry.

- These events are logged and visible for audit and investigation purposes.

- The username is not recorded in these specific event entries, which is expected behavior in the current Defender auditing model. However, the activation of Troubleshooting Mode is still logged and visible in the device Action Center, which allows confirmation that the mode was enabled on the device and the username.

Reference: See screenshot under Step 6 showing the relevant audit and event records in Timeline of Device Page. Similarly ,correlate using KQL across two Event Tables (DeviceEvents & EntraIdSignInEvents).

Below is the KQL query

let TimeWindow = 10m;

let Lookback = 7d;

// Portal sign-ins (Security & Compliance Center)

let DefenderPortalSignins =

materialize(

EntraIdSignInEvents

| where Timestamp >= ago(Lookback)

| where Application == "Microsoft 365 Security and Compliance Center"

| project

SignInTime = Timestamp,

PortalUserUpn = AccountUpn,

PortalUserObjectId = AccountObjectId,

SignInIP = IPAddress,

CorrelationId

| extend TimeBucket = bin(SignInTime, TimeWindow)

);

// Tamper-protection related events (broaden as needed)

let TamperEvents =

materialize(

DeviceEvents

| where Timestamp >= ago(Lookback)

| where ActionType has "Tamper" or ActionType == "TamperingAttempt"

| project

TamperTime = Timestamp,

DeviceId,

DeviceName,

ActionType,

AdditionalFields

| extend TimeBucket = bin(TamperTime, TimeWindow)

);

// Output rows: (UPN, TamperTime) within +/- window

TamperEvents

| join kind=inner (DefenderPortalSignins) on TimeBucket

| where abs(datetime_diff("minute", TamperTime, SignInTime)) <= toint(TimeWindow / 1m)

| project

PortalUserUpn,

TamperTime,

SignInTime,

DeviceName,

DeviceId,

ActionType,

SignInIP,

CorrelationId,

AdditionalFields

| order by TamperTime desc

This query correlates by time proximity. It indicates “user signed into the portal around the time a tamper event happened.”
It does not prove that the portal user caused the tamper event (that requires audit telemetry for the action). If you later want attribution (“who enabled troubleshooting mode / changed settings”), we should pivot to Defender Action Center message and then confirm the user.
The query can be used for generating alert using custom detection rule and take this alert to Security Operations center using API integration.

Below is reference to the sample output of the query.

6) Summary

Option 3 enables a controlled Troubleshooting Mode experience by combining Entra ID group-based user assignment, a custom Defender XDR role with minimal permissions, and device group scoping in MDE.

With this approach, eligible users can troubleshoot only the intended devices and perform a limited, operationally safe set of actions, while policy creation/modification remains restricted.

Audit and investigation are supported through MDE telemetry and device Action Center visibility, with the known limitation that certain telemetry entries may not include the initiating username.

Customer Offerings: Azure Local - Implementation, Migration, and Management

BrandonWilson — Sun, 12 Apr 2026 19:55:01 GMT

Hi everyone!

Brandon here, back once again to talk to you about a couple of new offerings that have just been released to assist our Unified customers with their on-premises virtualization needs! I continue to have the privilege of leading a great program and team helping customers to migrate from VMware to more cost-effective and/or modern solutions. These new offerings are <drum roll>:

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

NOTE: These offerings do not provide hands on keyboard support, do not create custom documentation for customers, and cannot provide direct support for any 3^rd party products that may be used in the process of migrations.

Many customers are reassessing their virtualization strategies and are actively exploring alternatives to VMware that align with long‑term hybrid cloud goals. Azure Local offers a purpose‑built platform that combines proven Windows Server–based virtualization with Azure services and management tooling, enabling customers to modernize on‑premises infrastructure while maintaining tight integration with Azure management, security, and governance capabilities.

Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Azure Local, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up prior to our review will have configuration issues, at times warranting extensive efforts to correct.

Problem 1: There are some potentially significant differences between the way VMware and Azure Local are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Azure Local environment.

Problem 2: Your management method must also change. Additionally, if you are converting/migrating to Azure Local, the available methods need to be determined, the terminology and functional differences identified and learned…there can be a lot to unpack in this area.

Problem 3: Perhaps the most obvious is that this may be a new platform for your team, and its important for them to gain experience through guided actions and knowledge transfer on the fly for those questions they really have, which is exactly what we aim to provide in guiding implementations and migrations!

A Structured Engagement Model

Successful Azure Local implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of an Azure Local Implementation and/or Migration

Most Azure Local implementation and migration engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Azure Local implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of the Azure Local engagements is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

An Azure Local migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Azure Local becomes a platform for long‑term innovation and a step to modernizing your infrastructure, not just a replacement hypervisor.

Conclusion

Moving from VMware to Azure Local is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Customer Offerings: Hyper-V - Implementation, Migration, and Management

BrandonWilson — Mon, 13 Apr 2026 02:50:50 GMT

Happy April everyone!

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

Many customers are taking a closer look at Microsoft Hyper‑V as a strategic alternative to traditional virtualization platforms. Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Hyper-V, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

I’m starting here for a very good reason… Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up for a VMware migration, will have configuration issues, many times warranting a complete redesign and re-deployment.

Problem 1: There are some potentially significant differences between the way VMware and Hyper-V are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Hyper-V environment.

Problem 2: To achieve feature parity, or near feature parity, your management method must also change. Additionally, if you are converting/migrating to Hyper-V, the available methods need to be determined, the terminology and functional differences identified and learned, well, honestly, I could go on for awhile on this, but I’ll spare you until we talk…

You mentioned management and conversion tools, what do you mean??

Hyper‑V has several methods for management, which can vary based on the feature needs and environment size. As a simple example, if I have 1500 virtualization hosts and 30,000 virtual machines spread out globally, its probably not going to be as efficient to manage everything only through locally available consoles. The capabilities of these management methods are continuing to grow and improve based on customer feedback, along with feedback from the field team. Let’s take a quick look at these options:

Native Windows tools: Hyper-V management console, Failover Clustering management console, Server Manager, etc
- This management method is typically used for small labs or smaller production environments (for migrations/conversions these methods do not provide feature parity with VMware).

System Center Virtual Machine Manager (SCVMM)
- This management method is fully supported for environments of all sizes. For migrations/conversions this method provides feature parity with VMware for management and features, along with offering VMware migration/conversion capability (offline). If you are already using any product from the System Center suite (SCCM, SCOM, SCORCH, SCSM, or DPM) then this can prove to be a great no cost option for you!

Windows Admin Center: Administration Mode (aMode)
- This management method is fully supported for environments of all sizes, however, is not designed as an infrastructure wide virtualization management method, but for server management and administration. If your environment isn’t extremely large, and VMware feature parity is not a necessity, this can provide a great no cost option for management of your physical and virtual servers. In addition, this method provides an online conversion option (currently public preview), allowing for a more seamless migration from VMware.

Windows Admin Center: Virtualization Mode (vMode) (currently public preview)
- This management method is fully supported for environments of all sizes, and is designed solely for the purpose of managing the Hyper-V virtualization infrastructure, tying together the primary needs for virtualization fabric into an easy to navigate web-based UI.

Azure
- You can Arc enable any Windows host or virtual machine and have a method of management and integration with cloud based services. In addition, these can work in conjunction with all of the above options to improve your management experience for your platform, and allows for the easy implementation and integration of many cloud based technologies (such as Hyper-V replica backups to ASR)

NOTE: You can learn more about Windows Admin Center evolution here: Windows Admin Center Architectural Changes | Microsoft Community Hub

A Structured Engagement Model

Successful Hyper‑V implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about a migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of a Hyper‑V Implementation and/or Migration

Most Hyper‑V engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Optional feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Hyper-V implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of a Hyper‑V engagement is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

A Hyper‑V migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Hyper‑V becomes a platform for long‑term innovation, not just a replacement hypervisor.

Conclusion

Moving from VMware to Hyper‑V is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Auditing FIDO2 authentication for Windows Sign-in

LijuV — Thu, 09 Apr 2026 11:10:08 GMT

Hello everyone, my name is Liju and I am a Cloud Solutions Architect helping customers secure their cloud and hybrid identities. With this post, I would like to show how FIDO2 security key authentication for Windows sign‑in can be audited on client devices.

Recently, a customer of mine asked how they could:

Audit each use of a FIDO2 security key on a Windows client device
Track all PIN verification attempts on the security key, including both successful and unsuccessful attempts
Determine which user successfully authenticated to a Windows device using a FIDO2 security key

While standard Windows logon events such as 4624 and 4625 report the user and logon type, they do not indicate whether a FIDO2 security key was used. We can find this information in the Microsoft‑Windows‑WebAuthN/Operational event log, although interpreting these events requires additional decoding and correlation.

Entra ID
FIDO2 Security Key authentication in Windows
- Authentication flow (high-level)
- Mapping the steps to WebAuthN events
WebAuthN Events
Tying it all together

But first, let us see how Entra ID stores the information when a user registers a FIDO2 security ley as an authentication method.

Entra ID

For each user that has registered a FIDO2 security key, the keys are represented as a fido2AuthenticationMethod resource on the user object. The identifier for the key is stored with a Base64URL encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA2

When a FIDO2 key is registered, an audit event is generated in Entra ID. The KeyIdentifier is stored using standard Base64 encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA==

If diagnostic logging is enabled for Entra ID and if the AuditLogs are sent to a Log Analytics Workspace, this information can be queried using KQL.

AuditLogs | where Category == "UserManagement" | where OperationName == "Add Passkey (device-bound)" | extend UserUPN = tostring(TargetResources[0].userPrincipalName) | extend FIDOkeyId = tostring(TargetResources[0].displayName)

Top👆

FIDO2 Security Key authentication in Windows

When a user signs in with a FIDO2 security key, Windows is trying to answer one question:

Can this authenticator (security key) prove possession of the private key associated with a registered credential for this user?

This proof is provided in the form of a WebAuthN assertion, which is a cryptographic response generated by the authenticator.

Authentication flow (high-level)

Challenge generation
During FIDO2 authentication for a Microsoft Entra user, a challenge is generated by the relying party (for example, login.microsoft.com) and provided to the client (Windows).

Request construction
Windows initiates a WebAuthN GetAssertion request, which is encoded using CBOR (Concise Binary Object Representation), a compact binary format used by the FIDO2 protocol.
The request contains the clientDataHash which is a hashed JSON object containing the challenge sent by Entra (along with other parameters).

Authenticator processing
The request is sent to the authenticator using CTAP (Client to Authenticator Protocol).
The authenticator then locates a matching credential for the relying party, performs user verification if required (for example, PIN or biometric) and constructs the authenticatorData, which includes the hash of the relying party ID (rpIdHash)
The authenticator finally generates the assertion by signing (authenticatorData + clientDataHash) using the credential’s private key

Response processing
The authenticator returns the assertion (encoded in CBOR) to Windows.
Windows then decodes the CBOR response, extracts the assertion components (credential ID, authenticatorData, signature), evaluates the result and completes the WebAuthN operation.

Top👆

Mapping the steps to WebAuthN events

Before we take a look at the WebAuthN events on the Windows client, let us see how the logon process maps directly to the Event Log task categories.

Step	Details	Event entry
Challenge generation	Windows initiates authentication using a FIDO2 credential A TransactionId is created that ties all related events together.	WebAuthN Ctap GetAssertion started (Event ID 1003)
Request construction	Windows builds the CTAP2 request to send to the key Encoded in the request are the rpId and clientDataHash. For Entra ID, the rpId is login.microsoft.com	Cbor encode GetAssertion request (Event ID 1103)
Authenticator processing	Windows transitions from WebAuthN to the CTAP layer, and authenticator interaction begins	Ctap GetAssertion started (Event ID 2100)
Authenticator processing	Windows exchanges CTAP commands with the key This includes: PIN verification (authenticatorClientPIN / getPINToken) Authentication request (authenticatorGetAssertion)	Ctap Usb Send Receive (Event ID 2225)
Response processing	Authenticator returns result to Windows	Ctap GetAssertion completed (Event ID 2102 / 2103)
	Windows interpret the authenticator’s response	Cbor decode GetAssertion response (Event ID 1104)
	Windows completes WebAuthN operation	WebAuthN Ctap GetAssertion completed (Event ID 1004 / 1005)

Top👆

WebAuthN Events

Challenge generation

The WebAuthN Ctap GetAssertion started event (Event ID 1003) indicates that Windows has initiated a WebAuthN authentication operation and is beginning the process of requesting an assertion from an authenticator. This marks the start of the FIDO2 authentication flow but does not yet involve communication with the security key or indicate whether authentication will succeed.

Request construction

The Cbor encode GetAssertion request event (Event ID 1103) shows Windows encoding a targeted WebAuthN GetAssertion request.

When the Request begins with 0x02, it indicates that this is a authenticatorGetAssertion CTAP command.

Note that whether or not a credential ID is present in this event depends on the scenario. When AllowCredentialCount is greater than zero, the request includes one or more specific credential IDs (making it a “targeted” WebAuthN GetAssertion request). When it is zero, the authenticator is performing a credential discovery.

The description may be parsed to get the credential Id and will match the key identifier from Entra ID when Base64 encoded.

The Cbor encode GetAssertion request event (Event ID 1103) is generally the most useful event for auditing each authentication attempts of a FIDO2 security key on a Windows client device.

Top👆

How to parse the CBOR-encoded request

Let us take the Cbor Encode GetAssertion Request event (ID 1103) and parse the CBOR-encoded data in its description

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
RpId: login.microsoft.com
ClientDataHashAlgId: S256
ClientDataLength: 176
ClientDataHash: 0x0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3
AllowCredentialCount: 1

Request: 0x02A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5

The first byte gives us the CTAP command.
- In this case it is 0x02 which means authenticatorGetAssertion (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5).
- Note that The CBOR payload starts with A4. This means that the CBOR body is a map with 4 entries or named fields.
If you do not want to decode the bytes by hand, a simple way to inspect the payload is to paste it into an online CBOR decoder such as CBOR Playground. The site accepts hex input and can parse it into a readable CBOR structure.
Paste the CBOR payload into the input area. Make sure the input mode is Hex, then use Parse.

For this example, the decoded result is:

{
1: "login.microsoft.com",
2: h'0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3',
3: [
    {
      "id": h'EDE6F30E65534AB78BB0992B8E6D6634',
      "type": "public-key"
    }
],
5: {
    "up": true
}
}

This output is still using the CTAP numeric field keys (1-5), so the next step is to translate those numbers into the field names used by the GetAssertion request based on the table at Client to Authenticator Protocol (CTAP):
- 1 = rpId
- 2 = clientDataHash
- 3 = allowList
- 5 = options
So in plain English, the payload says:

{
"rpId": "login.microsoft.com",
"clientDataHash": "0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3",
"allowList": [
    {
      "id": "EDE6F30E65534AB78BB0992B8E6D6634",
      "type": "public-key"
    }
],
"options": {
    "up": true
}
}

For a bit more detail about each field:
- Key 1 contains the relying party ID
- Key 2 contains the 32-byte clientDataHash
- Key 3 contains an allowList array with one credential descriptor
- Key 5 contains an options map
- Inside options, up: true means user presence was requested

For details on how to decode the CBOR payload yourself see RFC 8949: Concise Binary Object Representation (CBOR)

Top👆

Translating Entra key identifier to WebAuthN Credential Id

The key identifier from Entra ID when Base64 decoded will match the CredentialId in the event.

A sample PowerShell function that does this is given below:

function Convert-Base64UrlToBytes { param( [Parameter(Mandatory=$true)] [string]$Base64Url ) # Convert Base64url to normal Base64 $b64 = $Base64Url.Replace('-', '+').Replace('_', '/') # Add padding if required switch ($b64.Length % 4) { 2 { $b64 += "==" } 3 { $b64 += "=" } 0 { } # already aligned 1 { throw "Invalid Base64url string length" } } # Decode Base64 → byte array return [Convert]::FromBase64String($b64) } cls # Conversion from Base64URL encoded identifier (user object) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA2" ($bytes | ForEach-Object { $_.ToString("X2") }) -join "" # Conversion from Base64 encoded identifier (audit log) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA==" ($bytes | ForEach-Object { $_.ToString("X2") }) -join ""

Top👆

Authenticator processing

The Ctap GetAssertion started event (Event ID 2100) shows Windows starting a CTAP GetAssertion operation against a specific FIDO2 key.

Authenticator PIN Validation

All PIN attempts generate a Ctap Usb Send Receive event (Event ID 2225) where the Request starts with 0x06A401010205

06 means this is a PIN-related command
If the request starts with 06A401010205 this denotes a getPinToken flag, meaning a PIN verification attempt.

If the Response starts 0x00, it indicates a Success.

Other possible values for the response field are:

0x31 - Incorrect PIN
0x33 - PIN Auth Invalid
0x34 - PIN Required

Therefore, Ctap Usb Send Receive events (Event ID 2225) where the Request starts with 0x06A401010205 will report all security key PIN attempts, both successful and unsuccessful, on the client device.

Top👆

How to parse the CBOR-encoded request

Let us try and parse the CBOR-encoded data in the event’s description once again.

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
Request Command: 0x90
Response Command: 0x90

Request: 0x06A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A

Response: 0x00A1025093B2EE5307CC81EA08684FEBE22D536D

The first byte in the request (0x06) gives us the authenticatorClientPIN CTAP command (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A).
- As before A4 means that the CBOR body is a map with 4 entries or named fields.
Parsing this payload using CBOR Playground we get:

{
1: 1,
2: 5,
3: {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
6: h'746BE172CD2402CFFCC94734BC98D16A'
}

Using the table at Client to Authenticator Protocol (CTAP) to translate the numeric keys we have:
- key 1 = pinUvAuthProtocol
- key 2 = subCommand
- key 3 = keyAgreement
- key 6 = pinHashEnc
After the translation, the payload says:

{

"pinUvAuthProtocol": 1,
"subCommand": 5,
"keyAgreement": {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
"pinHashEnc": h'746BE172CD2402CFFCC94734BC98D16A'
}

The information most useful for us here is "subCommand": 5, which as you can see from the second table in Client to Authenticator Protocol (CTAP) tells is a getPinToken subcommand.

In summary, when the request begins with 06 A4 01 01 02 05, it can be identified as a PIN verification attempt. The leading byte 0x06 indicates the CTAP authenticatorClientPIN command. The next byte A4 shows that the CBOR payload is a map with four fields. Within that map, the sequence 01 01 corresponds to pinUvAuthProtocol = 1, and 02 05 corresponds to subCommand = 5. In the Client PIN command set, subcommand 5 represents getPinToken, which is used during PIN verification. Together, this byte pattern reliably indicates that the operation is a PIN-based authentication step rather than a standard assertion request.

Turn on Annotate if you want the CBOR Playground site to show how each byte is interpreted.

Top👆

Authenticator GetAssertion operation

Ctap Usb Send Receive events (Event ID 2225) where the Request begins with 0x02 indicate an authenticatorGetAssertion CTAP2 Operation. The encoded payload includes the RpId and ClientDataHash.

If the Response begins with 0x00 it was successful. Included in the CBOR payload is the id (Credential ID) and the rpIdHash

Top👆

Response processing

The Ctap GetAssertion completed event (Event ID 2102) tells us that the authenticator successfully completed a GetAssertion operation and returned a valid signed assertion to Windows.

Included in the response payload are security key device information, status of the operation (6673746174757300 stands for status = 0), the credential used and authenticator data.

The Cbor decode GetAssertion response event (Event ID 1104) is logged when the authenticator successfully returns a WebAuthN assertion for the relying party using a particular credential.

This is one of the best events to track successful authentication because the important fields are already parsed out.

The RpIdHash of 356C9ED4A09321B9695F1EAF918203F1B55F689DA61FBC96184C157DDA680C81 is the SHA-256 hash of “login.microsoft.com”
A Flags value of 0x85 means 0x80 + 0x04 + 0x01
- 0x01: UP (the user was present and interacted with the key)
- 0x04: UV (user verification succeeded, which in this scenario means PIN was successfully validated)
- 0x80: ED (extension data was included in the assertion)
The CredentialId of EDE6F30E65534AB78BB0992B8E6D6634 when Base64 encoded, will match the key identifier in Entra.

Therefore, Cbor decode GetAssertion response events (Event ID 1104) will tell you which users successfully authenticated to the Windows device using a FIDO2 security key.

Finally, the WebAuthN Ctap GetAssertion completed event (Event ID 1004) tells us that WebAuthN GetAssertion operation completed successfully for this TransactionId.

Top👆

Tying it all together

I started out by outlining what my customer’s monitoring goals were; the table below summarizes the events recommended for monitoring:

What to Monitor	Event	Notes
Each use of a FIDO2 security key on a Windows client device.	Cbor encode GetAssertion request (Event ID 1103)	Filter for events where: Request begins with 0x02 AllowCredentialCount is greater than zero. Parse Request for credential Id. Base64 encode credential Id to match key identifier and user in Entra ID.
All attempts, both successful and unsuccessful, when a PIN was tried to unlock a credential on the FIDO2 security key on the device.	Ctap Usb Send Receive (Event ID 2225)	Filter for events where Request starts with 0x06A401010205. The Response property indicates result.
Which user successfully authenticated to the Windows device using their FIDO2 security key.	Cbor decode GetAssertion response (Event ID 1104)	Base64 encode credential Id to match key identifier and user in Entra ID.

The techniques outlined in this document show how to identify individual FIDO2 credentials, track PIN verification attempts, and conclusively determine which user authenticated to a Windows device using a security key. With this approach, passwordless authentication becomes not only more secure, but also more observable and supportable in enterprise environments.

Azure Database Security Newsletter - April 2026

PieterVanhove — Wed, 01 Apr 2026 08:08:13 GMT

Welcome to the quarterly edition of Azure Database Platform Security Newsletter. In this newsletter we highlight the importance of strong encryption for data security, and call out recent encryption, key management, and auditing enhancements designed to help you strengthen your security posture while simplifying operational management.

Data is one of the most critical assets organizations manage, and protecting it is essential to maintaining trust, resilience, and long‑term success. As cyber threats continue to evolve and regulatory expectations increase, strong encryption has become a foundational requirement rather than an optional safeguard.

Encryption protects sensitive data across its entire lifecycle. Data is encrypted at rest using Transparent Data Encryption (TDE) to protect stored information, in transit using Transport Layer Security (TLS) to secure data as it moves across your application and server, and in use through Always Encrypted to help ensure data remains protected even from high-privileged users. Together, these capabilities reduce risk and support compliance obligations.

Feature highlights 💡

Customer-Managed Keys in Fabric SQL Database

Customer-Managed Keys (CMK) are now generally available for Fabric SQL Database, allowing you to use Azure Key Vault keys to encrypt all workspace data, including all SQL Database data. This feature gives organizations greater control over key management and helps meet data governance and encryption requirements. More information on How to encrypt Fabric SQL Database with Customer Managed Keys (Video).

Versionless keys for Transparent Data Encryption in Azure SQL Database

Azure SQL Database now lets you use versionless key URIs for Transparent Data Encryption (TDE) with customer-managed keys, automatically applying the latest enabled key from Azure Key Vault or Managed HSM. This update simplifies encryption management.

Auditing in Fabric SQL Database

Auditing for Fabric SQL Database is now generally available. Organizations can track and log database activities, addressing questions about data access for compliance, threat detection, and forensic analysis. Audit logs are stored in One Lake, and access is controlled by Fabric workspace roles and SQL permissions.

Best Practices Corner

Retain all historical TDE keys and key versions

Always keep all historical Transparent Data Encryption (TDE) keys and their versions. Databases and backups remain encrypted with the key version that was active at the time of encryption. Restoring an older database requires access to the exact key version used. Deleting older keys or versions can make database restore impossible and result in permanent data loss. See Everything you need to know about TDE key management for database restore.

Apply the Principle of Least Privilege

Always grant users, applications, and services the minimum level of access required to perform their database tasks. Avoid broad administrative or owner-level permissions unless absolutely necessary. Regularly review, restrict, and remove excessive or unused privileges to reduce the attack surface and limit the impact of compromised credentials or configuration errors. This control aligns with established security standards such as NIST SP 800‑53 (AC‑6: Least Privilege), CIS Critical Security Controls, ISO/IEC 27002, and OWASP database security guidance.

Enable Auditing on Azure SQL and SQL Server

Always enable auditing on Azure SQL to record database activities for security monitoring, compliance, and forensic investigation. Auditing provides visibility into database access and changes, helping detect unauthorized or suspicious behavior and supporting incident response and regulatory requirements. See Auditing - Azure SQL Database.

Blogs and Video Spotlight 🅱️

In the last three months, we've published blog posts on major releases and features. These updates offer practical insights and highlight the latest in data security and database management.

Why ledger verification is non-negotiable

How to Enable Microsoft Entra ID for Azure Cosmos DB (NoSQL)

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)

Announcing Preview of bulkadmin role support for SQL Server on Linux

Zero Trust for data: Make Microsoft Entra authentication for SQL your policy baseline

Community & Events 👥

The data platform security team will be on-site at several upcoming events. Come and say hi!

Previous events

SQL Konferenz

FABCON 26 - Microsoft Fabric Community Conference - FABCON

SQLCON - Microsoft SQL Community Conference - SQLCON

Upcoming events

SQLBits

DataGrillen

Call to action 📢

Take 15 minutes this week to validate your database encryption posture: confirm TDE is enabled, review your key management plan (including retaining historical key versions), and ensure TLS is enforced for all connections. If you are using Fabric SQL Database, consider enabling Customer-Managed Keys and turning on Auditing to strengthen governance and investigation readiness. Share this newsletter with your security and DBA partners and align on one concrete improvement you can complete.

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

TysonPaul — Mon, 30 Mar 2026 18:45:30 GMT

Member: TysonPaul | Microsoft Community Hub

Automating Large‑Scale Data Management with Azure Storage Actions

Team Blog: ITOps Talk

Author: 1Nataraj

Published: 02/25/2026

Summary: Azure Storage Actions is a fully managed, serverless automation platform that simplifies large-scale data management in Azure Blob and Data Lake Storage. It enables users to automate tasks such as tagging, tiering, deletion, and applying immutability based on customizable conditions—without custom code or infrastructure. Administrators can centrally define tasks and assign them across multiple storage accounts, with built-in preview, monitoring, and audit features. Use cases include compliance, cost optimization, and metadata management, making it ideal for organizations managing millions of items across vast storage estates. Azure Storage Actions is available in over 40 Azure regions.

Migration, Modernization & Agentic Tools

Team Blog: ITOps Talk

Author: OrinThomas

Published: 02/25/2026

Summary: The article discusses how agentic tools, such as those in Azure Copilot and GitHub Copilot, transform cloud migration and modernization from one-time projects into ongoing, autonomous systems. These tools dynamically discover environments, recommend modernization paths, automate migration steps, and continuously optimize workloads for cost, performance, security, and compliance. By embedding governance and leveraging real-time telemetry, agentic tools reduce manual effort, minimize errors, and ensure migrations are efficient, secure, and aligned with enterprise standards, providing continuous improvement post-migration.

What’s new in FinOps toolkit 13 – January 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 02/09/2026

Summary: The January 2026 update to the FinOps toolkit focuses on stability, usability, and community engagement. Key enhancements include improved documentation, new features like configurable Key Vault purge protection, and expanded support for Parquet format and compression in Cost Management exports via PowerShell. Security, reliability, and extensibility have been strengthened for FinOps hubs, with numerous bug fixes across Power BI reports, workbooks, and the Azure Optimization Engine. The release highlights ongoing community involvement, upcoming features like AI automation, and premium services to help organizations deploy and scale the toolkit effectively.

Managed Identity on SQL Server On-Prem: The End of Stored Secrets

Team Blog: Core Infrastructure and Security

Author: RyadB

Published: 02/23/2026

Summary: **Summary:** The article explains how SQL Server 2025 on-premises, when connected to Azure Arc, can use Managed Identity to access Azure resources without storing secrets like SAS tokens or keys. This approach eliminates risks of secret storage, rotation, and auditing complexity by leveraging Microsoft Entra ID for identity management and RBAC for permissions. The article details configuration steps, migration from stored credentials, troubleshooting, and current limitations, highlighting improved security and simplified management for on-prem SQL Server accessing Azure services.

Running Text to Image and Text to Video with ComfyUI and Nvidia H100 GPU

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 02/27/2026

Summary: This article provides a step-by-step guide for setting up and running ComfyUI, a node-based interface for AI-powered text-to-image and text-to-video generation, on Azure VMs with Nvidia H100 GPUs. It details both automated (Terraform) and manual setup methods, including installing drivers, dependencies, and downloading required models. The guide explains accessing ComfyUI’s web portal, workflow configuration, and model management to create high-quality images and videos efficiently. It also includes important notes about GPU driver compatibility and offers links to official documentation and scripts for further reference.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Team Blog: Azure Networking

Author: cozhang

Published: 02/06/2026

Summary: The article introduces Azure’s StandardV2 NAT Gateway, highlighting its new features such as zone-redundancy, enhanced performance, dual-stack support, and, notably, flow logs. Flow logs provide detailed visibility into outbound traffic, enabling security auditing, compliance, usage analytics, and troubleshooting. The article explains how to enable and use flow logs to diagnose connectivity issues and optimize network architecture. It emphasizes the importance of flow logs for monitoring established outbound connections and offers troubleshooting steps for connection drops, recommending best practices for resilient Azure deployments.

Centralized cluster performance metrics with ReFrame HPC and Azure Log Analytics

Team Blog: Azure High Performance Computing (HPC)

Author: jimpaine

Published: 02/06/2026

Summary: The article outlines how to integrate ReFrame HPC, a flexible high-performance computing testing framework, with Azure Log Analytics for centralized performance monitoring across diverse clusters and environments. It details deploying necessary Azure resources, configuring ReFrame for HTTP logging, and running performance tests with results sent to Log Analytics. This integration enables unified, standardized metrics collection, cross-cluster comparisons, trend analysis, and improved system visibility—supporting migration, development, and operational assurance in heterogeneous HPC environments.

Azure Recognized as an NVIDIA Cloud Exemplar, Setting the Bar for AI Performance in the Cloud

Team Blog: Azure High Performance Computing (HPC)

Author: Fernando_Aznar

Published: 02/18/2026

Summary: Microsoft Azure has been recognized as the first NVIDIA Exemplar Cloud for its world-class, end-to-end AI workload performance, now validated for both H100 and next-generation GB300 (Blackwell) systems. This designation reflects Azure’s optimized full-stack infrastructure—including compute, networking, and software integration—delivering predictable, efficient, and scalable AI training at production scale. Customers benefit from faster time-to-train, improved ROI, and confidence in Azure’s readiness for advanced AI workloads, ensuring consistent high performance from proof-of-concept to deployment without sacrificing cloud flexibility or manageability.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service (AKS)

Team Blog: Azure Architecture

Author: rgarofalo

Published: 02/03/2026

Summary: The article presents a reference architecture for highly available, multi-region Azure Kubernetes Service (AKS) deployments. It compares active/active, active/passive, and deployment stamp models, detailing their trade-offs in availability, complexity, and cost. Key components include Azure Front Door for global traffic routing, geo-replicated data services, centralized monitoring, and consistent security controls. The architecture emphasizes resilience through fault isolation, automated recovery, and regular testing. It offers practical guidance for cloud architects to design AKS platforms that withstand regional outages, ensuring business continuity and scalable operations across Azure regions.

Reactive Incident Response with Azure SRE Agent: From Alert to Resolution in Minutes

Team Blog: Azure Architecture

Author: Sabyasachi-Samaddar

Published: 02/18/2026

Summary: **Summary:** The article details how Azure SRE Agent revolutionizes incident response by automating investigation and triage as soon as an alert fires, reducing resolution times from hours to minutes. Through two real-world scenarios—a SQL connectivity outage and a VM CPU spike—the agent autonomously diagnosed issues, proposed remediations, and required minimal human intervention. Custom Incident Response Plans and instructions enable context-aware, consistent, and rapid resolutions, with automated post-incident documentation. Key benefits include faster MTTR, reduced manual toil, and improved knowledge capture, though some technical challenges remain. Azure SRE Agent is currently in preview.

Cross Forest Enrollment – PKISync.PS1

Team Blog: Ask the Directory Services Team

Author: Manuel_Alvarez_V

Published: 02/19/2026

Summary: The article explains how to use the PKISync.ps1 PowerShell script for cross-forest certificate enrollment in Active Directory environments. PKISync synchronizes PKI-related objects, such as certificate templates and CA configurations, from a source forest to a target forest, enabling certificate requests across forests. It details the setup requirements, including two-way forest trusts, LDAP referral configuration, and certificate publishing. Although PKISync is considered legacy, automating its use can facilitate simple cross-forest enrollment, but CEP/CES is recommended for modern, secure deployments. The article concludes with best practices and automation tips for PKISync.

What’s New in Windows Group Policy Preferences Debug Logging

Team Blog: Ask the Directory Services Team

Author: TagoreN

Published: 02/27/2026

Summary: The article outlines a new feature in Windows 11 24H2 and 25H2 (from February 2026 preview updates) that allows administrators to enable Group Policy Preferences (GPP) debug logging directly through Local Group Policy, not just domain-based GPOs. This simplifies troubleshooting by allowing detailed logging on client devices without domain reliance. The article explains how to configure logging, manage trace file locations, and set necessary permissions. Overall, this update enhances flexibility and efficiency for IT professionals managing and debugging GPP issues on Windows client devices.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

Team Blog: Azure Storage

Author: ellievail

Published: 02/26/2026

Summary: Microsoft has announced the public preview of user-bound user delegation SAS for Azure Storage, enhancing security by restricting SAS token usage to a specific Microsoft Entra ID identity. This feature extends user delegation SAS, requiring the end user to authenticate with Entra ID to access storage resources. It supports cross-tenant scenarios and incurs no additional cost beyond standard storage transactions. User-bound SAS is available via REST APIs, SDKs, PowerShell, and CLI for all GPv2 storage accounts in public regions, with detailed steps provided for setup and role assignment.

Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets

Team Blog: Azure Storage

Author: Lakshya_Jalan

Published: 02/18/2026

Summary: Azure Migrate now supports Premium SSD v2, Ultra Disk, and ZRS Disks as migration targets, with Premium SSD v2 and ZRS generally available and Ultra Disk in public preview. This update enhances assessment and migration by enabling tailored recommendations based on workload performance needs, offering greater flexibility, performance, and resiliency. Users can now migrate demanding, mission-critical workloads to Azure using these advanced disk options, benefiting from features like zonal redundancy and customizable performance. The enhancements streamline migrations and ensure optimal resource alignment, supporting petabytes of data already migrated during the preview phase.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

Team Blog: Azure Compute

Author: HilaryWang

Published: 02/17/2026

Summary: Azure has introduced the public preview of automatic zone balance for Virtual Machine Scale Sets, which automatically monitors and redistributes VM instances across availability zones to maintain optimal resiliency. This feature addresses imbalances that can occur over time, minimizing the impact of zone failures without manual intervention. The system uses health checks, respects instance protection policies, and ensures workload capacity during rebalancing. Automatic instance repair is also enabled by default. Users can join the preview by enabling the feature and meeting specific prerequisites. This capability reduces operational overhead while enhancing workload reliability and zone-level resilience.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 02/04/2026

Summary: Azure Automated Virtual Machine Recovery is a built-in Azure feature that minimizes VM downtime through fast, intelligent, and automated recovery processes. Without requiring customer setup, it continuously monitors VM health, rapidly detects failures, diagnoses issues, and applies the optimal recovery action, all without customer intervention. Leveraging detailed recovery event annotations, it provides deep visibility into incident timelines and helps optimize recovery strategies. Over the past 18 months, this system has halved average VM downtime, strengthening business continuity, reducing financial impact, and reinforcing customer trust in Azure’s reliable cloud platform.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/02/2026

Summary: This article provides guidance for resolving device noncompliance issues when using Mobile Threat Defense (MTD) partner apps, like Microsoft Defender for Endpoint, with Microsoft Intune. It outlines troubleshooting steps for users to restore compliance—installing, activating, refreshing, or reinstalling the MTD app—and checking compliance status. It also details simplified remediation workflows for iOS/iPadOS and methods for resetting the MTD connection on Android if sign-out is blocked, helping users regain access to work or school resources and reducing support overhead.

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/20/2026

Summary: Starting June 16, 2026, Intune will require HTTPS for Microsoft Connected Cache when delivering Win32 apps. To maintain caching benefits and reduce bandwidth, administrators must configure HTTPS on Connected Cache nodes using a CA-signed TLS certificate. The guide details generating a CSR on the node, signing and importing the certificate, and validating HTTPS on both Windows and Linux hosts. It also covers troubleshooting, maintenance, and renewal. Without HTTPS, devices will revert to using the CDN for Intune app downloads. Other content types remain unaffected. Early configuration ensures seamless transition and continued performance benefits.

The Copilot resource guide to share with your employees

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces the "Essential Copilot resource hubs for employees," a centralized guide designed to streamline Microsoft Copilot onboarding and support. It helps adoption leaders structure learning paths, IT admins share resources efficiently, and all employees access consistent guidance. The guide consolidates key Microsoft Copilot resources, making it easier for organizations to accelerate adoption and customize internal policies. Additional support is available through FastTrack and the Microsoft 365 Accelerator site, offering expert guidance, templates, and personalized assistance to boost Copilot deployment and change management efforts.

Copilot adoption: Move your org from pilot to production with this guide

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces a comprehensive guide for IT admins and Copilot adoption leads to streamline the rollout of Microsoft 365 Copilot. Organized around the adoption lifecycle (plan, build, operate), the guide highlights eight essential resource hubs, practical rollout steps, and audience-specific resources to ensure effective, governed adoption. It also promotes Microsoft FastTrack, which offers expert support, self-service resources, and personalized assistance to accelerate and scale Copilot deployment at no extra cost.

Azure Virtual Desktop is now available in US Gov Texas in Azure Government

Team Blog: Azure Virtual Desktop

Author: Ron_Coleman

Published: 02/04/2026

Summary: Azure Virtual Desktop is now available in the USGov Texas region of Azure Government, offering customers a new option for deploying secure and flexible virtual desktop environments. This expansion enables improved connection performance, reduced latency, and enhanced responsiveness by allowing host pool creation directly in the region. It supports mission needs, geographic distribution, and regulatory requirements, while maintaining Azure Government’s compliance and security standards. Customers can now leverage multiple regions for greater flexibility and performance in their virtual desktop deployments.

RDP Shortpath (UDP) over Private Link is now generally available

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 02/17/2026

Summary: Azure Virtual Desktop now supports UDP-based RDP Shortpath over Private Link, enabling direct, high-performance RDP connections between session hosts and clients using private IPs. This complements existing TCP connectivity, helping customers with strict private network boundaries. Administrators must explicitly enable UDP in Azure portal settings to use this feature. The opt-in model ensures secure and predictable transport, giving full control over UDP introduction. This enhancement is recommended for customers needing precise routing and policy enforcement in regulated environments, while standard AVD connectivity remains suitable for most deployments. Full configuration guidance is available in Azure documentation.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 02/18/2026

Summary: The article outlines a structured, five-phase approach for migrating workloads from AWS to Azure, emphasizing a like-for-like architecture to minimize risk and maintain operational stability. Key phases include planning, preparation, execution, evaluation, and decommissioning, each requiring thorough documentation, stakeholder alignment, testing, and validation. The recommended migration strategy is blue/green deployment for risk mitigation. The workload team should lead the migration, supported by external Azure experts. Success depends on careful planning, phased execution, and post-migration optimization, with organizational knowledge-sharing encouraged for future improvements.

Modernizing for the AI Era: Accelerating Application Transformation with Agentic Tools

Team Blog: Azure Migration and Modernization

Author: MarcoB

Published: 02/12/2026

Summary: The article highlights the urgent need for organizations to modernize legacy applications to thrive in the AI era. Legacy systems drain resources and hinder innovation, but new agentic tools—such as GitHub Copilot, Azure Migrate, and Azure Copilot—use AI to automate and accelerate application transformation. These tools reduce manual effort, boost accuracy and safety, and make modernization accessible, empowering teams to focus on innovation. The result is faster, safer, and more consistent modernization, enabling organizations to continuously evolve their applications for intelligent, cloud-optimized environments. Practical steps and resources are provided to guide organizations in getting started.

Secure DNS with DoH: Public Preview for Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 02/09/2026

Summary: Microsoft has launched a public preview of DNS over HTTPS (DoH) for Windows DNS Server, enabling encrypted and authenticated DNS queries within on-premises networks. This upgrade enhances security and privacy by preventing DNS traffic from being exposed or intercepted, aligning with Zero Trust principles and U.S. federal requirements. The DoH feature, included in the February 2026 update for Windows Server 2025, is disabled by default and currently intended for evaluation only. Existing DNS functionality remains unchanged, with new tools added for DoH management. Feedback is encouraged to improve the feature before general availability.

Announcing Public Preview: Simplified Machine Provisioning for Azure Local

Team Blog: Azure Arc

Author: PragyaDwivedi

Published: 02/26/2026

Summary: Microsoft has announced the Public Preview of Simplified Machine Provisioning for Azure Local, streamlining edge infrastructure deployment. The new process centralizes configuration in Azure, requiring minimal on-site expertise—staff only need to rack, power on hardware, and insert a prepared USB. Secure provisioning uses industry standards like FIDO Device Onboarding and Azure Arc Site for consistent, automated deployments across multiple locations. IT teams manage and monitor provisioning remotely, reducing errors and speeding up setup. Once complete, machines are ready for cluster creation and workload deployment, significantly simplifying and scaling Azure Local deployments.

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Team Blog: Azure Tools

Author: Alex-wdy

Published: 02/03/2026

Summary: The article discusses a critical issue affecting Azure CLI upgrades on Windows using the MSI installer, where users upgrading from version 2.76.0 (or earlier) to 2.77.0 (or later) encountered startup crashes due to missing Python extension files. The root cause was a versioning conflict during upgrade, leading to incomplete installations. The article details recovery steps, recommends upgrading to version 2.83.0, and highlights improvements to the MSI upgrade process, making installations faster and more reliable by simplifying file replacement logic and eliminating slow version checks. Users are encouraged to upgrade and report issues if encountered.

Navigating the 2025 holiday season: Insights into Azure’s DDoS defense

Team Blog: Azure Network Security

Author: Jdasari

Published: 02/18/2026

Summary: During the 2025 holiday season, Azure observed a rise in burst-style DDoS attacks, with high-intensity, short-lived surges targeting packet processing and connection-handling layers. Most attacks were automated and brief, but the cumulative impact was operationally draining, especially for latency-sensitive sectors like gaming. Botnet-driven attacks rapidly shifted targets, exploiting inconsistent defenses. Azure DDoS Protection mitigated over 174,000 attacks, underscoring the need for always-on, automated, and layered security. Organizations are urged to standardize protections, proactively monitor, and adopt Zero Trust and multi-layered defense strategies to ensure resilience against evolving threats in 2026.

A Practical Guide to Azure DDoS Protection Cost Optimization

Team Blog: Azure Network Security

Author: SaleemBseeu

Published: 02/18/2026

Summary: The article provides strategies for optimizing Azure DDoS Protection costs. It explains the differences between DDoS Network Protection (best for large-scale, centralized management) and DDoS IP Protection (for few, specific endpoints). Key recommendations include consolidating protection plans to reduce base costs, selectively applying protection based on workload exposure, preventing unnecessary spend via regular reviews, and using cost management tools and tagging for visibility. The guide emphasizes aligning protection with actual risk and criticality, and offers scripts and checklists to support ongoing cost-efficient DDoS defense.

Implementing Intune RBAC and Scope Tags for Zero Trust and Least Privilege

ChrisVetter — Mon, 30 Mar 2026 12:48:45 GMT

If you’re rolling out Microsoft Intune at scale, the hardest part usually isn’t creating policies—it’s making sure the right people can manage the right things, without turning every admin account into a “keys to the kingdom” risk. In this guide, you’ll learn how to use Intune RBAC and Scope Tags to enforce least privilege, build clear management boundaries by region/agency/environment, and pair device compliance with Entra Conditional Access to strengthen a Zero Trust posture—plus a practical RACI approach so ownership stays clear as your environment grows.

TL;DR

Use Intune RBAC to align admin permissions to job responsibilities, reducing standing privilege and limiting who can change policies, apps, and security settings.
Use Scope Tags to create visibility/management boundaries (region, agency, environment) so admins only see and manage what they own.
Pair Intune compliance + Entra Conditional Access to enforce “access only from compliant devices / protected apps,” which supports a Zero Trust posture.
Establish a RACI model so ownership is explicit across Endpoint, Identity, Security, Apps, AD, Help Desk, and Compliance teams.
Track outcomes (compliance rates, blocked risky sign-ins, RBAC audit events, scope boundary effectiveness, GPO migration progress) and review on a regular cadence.

Zero Trust and Least Privilege in Modern Endpoint Management

Zero Trust is an approach to security that treats every access attempt as untrusted until it is proven otherwise. Rather than relying on “inside the network = safe,” organizations evaluate each request using signals such as user identity, device health, location, and risk, and they re-check those signals over time. In an endpoint program, Microsoft Intune supports this model by establishing device compliance, applying app protection where appropriate, and working with Conditional Access so that access decisions can depend on verified user and device posture.

A practical way to describe Zero Trust is through three recurring themes: (1) make access decisions using explicit verification (strong authentication plus context and risk signals), (2) minimize privilege by granting only the access needed and reducing standing admin rights where possible, and (3) design for compromise by limiting lateral movement and reducing the impact of any single breach. These concepts align with Microsoft’s published Zero Trust guidance.

Role-Based Access Control (RBAC) in Intune allows organizations to delegate administrative permissions based on roles, responsibilities, and scope. For modern endpoint environments, RBAC ensures that only authorized personnel can manage devices, deploy configurations, or access sensitive data, which is a foundational control in a Zero Trust model where access is granted based on least privilege and verified identity.

By combining Intune's RBAC capabilities with Scope Tags, organizations can create visibility boundaries that align with their organizational structure, whether by region, department, business unit, or function. This prevents over-allowing permissions by assigning only the rights needed for each role, supports Zero Trust by enforcing least privilege and role-based access, and improves operational security by limiting who can manage devices and policies.

Understanding Intune RBAC Roles and Permissions

Microsoft Intune provides nine built-in RBAC roles designed to address common administrative scenarios. Each role has predefined permissions that determine what actions users can perform within the Intune environment, helping organizations delegate administrative tasks while maintaining control over access to sensitive information. The built-in roles include Intune Administrator with full access to all Intune features and settings (This role should not be used for every day management tasks and should be limited to only a few individuals who would be responsible for performing more elevated tasks in the Intune Portal), Policy and Profile Manager who manages device configuration profiles and compliance policies, Application Manager who manages mobile and managed applications, Endpoint Security Manager who manages security and compliance features, Help Desk Operator who performs remote tasks on users and devices, Read-Only Operator with view-only access, School Administrator for Windows 10 devices in Intune for Education, Intune Role Administrator who manages custom roles and assignments, and Cloud PC roles for managing Cloud PC features and Windows Autopatch roles for managing updates.

Built-in Role	Primary Permissions	Use Case
Application Manager	Manages mobile and managed applications, app configuration policies, and app protection policies	Teams responsible for deploying and managing organizational apps across devices
Policy and Profile Manager	Manages device configuration profiles, compliance policies, and conditional access policies	IT administrators configuring device settings and ensuring compliance across the organization
Endpoint Security Manager	Manages security baselines, endpoint detection and response, and BitLocker policies	Security teams focused on device protection and threat mitigation
Help Desk Operator	Performs remote tasks including device restart, password reset, and remote lock	First-line support staff assisting end users with device issues
Read-Only Operator	View-only access to all Intune data and reports without modification rights	Auditors and stakeholders needing visibility without administrative capabilities

Beyond built-in roles, Intune supports custom roles that allow administrators to define specific permissions for users or groups based on their responsibilities. Custom roles enable fine-grained access control by selecting granular permissions for each role, ensuring users have access only to the features and data they require. For example, a custom role could grant only the 'Rotate local administrator password' permission to a specific Helpdesk Managers group, demonstrating the principle of least privilege in action.

Create Custom Roles

Login to the Intune Admin Portal with the Intune Administrator Role and navigate to Tenant Administration> Roles > All Roles > Create then select the type of role you want to create. I will select “Intune Role”

Give your Custom Role a Name and a brief description.

Scroll through the list of permissions as they will all be set to no by default and select the permissions relevant to the responsibility of the custom role.

If you have already created your Scope Tag add it here, then review and select create

Once the role is created you can select the new role and create an assignment. Give it a name and description, then select the admin group to be assigned to the role.

Add the groups that the role will be managing.

Add your relevant Scope Tags then select create.

To take things one step further I would recommend leveraging Privileged Identity Management (PIM) for groups so that you can leverage Just-in-Time Assignments for the Intune roles.

One last note on custom roles if you do not want to start from scratch with the permission sets, you can also duplicate a built-in role and modify the permissions as needed. Just select the 3 dots to the right of the role and select Duplicate

Implementing Scope Tags for Distributed IT Management

Scope Tags are labels that help control what different admins can see and manage in Microsoft Intune. By adding scope tags to Intune items like configuration profiles, apps, policies, or device groups and assigning the same labels to admins, organizations create clear boundaries, so each admin only sees the devices and settings they are responsible for. This capability is essential for distributed IT environments where different teams manage different locations, departments, or business units.

Every Intune tenant includes a default scope tag that is automatically applied to all objects and admins, ensuring everything continues working smoothly even without custom tags configured. The key benefits of using scope tags include enabling distributed IT management by allowing regional or departmental admins to manage their specific resources, controlling access by limiting admin visibility to specific resources, enhancing security by preventing unauthorized access, improving organization by grouping resources by scope, and providing flexibility to support multiple administrative models.

Scope tags work together with RBAC role assignments through three components: the role defining what actions admins can perform, scope tags determining which objects admins can see, and scope groups limiting which users and devices they can affect. Common use cases for scope tags include managed service providers limiting access to specific customer resources, regional IT administrators ensuring teams only manage and see objects relevant to their region, separating testing versus production environments when a dedicated test tenant is not available, and separating Azure Virtual Desktop resources for AVD administrators.

Creating Scope Tags

While still under Tenant Administration> Roles select Scope Tags Then Create.

Give it a name and description.

Assign the proper groups then select create.

If this is all implemented properly, the admin will only be able to see items and devices that have the Scope tag that has been assigned to their role. Here are views of the apps in my tenant when signed in as a Intune Administrator (which Scope tags do not apply t

And here are the same views when logged in with an admin with the iOS admin role that we created.

Establishing a RACI Model for Intune Management

While establishing a RACI model is not something done in the Intune portal, it is crucial in my opinion for enterprise customers since Intune covers such a vast number of capabilities that should not all be done by one team if we are practicing least privilege and zero trust.

A RACI matrix is a powerful tool for defining organizational roles and responsibilities, identifying who is Responsible, Accountable, Consulted, and Informed for each activity. In Microsoft Intune management, implementing a RACI model eliminates ambiguity about which teams handle security policies, application management, patch compliance, Conditional Access, and GPO migration.

The RACI framework defines four key roles: Responsible individuals execute the task or deliverable, Accountable is the single person ultimately answerable for correct completion and decision-making authority, Consulted are experts or stakeholders whose feedback is sought during the task, and Informed are those kept up to date on progress or decisions without actively contributing.

For Intune environments, a well-designed RACI matrix promotes organizational alignment by mapping all key stakeholders across central IT and individual agencies or departments, clarifies decision rights by defining who approves, who executes, and who provides input for each Intune activity, ensures accountability by assigning a single accountable party for each deliverable to prevent diffusion of responsibility, and improves communication by identifying upfront who needs to be consulted and kept informed.

Based on internal implementation experience and with Microsoft Federal customers, organizations should list deliverables not just activities, define roles not individual names to ensure the matrix remains relevant as people change positions, enforce exactly one Accountable person per task, assign Responsible, Consulted, and Informed roles thoughtfully, validate in a short review session, publish where work happens, and evolve the matrix as the project evolves.

RACI Matrix for Security Policies and Compliance

The following are just generic examples of some of the workloads and how they could be managed with a RACI matrix.

Security policies and compliance management in Intune require clear ownership across multiple teams. Organizations must define who creates compliance policies requiring device encryption and minimum OS versions, who deploy security baselines like the Microsoft Defender for Endpoint Security Baseline, who manages Conditional Access policies that require device compliance, and who responds to non-compliant devices. A typical RACI model for security policies assigns the Cloud Security Team as Accountable for overall security policy strategy and compliance requirements, the Endpoint Team as Responsible for creating and deploying compliance policies and security baselines in Intune, the Application Team as Consulted for application-specific security requirements, the Help Desk as Informed about policy changes that may affect device compliance status, and the Compliance Team as Consulted to ensure policies meet regulatory requirements and as Informed about compliance status reports.

For patch management and application compliance, the RACI model shifts slightly with the Endpoint Team becoming Accountable for patch deployment strategy and timing, the Application Team becoming Responsible for testing application compatibility with updates, the Help Desk becoming Responsible for addressing user-reported issues after patches, and the Cloud Security Team becoming Consulted for security update prioritization. Organizations implementing Windows Autopatch benefit from Microsoft managing problematic quality and feature update deployment cancellations using telemetry, automatically splitting devices into rings based on percentage of total devices, and managing patching behavior for Windows, Microsoft 365 Apps, Edge, Teams, and Drivers. This shifts some Accountable and Responsible designations to Microsoft while keeping internal teams Informed and Consulted.

Intune Activity	Accountable	Responsible	Consulted	Informed
Security Policy Creation	Cloud Security Team	Endpoint Team	Application Team, Compliance Team	Help Desk
Compliance Policy Deployment	Cloud Security Team	Endpoint Team	Compliance Team	Help Desk, Application Team
Security Baseline Management	Cloud Security Team	Endpoint Team	Application Team	Help Desk, Compliance Team
Patch Management Strategy	Endpoint Team	Application Team	Cloud Security Team	Help Desk, Compliance Team
Non-Compliance Response	Cloud Security Team	Endpoint Team, Help Desk	Compliance Team	Application Team

Application and Conditional Access Management Responsibilities

Application management and Conditional Access in Intune span multiple organizational functions requiring coordinated responsibility. For application lifecycle management, the Application Team is both Accountable and Responsible for deployment strategy, app protection policies, creating and testing app packages and configurations. The Endpoint Team is Consulted for deployment targeting and device compatibility, while the Help Desk is Informed about new applications and support procedures.

For Conditional Access policy management, multiple teams coordinate their expertise. The Cloud Security Team is Accountable for overall Conditional Access strategy and Zero Trust implementation. The Endpoint Team is Responsible for ensuring device compliance status feeds correctly into Conditional Access decisions. The Identity Team is Responsible for configuring Conditional Access policies in Microsoft Entra ID. The Application Team is Consulted about application-specific access requirements, and the Help Desk is both Informed about access restrictions and Responsible for assisting users blocked by Conditional Access policies.

Conditional Access integration with Intune creates a powerful Zero Trust security model where Intune evaluates device compliance based on compliance policies, compliance status is reported to Microsoft Entra ID, Conditional Access policies check device compliance status, and access is granted or blocked based on compliance status.

For mobile application management, the Application Team is both Accountable and Responsible for app protection policies including data protection settings, access requirements like PIN and biometric authentication, and integration with Conditional Access. The Cloud Security Team is Consulted for security requirements, and the Endpoint Team is Informed about app-level controls that complement device-level policies.

GPO Migration to Intune: Roles and Responsibilities

Migrating Group Policy Objects from on-premises Active Directory to Microsoft Intune represents a critical transformation requiring clear ownership and phased execution. The migration process uses Group Policy Analytics, a built-in tool in Intune that analyzes on-premises GPOs by importing them as XML exports and translating them against the Settings Catalog to determine which policies are supported, deprecated, or unsupported in Intune.

Organizations export GPOs from the Group Policy Management Console by right clicking the GPO, selecting Save Report, and saving as XML format. After importing to Intune via Devices > Group Policy Analytics, the tool generates a percentage-based report showing exactly how many settings have a direct 1:1 mapping to modern Intune settings.

The Group Policy Analytics tool categorizes settings into three distinct types: Supported settings that have a direct counterpart in Intune and can be migrated via Settings Catalog policies, Deprecated settings no longer applicable to modern Windows versions, and Not Supported settings that do not currently have a CSP mapping and often require alternative management methods like PowerShell scripts or Proactive Remediations. Approximately 45% of GPOs can be successfully migrated to Settings Catalog, 30% require alternative approaches via PowerShell remediations, and 25% can be deprecated and retired based on typical migration outcomes.

RACI Model for GPO Migration

For the RACI model, the Endpoint Team is Accountable for the overall GPO migration strategy and timeline, the Active Directory Team is Responsible for exporting GPOs and documenting current policy structures, the Application Team is Consulted to validate that application-specific GPOs migrate correctly and that applications continue functioning, the Cloud Security Team is Consulted to ensure migrated policies maintain security posture, and the Help Desk is Informed about changes to device configurations and becomes Responsible for user communication about policy transitions.

Integrating Conditional Access with Device Compliance

Conditional Access integration with Intune device compliance creates an additional layer of security by enforcing access controls based on device compliance status and app protection policies. This integration ensures that only compliant devices and protected apps can access organizational resources, forming a cornerstone of Zero Trust architecture.

Device-Based Conditional Access Implementation

Device-based Conditional Access uses device compliance status from Intune to control access to organizational resources through a four-step process:

Intune evaluates device compliance based on compliance policies
Compliance status is reported to Microsoft Entra ID
Conditional Access policies check device compliance status
Access is granted or blocked based on compliance status

To implement device compliance Conditional Access, organizations first create and assign device compliance policies in Intune requiring elements like BitLocker encryption, Microsoft Defender antivirus enabled, Windows Firewall enabled, and minimum OS version requirements. Then in the Microsoft Entra Admin Center under Security > Conditional Access, administrators create policies specifying:

Users as target groups like Corporate Users
Cloud apps as All cloud apps or selected Microsoft 365 apps
Device platform as Windows or other platforms
Access control requiring device to be marked as compliant

Measuring Success and Continuous Improvement

Organizations implementing Intune RBAC and Scope Tags should establish metrics to measure success and identify areas for continuous improvement. Key performance indicators include percentage of devices compliant with security policies, time to resolve non-compliance issues, number of unauthorized access attempts blocked by Conditional Access, percentage of GPOs successfully migrated to Intune Settings Catalog, and administrative efficiency measured by reduction in time spent on routine management tasks.

Compliance reporting in Intune provides visibility into device compliance status across the organization, with reports showing compliant versus non-compliant devices, specific compliance policy violations, and trends over time. Organizations typically see compliance rates improve from a 65% baseline to 95% or higher within 12 months of implementing proper RBAC roles and Scope Tags. This improvement results from clearer ownership, faster policy deployment, and more focused administrative oversight.

Conditional Access sign-in logs in Microsoft Entra ID reveal which access attempts are granted or blocked, the reasons for access decisions, and patterns of risky sign-ins that may indicate compromised credentials or devices. For RBAC effectiveness, organizations should monitor audit logs to track which administrators are performing which actions, identify any privilege escalation attempts or suspicious administrative activity, and ensure separation of duties is maintained.

Scope tag effectiveness can be measured by confirming that administrators only see resources within their designated scope, tracking incidents where admins requested access outside their scope, and validating that regional or departmental segregation is working as intended. Organizations should establish a regular review cadence with monthly compliance and security posture reviews, quarterly RBAC and Scope Tag access reviews, bi-annual GPO migration progress assessments, and annual Zero Trust maturity assessments.

Disclaimer

All screenshots are from a non-production lab environment and can/will vary per environment. All processes and directions are of my own opinion and not of Microsoft and are from my years of experience with the Intune product in multiple customer environments

References

Role-based access control (RBAC) with Microsoft Intune - Microsoft Intune | Microsoft Learn

Use role-based access control (RBAC) and scope tags for distributed IT - Microsoft Intune | Microsoft Learn

Aligning responsibilities across teams - Cloud Adoption Framework | Microsoft Learn

How to Require Device Compliance with Conditional Access - Microsoft Entra ID | Microsoft Learn

Configuring Microsoft Intune just-in-time admin access with Azure AD PIM for Groups | Microsoft Community Hub

What Changed in RC4 with the January 2026 Windows Update and Why it is Important

Elanor92 — Mon, 23 Mar 2026 14:08:21 GMT

In case you haven’t heard, RC4 is not secure and has been deprecated. In this article, I will discuss what changed with the January 2026 Windows Update and why it is important to start auditing and remediate RC4 usage is your environment.

Starting with the January 13, 2026, Windows security updates, Microsoft began the first official phase of hardening Kerberos authentication by reducing reliance on RC4 encryption. The RC4 change will mainly impact service accounts and accounts that have the attribute msDS-SupportedEncryptionTypes left blank.

Why Microsoft Is Targeting RC4

RC4 is considered insecure due to cryptographic flaws that produce biased, non-random output, allowing attackers to recover encrypted data.

Despite this, RC4 remains enabled by default in many Active Directory environments for backward compatibility.

Microsoft tied the January changes to a Kerberos information disclosure vulnerability tracked as CVE-2026-20833, using this security update as the entry point to begin the RC4 deprecation process.

Update Timeline: From Audit to Full Enforcement

Microsoft is rolling out the Kerberos RC4 hardening in well-defined phases throughout 2026, giving organizations time to identify dependencies and remediate them before enforcement becomes mandatory. Understanding this timeline is critical to avoid outages.

Phase 1 – Initial Deployment (January 2026)

Starting on January 13, 2026, Windows security updates introduce the initial deployment phase.
This stage is focused on monitoring, not enforcement.

Key points of this phase:

New Kerberos audit events are logged on Domain Controllers (we will analyze them later in this article)
A temporary registry control setting (RC4DefaultDisablementPhase) has been introduced, allowing organizations to optionally enable stricter behavior ahead of time
No default behavior changes are applied

Phase 2 – Enforcement Enabled by Default (April 2026)

Beginning with the April 2026 Windows security update, Microsoft moves to the second deployment phase, where behavior changes start to matter operationally.

During this phase:

Enforcement mode is enabled by default on all supported Windows Domain Controllers, the default value for DefaultDomainSupportedEncTypes is set to allow AES-SHA1 only: 0x18

This changes the Kerberos KDC default behavior for accounts without an explicit msDS-SupportedEncryptionTypes configuration to allow RC4. RC4 is no longer negotiated implicitly for accounts with a blank msDS-SupportedEncryptionTypes, they will only receive AES encrypted tickets

While it is still technically possible to revert to audit behavior temporarily (by changing the value of the registry key mentioned above), it will be important to arrive in this phase with the remediation already completed.

Phase 3 – Full Enforcement (July 2026)

The final phase begins with the July 2026 security updates and represents the end of the transition period.

At this point:

Audit‑only mode is removed
The temporary RC4DefaultDisablementPhase registry value is no longer read
the default value for DefaultDomainSupportedEncTypes is set to AES-SHA1 only (0x18)
With this configuration, Kerberos will issue RC4 tickets only if explicitly configured per account using the attribute “msDS-SupportedEncryptionTypes ”

Organizations that didn’t address RC4 usage earlier will experience persistent service outages for legacy systems and applications not compatible with AES encryption.

How to prepare for the changes

It’s tempting to ignore the January changes because “nothing is broken,” but that would be a mistake. The new audit events are here to help you prepare for the changes.

Let’s analyze how we can leverage audit data to be ready before April 2026

Audit events

After the January Windows security update, some new events will start to appear in the system event logs of supported domain controllers if:

Your domain controller is receiving Kerberos service ticket requests that require RC4 cipher to be used but the service account has default encryption configuration
Your domain controller has an explicit DefaultDomainSupportedEncTypes configuration to allow RC4 encryption

To understand if your environment will be impacted by the change, you’ll need to audit the events 201,202,205,206,207 from the system event log. The events 203,204,208 and 209 will be logged starting from phase 2. See this Microsoft article for more details about the events.

These events are designed to help you identify accounts or services still requesting RC4encrypted tickets and clients or applications that do not support AES. This gives administrators a safe discovery phase to identify dependencies before anything stops working.

Identify High Risk Dependencies

Not all RC4 usage has the same impact. The audit events allow administrators to prioritize remediation by identifying:

Service accounts that rely on RC4 due to missing or outdated encryption keys, such as accounts that have not had password reset in years
Legacy applications or appliances that cannot negotiate AES

Service accounts deserve special attention because they are commonly affected by RC4 dependencies and are high value targets in Kerberoasting scenarios.

Validate Kerberos Encryption Configuration

One of the most important insights provided by the new events is whether accounts are missing AES‑compatible Kerberos keys (msDS-SupportedEncryptionTypes).

In many cases, RC4 usage is not intentional but happens because the account password has never been reset since AES support was introduced or because the encryption types are implicitly inherited rather than explicitly defined.

The audit data allows you to confirm which accounts already support AES and which ones will fail once AESonly behavior becomes the default.

Establish a Remediation Baseline Before April

By the time the April 2026 enforcement phase begins, you should already have:

Reviewed Kerberos audit events across all domain controllers
Identified all RC4-dependent accounts and services
Confirmed AES compatibility where possible
Documented any unavoidable legacy dependencies

The January audit data is meant to drive these actions early, while remediation can still be planned and tested calmly.

Why the January Update Matters (Even If Nothing Breaks Yet)

Since the creation of AES-SHA1 tickets has been implemented in Windows Server 2008R2, I’m confident that many organizations won’t have issues with this transition and can use these phases to validate their configurations.

If you didn’t have the chance or the time to address the RC4 usage earlier, don’t give into the temptation to ignore the January changes, because that would be unwise. The audit events that have been introduced are your only early warning system to avoid Kerberos authentication failures, problems with legacy applications, and service accounts failing due to missing AES keys.

In practice, the January update is the last safe window to:

Identify RC4‑only service accounts
Detect non-AES-capable clients
Fix misconfigured Kerberos encryption settings on your terms

Organizations that use this phase to audit, remediate, and modernize will transition smoothly.
Those who ignore it risk discovering RC4 dependencies only when enforcement is already active.

Remove Unnecessary Azure Storage Account Dependencies in VM Diagnostics

hspinto — Mon, 16 Mar 2026 07:00:00 GMT

In a recent engagement with a customer willing to decrease Shared Access Signature (SAS) tokens usage in their Storage Accounts, we found out that a good amount of SAS token-based requests was associated with VM diagnostics. One practical way to reduce SAS token usage is to eliminate dependencies that require Storage Accounts in the first place, especially when Azure offers managed alternatives.

This post focuses on two VM-level features that often introduce (or preserve) unnecessary Storage Account coupling:

The legacy IaaS Diagnostics extension (retiring), which can write diagnostic data to Storage
Boot diagnostics configured to use a customer-managed Storage Account, considering Microsoft-managed boot diagnostics works as well without any operational effort.

1) Retire the legacy IaaS Diagnostics extension

If you’re no longer using the legacy IaaS Diagnostics extension for VM monitoring and troubleshooting, removing it is an easy win: it reduces Storage Account coupling and helps you stay ahead of platform deprecations. Microsoft has announced retirement of the extension as of March 31, so now is a good time to inventory and remove it where it’s still present.

How to find affected VMs

Use Azure Resource Graph (ARG) to identify virtual machines with the extension installed across subscriptions at scale. Once you have the list, you can remove the extension directly from the Azure portal or using your preferred automation approach (PowerShell or Azure CLI).

For a proven at-scale removal pattern (including cleanup of the data the extension produced), see How to remove at scale the Azure Diagnostics Extension and its storage data.

2) Switch boot diagnostics to Microsoft-managed storage

Boot diagnostics are invaluable when you need VM boot screenshots/logs and serial console access. Historically, it required a customer-managed Storage Account—often leading teams to create “diagnostics” Storage Accounts, wire up access, and sometimes rely on SAS tokens to make the integration work across tooling.

Today, you can enable boot diagnostics without providing a Storage Account by using managed boot diagnostics (Microsoft-managed storage). In most scenarios, this removes an entire class of dependency without sacrificing functionality. The switch is also operationally friendly: it does not require a VM reboot and doesn’t interfere with the guest OS.

How to find and migrate at scale

As with extensions, Azure Resource Graph is a good starting point to identify VMs that have boot diagnostics enabled against a customer-managed Storage Account. Use the query below to identify those VMs:

resources | where type =~ 'microsoft.compute/virtualmachines' | extend diagProfile = properties.diagnosticsProfile.bootDiagnostics | extend powerState = tostring(properties.extended.instanceView.powerState.code) | extend diagAccount = tostring(split(parse_url(tostring(properties.diagnosticsProfile.bootDiagnostics.storageUri)).Host,'.')[0]) | extend bootDiagnosticsEnabled = tobool(properties.diagnosticsProfile.bootDiagnostics.enabled) | project name, resourceGroup, subscriptionId, powerState, bootDiagnosticsEnabled, diagAccount | where bootDiagnosticsEnabled and isnotempty(diagAccount)

After you’ve validated the impact in a non-production subscription, you can automate migration in bulk to enable managed boot diagnostics, by using the Set-AzVMBootDiagnosticsWrapper.ps1 script. Simply download it, unblock it (file properties > unblock), and upload it to Azure Cloud Shell.

Example PowerShell usage pattern:

./Set-AzVMBootDiagnosticsWrapper.ps1 -Action EnableManaged [-TargetSubscriptionId <sub id>] [-ARGFilter <ARG condition, e.g., resourceGroup =~ 'xyz'>] [-Simulate]

Wrap-up

Reducing SAS token usage isn’t only about replacing tokens with another credential type —it’s also about removing the underlying dependencies that make tokens attractive in the first place. By (1) removing the retiring IaaS Diagnostics extension and (2) migrating boot diagnostics to Microsoft-managed storage, you can simplify your VM baseline, reduce Storage Account sprawl, and stay ahead of deprecations. As a next step, consider standardizing these checks in your provisioning pipelines (Bicep/Terraform), and add periodic ARG-based hygiene queries to keep drift under control.

Bulk enable Azure Arc Connected Machine Agent Automatic Upgrade (Tag Scoped) with Azure Cloud Shell

absharan — Thu, 12 Mar 2026 20:38:28 GMT

Overview

Keeping the Azure Arc Connected Machine agent current is a foundational hygiene task for any hybrid server estate, especially when you’re operating at scale and onboarding hundreds (or thousands) of machines into Arc.

The good news: Azure Arc supports an automatic agent upgrade (preview) capability that can be enabled per Arc machine by setting the agentUpgrade.enableAutomaticUpgrade property via Azure Resource Manager (ARM). Microsoft’s public guidance shows enabling this using a PATCH call (via Invoke-AzRestMethod) against the Arc machine resource with the 2024-05-20-preview API version. Manage and maintain the Azure Connected Machine agent - Azure Arc | Microsoft Learn

In real environments, you rarely want to enable this across every Arc-enabled server in one shot. Instead, you typically:

start with a pilot ring (e.g., Dev/Test or low‑risk servers),
validate results, and then
expand coverage gradually.

The Script: Abhishek-Sharan/ExtensionManagement: Install & Manage Extensions

The script implements exactly that approach by:

prompting an explicit disclaimer acknowledgement (safety gate),
selecting Arc machines by tag (a controlled blast-radius technique),
enabling automatic upgrade using ARM PATCH through Invoke-AzRestMethod,
producing a final summary report of success/failure per machine.

This post walks through what the script does, why each section exists, and what to consider before using it in production.

Why Tag‑Scoped Enablement?

In many enterprise deployments, tags are the simplest way to define a “ring” of servers:

Ring=Pilot
Environment=NonProd
Workload=LowRisk

This script discovers resources of type Microsoft.HybridCompute machines in a given resource group and filters them by a tag/value pair. That makes it easy to:

onboard machines first,
apply tags as part of provisioning,
then flip on agent auto-upgrade only for the right cohort.

Script Details (Walkthrough)

1) Safety Gate: Disclaimer + Explicit User Consent

This script prints a disclaimer block and requires the operator to type Y to proceed. If the user types anything else, the script exits.

Why it matters:

It prevents accidental execution (especially in shared shells or jump boxes).
It reinforces that this is a potentially impactful change across multiple machines.

2) Configuration: Subscription, Resource Group, and Tag Scope

The script sets the active Azure context:

Set-AzContext -Subscription "YOUR SUBSCRIPTION"

Then defines:

$resourceGroup
$tagName, $tagValue

3) Discovery: Find Azure Arc Machines with a Target Tag

Discovery uses:

Get-AzResource -ResourceType "Microsoft.HybridCompute/machines"
filters by tag match on the returned resource object.

This ensures you are only targeting Arc-enabled servers represented as Microsoft.HybridCompute machines resources.

If no machines are found, the script exits cleanly, which avoids the “silent no-op” problem and helps operators quickly validate that scope selection is correct.

4) Update: Enable Automatic Upgrade via ARM PATCH

For each machine, the script uses Invoke-AzRestMethod with:

ResourceProviderName = "Microsoft.HybridCompute"
ResourceType = "Machines"
ApiVersion = "2024-05-20-preview"
Method = "PATCH"
payload:

{"properties":{"agentUpgrade":{"enableAutomaticUpgrade":true}}}

5) Output: Per‑Machine Result + Final Summary Table

The script records results into an array of PSCustomObject entries with:

MachineName
EnableAutomaticUpgrade
Result (Success/Failed)

Then prints a formatted table.

This is useful for:

quick operator confirmation,
change records,
attaching output to internal work items / change tickets.

Conclusion

This script is a solid operational accelerant for teams managing Arc-enabled servers at scale. It combines:

safety (explicit disclaimer + opt-in),
control (tag-based targeting),
automation (bulk enabling via ARM PATCH),
observability (clear per-server results and a final summary).

If you’re trying to standardize operational hygiene across hundreds of Arc machines, tag-scoped enablement like this is one of the cleanest ways to start small, learn safely, and then scale.

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

TysonPaul — Wed, 11 Mar 2026 15:55:52 GMT

Member: TysonPaul | Microsoft Community Hub

Secure DNS with DoH: Public Preview for Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 02/09/2026

Summary: Microsoft has launched a public preview of DNS over HTTPS (DoH) for Windows DNS Server, available in the February 2026 update for Windows Server 2025. DoH encrypts DNS queries and responses, enhancing authentication and privacy while maintaining existing server functions. This move aligns with Zero Trust security principles and supports U.S. federal cybersecurity requirements. The feature is disabled by default, is not production-ready, and currently only encrypts client-to-server traffic. Feedback is encouraged during the preview phase, with future updates planned for upstream encryption support.

Azure Blob Tiering: Clarity, Truths, and Practical Guidance for Architects

Team Blog: Azure Infrastructure

Author: nehatiwari1994

Published: 02/06/2026

Summary: The article explains Azure Blob Storage tiering for backup architects, debunking common misconceptions about tier performance and access. Hot, Cool, and Cold tiers are online and offer immediate data access; minimum retention is a billing rule, not a technical limit. Archive tier requires rehydration before restores. Restore speed depends on throughput architecture, not tier. Cost is influenced by both storage and access patterns. Effective tiering strategies and lifecycle policies are essential for scaling backup repositories from terabytes to petabytes, ensuring operational safety and cost control. The article offers practical design recommendations and clarifies Azure tier behaviors.

AKS Tenant Migration: Considerations and Approach

Team Blog: Azure Infrastructure

Author: SoumyaShet05

Published: 02/05/2026

Summary: 321: No summary could be found for article: [AKS Tenant Migration: Considerations and Approach] [https://techcommunity.microsoft.com/blog/azureinfrastructureblog/aks-tenant-migration-considerations-and-approach/4415198].

What’s new in FinOps toolkit 13 – January 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 02/09/2026

Summary: FinOps toolkit 13 (January 2026) delivers stability and usability improvements for cloud cost management, including enhanced documentation, Key Vault purge protection options, Power BI report fixes, and streamlined Cost Management exports via PowerShell with Parquet support. The release strengthens security, reliability, and extensibility for enterprise-scale deployments. Community engagement is emphasized with new office hours. Future plans include AI-driven automation, expanded recommendations, and premium support services. The toolkit remains open-source and continues to evolve with community contributions and ongoing enhancements across Microsoft Cloud environments.

Reading GPSVC Like a Crime Novel

Team Blog: Ask the Directory Services Team

Author: Chris_Cartwright

Published: 02/25/2026

Summary: The article, "Reading GPSVC Like a Crime Novel," explains how to troubleshoot Group Policy issues using the enhanced GPSVC debug log in modern Windows 11 versions. It details the two core phases of Group Policy processing, emphasizes the importance of following log threads, and highlights the benefit of new date and time stamps for better correlation with other events. The post also covers enabling verbose logging, interpreting log entries, and using additional tools like TSS for deeper analysis, ultimately making GPSVC logs more powerful for diagnosing Group Policy problems.

What’s New in Windows Group Policy Preferences Debug Logging

Team Blog: Ask the Directory Services Team

Author: TagoreN

Published: 02/27/2026

Summary: The article outlines enhancements to Windows Group Policy Preferences (GPP) debug logging in Windows 11 versions 24H2 and 25H2 (from February 2026 preview updates). Administrators can now enable verbose GPP debug logging directly via Local Group Policy, not just domain-based GPOs. This change simplifies troubleshooting, reduces reliance on domain controllers, and allows easier, flexible diagnostic workflows on client devices. The article explains how to configure logging settings, log locations, and necessary permissions, highlighting a significant quality-of-life improvement for IT professionals managing GPP issues.

Azure Landing Zone and compliance for Banks (Indian Banks)

Team Blog: Azure Migration and Modernization

Author: srhulsus

Published: 02/12/2026

Summary: **Summary:** Azure Landing Zone (ALZ) provides Indian banks with a secure, compliant, and auditable cloud foundation, aligning with RBI and global standards (ISO 27001, PCI-DSS, FFIEC). It features subscription isolation, centralized IAM, robust network and data security, mandatory encryption, continuous monitoring, and business continuity controls. ALZ ensures India data residency, policy automation, regulatory audit support, and secure exit management. The architecture is regulator-accepted and proven by major banks, supporting governance, risk, and compliance mandates for hosting sensitive, regulated banking workloads on Azure.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 02/18/2026

Summary: The article outlines a structured, five-phase approach for migrating workloads from AWS to Azure, emphasizing a “like-for-like” architecture to minimize risk and complexity. Key phases include planning, preparation, execution, evaluation, and decommissioning, with blue/green deployment recommended for risk reduction. Success hinges on comprehensive documentation, stakeholder alignment, phased validation, and having the current workload team lead the migration. External partners can assist with planning but should not execute cutovers. Once stability on Azure is achieved, optimization can begin. Thorough preparation and collaboration are essential for a confident, disruption-free migration.

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/20/2026

Summary: Starting June 16, 2026, Intune will require HTTPS for Microsoft Connected Cache nodes serving Win32 apps. To retain bandwidth savings and localize content, admins must configure HTTPS on their Connected Cache servers by preparing a TLS certificate, generating a CSR on the node, signing it with a CA, importing the certificate, and validating HTTPS. The process is similar for Windows and Linux hosts. Regular certificate monitoring and renewal are necessary. Without HTTPS, devices will fall back to CDN. Improvements and fixes are underway, and early setup ensures readiness for the upcoming enforcement.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/02/2026

Summary: The article explains how to resolve device noncompliance issues in Microsoft Intune when using Mobile Threat Defense (MTD) partner apps like Microsoft Defender for Endpoint. It outlines steps for users to restore compliance, including installing or activating the MTD app, refreshing the app’s connection, or reinstalling it. It also details simplified remediation for iOS/iPadOS and steps to refresh the MTD connection on Android if sign-out is blocked. The guidance helps organizations ensure device compliance and secure access to work or school resources while reducing support overhead.

Announcing Public Preview: Simplified Machine Provisioning for Azure Local

Team Blog: Azure Arc

Author: PragyaDwivedi

Published: 02/26/2026

Summary: Microsoft has announced the public preview of Simplified Machine Provisioning for Azure Local, streamlining edge infrastructure deployment by shifting configuration to Azure. IT teams can now centrally define and automate provisioning using Azure Arc, with minimal onsite interaction—staff only need to rack, power on hardware, and use a prepared USB. Built on the FIDO Device Onboarding standard, this approach ensures secure, consistent device onboarding and management at scale, with end-to-end deployment visibility. This new process enables faster, less error-prone deployments, allowing organizations to efficiently provision and manage Azure Local infrastructure across multiple sites.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Team Blog: Azure Networking

Author: cozhang

Published: 02/06/2026

Summary: The article introduces the Azure StandardV2 NAT Gateway, highlighting new features such as zone-redundancy, enhanced throughput, dual-stack IP support, and the availability of flow logs. Flow logs provide detailed outbound traffic data, improving security, compliance, and troubleshooting. They help monitor traffic patterns, identify issues like connection drops, and optimize network architecture. The article explains enabling and using flow logs for diagnostics, emphasizing their value in validating connectivity and auditing outbound flows, and encourages users to leverage these insights for resilient Azure deployments.

Migration, Modernization & Agentic Tools

Team Blog: ITOps Talk

Author: OrinThomas

Published: 02/25/2026

Summary: The article discusses how agentic tools are transforming cloud migration and modernization by introducing autonomy, continuous optimization, and context-aware decision-making. Rather than a one-time process, migration becomes an ongoing, self-improving system with tools like Azure Copilot and GitHub Copilot. These tools automate environment discovery, recommend modernization paths, execute migrations, validate and optimize workloads, and ensure governance. They classify workloads, automate migration waves, and continuously enhance cost, performance, security, and compliance, reducing manual effort and errors while enabling safe, efficient, and policy-driven cloud transitions.

Automating Large‑Scale Data Management with Azure Storage Actions

Team Blog: ITOps Talk

Author: 1Nataraj

Published: 02/25/2026

Summary: Azure Storage Actions is a fully managed, serverless automation platform that enables customers to automate large-scale data management tasks—such as tiering, tagging, deletion, and applying immutability policies—across Azure Blob Storage and Data Lake Storage without custom code or infrastructure. It uses reusable, condition-based storage tasks and assignments, supporting compliance, cost optimization, and operational efficiency. The platform provides built-in monitoring, auditing, and preview features, making it suitable for scenarios requiring traceability. Common use cases include regulatory compliance, cost control, and metadata management across industries like finance, airlines, and manufacturing.

Securing A Multi-Agent AI Solution Focused on User Context & the Complexities of On-Behalf-Of.

Team Blog: Azure Architecture

Author: Charles_Chukwudozie

Published: 02/11/2026

Summary: The article outlines how an enterprise-grade multi-agent AI system was designed to securely preserve user identity and enforce access controls when AI agents interact with backend services like Databricks. By implementing Microsoft Entra ID’s On-Behalf-Of (OBO) flow, each AI agent operates strictly within the authenticated user’s permissions, maintaining RBAC policies and an audit trail. The solution uses a custom OAuth provider, per-user agent instances, and human-in-the-loop approval for sensitive operations, aligning with Zero Trust principles and ensuring robust AI governance for enterprise applications.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service (AKS)

Team Blog: Azure Architecture

Author: rgarofalo

Published: 02/03/2026

Summary: This article presents a reference architecture for deploying Azure Kubernetes Service (AKS) across multiple Azure regions to maximize availability and resilience. It compares active/active, active/passive, and deployment stamp patterns, detailing trade-offs in availability, complexity, and cost. Key components include Azure Front Door for global routing, geo-replicated data services, centralized monitoring, and consistent security. The article emphasizes clear design choices, regular testing, and operational preparedness, highlighting that multi-region resilience requires coordinated patterns, not a simple switch, and should align with business RTO/RPO objectives and operational maturity.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

Team Blog: Azure Storage

Author: ellievail

Published: 02/26/2026

Summary: Microsoft has announced the public preview of user-bound user delegation SAS for Azure Storage, enhancing security by restricting SAS token usage to a specific Microsoft Entra ID identity. This extension of user delegation SAS ensures only the designated user can access storage resources, reducing the risk of unintended access. The feature is available at no additional cost in all public regions and supports cross-tenant scenarios. It integrates with existing Azure RBAC and is accessible via REST APIs, SDKs, PowerShell, and CLI. Setup involves assigning the correct roles, obtaining user IDs, and generating the SAS token.

Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets

Team Blog: Azure Storage

Author: Lakshya_Jalan

Published: 02/18/2026

Summary: 321: No summary could be found for article: [Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets] [https://techcommunity.microsoft.com/blog/azurestorageblog/azure-migrate-now-supporting-premium-ssd-v2-ultra-and-zrs-disks-as-targets/4495332].

Bringing AI fluency to every corner of the organization (even yours!)

Team Blog: Microsoft Learn

Author: AshleyMastersHall

Published: 02/19/2026

Summary: The article emphasizes the importance of AI fluency for all roles within organizations, likening AI’s impact to the transformative effect of GPS on navigation. It defines AI fluency as understanding and effectively using generative AI in care tasks, now a critical skill for the modern workplace. The author provides practical, approachable steps to integrate AI into daily workflows, recommends starting small, and highlights Microsoft’s AI Skills Navigator as a resource. The core message: AI is already changing work, and building fluency—starting with familiar tasks—ensures continued relevance and success.

Microsoft Credentials roundup: February 2026 edition

Team Blog: Microsoft Learn

Author: PujaA

Published: 02/26/2026

Summary: Microsoft’s February 2026 Credentials roundup introduces four new AI-focused Certifications and six new Applied Skills, targeting both technical and business professionals. These credentials validate expertise in AI integration, Copilot, and agent solutions, enhancing career prospects in an AI-powered workplace. Applied Skills offer quick, practical assessments in real-world AI tasks. Several older Certifications and Applied Skills are being retired, reflecting Microsoft’s ongoing commitment to current, relevant skills. Additional AI-focused updates are planned for March 2026 and beyond, further expanding learning and credentialing opportunities in AI and cloud technologies.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

Team Blog: Azure Compute

Author: HilaryWang

Published: 02/17/2026

Summary: Azure has introduced the public preview of automatic zone balance for Virtual Machine Scale Sets, which ensures VMs are evenly distributed across availability zones with no manual intervention. This feature continuously monitors and rebalances VMs, minimizing the impact of zone failures and maintaining optimal resiliency. It uses a create-before-delete approach with health checks and built-in safety measures, reducing operational overhead and ensuring workload stability. Automatic instance repairs are enabled by default. To use this feature, register for the preview, meet prerequisites, and enable it via the Azure portal, CLI, PowerShell, or REST API.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 02/04/2026

Summary: Azure Automated Virtual Machine Recovery is a built-in Azure feature designed to minimize VM downtime by automatically detecting, diagnosing, and mitigating failures within seconds, without customer intervention. It operates continuously, leveraging multiple detection mechanisms and optimized recovery paths, ensuring business continuity and consistent SLA compliance. Recovery Event Annotations provide deep visibility into the recovery process, helping identify bottlenecks and improve reliability. Over the past 18 months, this system has halved average VM downtime, empowering customers to confidently run resilient applications with reduced risk of service disruption and financial loss. No setup is required; all Azure VMs benefit automatically.

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Team Blog: Azure Tools

Author: Alex-wdy

Published: 02/03/2026

Summary:

The Nightmare of renewing NDES Enrollment Agent Certificates

DagmarHeidecker — Mon, 09 Mar 2026 07:28:55 GMT

NDES EA Certificates – Quick Recap

By default, three version 1 certificate templates are assigned to your Certification Authority by the configuration routine of the NDES service:

CEP Encryption - Used by the device to encrypt communication with NDES
Exchange Enrollment Agent (Offline Request) - Used to request certificates on behalf of another subject
IPSec (Offline request) - Default template to enroll certificates to devices

All certificate templates from the list above are version 1 certificate templates. Number 1 and 2 share the common characteristic of having the Extended Key Usage (EKU) extension set to include the OID 1.3.6.1.4.1.311.20.2.1, which corresponds to “Certificate Request Agent”. In this article template number 1 and 2 (from the list above) will be referred to as “NDES Enrollment Agent certificate(s) templates”.

Version 1 certificate templates originated with Windows 2000 and have functional and security limitations. Since the autoenrollment feature did not exist at that time, these templates do not support autoenrollment and instead rely on Automatic Certificate Request Settings, a legacy mechanism that is no longer recommended. Furthermore, the only property that can be modified on a version 1 template is the set of assigned permissions that controls access to the template. Find more details in Certificate Template Concepts.

Certificate Enrollment (or Request) Agents were designed to enable trusted principals to perform certificate enrollment on behalf of other users or devices (aka Enroll-on-behalf). NDES is a concrete implementation of this concept as it enrolls certificates for entities other than itself.

The enrollment of the NDES EA certificates based on certificate templates number 1 and 2 (see above) during NDES configuration is hard‑coded in the configuration routine. This design choice from many years ago introduces several challenges:

Security: in case you misconfigure the default NDES certificate templates security settings, they are vulnerable to CVE-2024-49019. A detailed explanation of this vulnerability is out of scope here; however, as a general best practice, certificate templates version 1 should not be used.
The default “Exchange Enrollment Agent (Offline request)” certificate template (default template number 2. as per above) is a user template and the installation routine “somehow magically” imports this certificate into the machine store. This makes automatic renewal challenging...
Version 1 certificate templates have significant functional limitations, as they cannot be modified (except for security settings):
- The validity period (2 years) cannot be changed. For NDES EA certificate templates the validity period is 2 years.
- The template’s CSP[1] cannot be modified. As a result, NDES Enrollment Agent certificates cannot be enrolled in a Hardware Security Module (HSM).
- Version 1 templates do not support Autoenrollment. Consequently, NDES service certificates therefore must be renewed manually. When the Enrollment Agent certificates expire, NDES stops working.
- Version 1 templates lack template-level access control and modern enrollment safeguards (e.g. Certificate Manager Approval).

[1] NDES does not support KSP for EA certificates.

As you can see, there are several reasonable arguments to replace the default NDES service certificate templates.

Configuring custom NDES Service Certificate Templates

Generally, there are two ways of creating some kind of “fire and forget” certificate templates for NDES:

Common Windows Active Directory Autoenrollment can be used if there is no need for a custom name/subject in the request agent certificates.
We can use key-based renewal (KBR) which allows us to create custom subjects in the certificates even together with automatic renewals.

The NDES service will not verify the certificates’ subject information. It will just verify that the certificates have “request Agent” EKU (1.3.6.1.4.1.311.20.2.1).

In a nutshell, you will need to duplicate two version 1 certificate templates and modify those to fit your needs. See table below for detailed description of settings.

In addition to that, there are a few more things to consider:

NDES service account

There are different options for creating the SCEP IIS App Pool identity. As Microsoft recommends using a hardened Tier 0 domain user account, this article will focus on this configuration. By default, domain user accounts do not have any permissions on private keys in the computer certificate store. Therefore, you must grant READ permissions to the NDES service certificate private keys either manually or in the certificate template configuration. This can be configured on the Request Handling tab as we will see later in this article.

(Source) Certificate Templates to duplicate

Certificate templates include a flag that is hidden from the GUI and determines whether a template is treated as a user or a computer certificate template. If you are curious, the command certutil -ds -v “CEPEncryption” will make it visible. Look out for CT_FLAG_MACHINE_TYPE in the output. This distinction is important in our scenario because the Exchange Enrollment Agent (Offline Request) template does not include this flag. As a result, certificates based on this template can only be enrolled into the user certificate store. To ensure the new template replacing the Exchange Enrollment Agent (Offline Request) template supports enrollment into the computer certificate store, we use the Enrollment Agent (Computer) default template as the source template.

Subject and SAN for NDES Service Certificates

Subject/SAN can either be built from Active Directory or provided in the request.

a) Build (subject) from this Active Directory information (option 1 from above – using common autoenrollment)

Using Common Name and DNS name is common practice. Subject and/or SAN will simply include the NDES computer account name.

As this may not be appropriate in all scenarios, we also have option...

b) Supply (subject) in the request (option 2 from above – using key-based renewal)

While this option gives you the freedom of choosing a proper Enrollment Agent subject information and SAN, it comes at the price of some additional configuration requirements to allow secure and automatic renewal of NDES service certificates. Using the key based renewal feature, we will have to initially enroll the NDES service certificates manually. Renewal will happen automatically. To implement this, both NDES service certificate templates must be configured as described below:

Subject Name tab

Issuance Requirements tab

Extensions tab

“Certificate Request Agent” is the only Application Policy required.

Please note that “Client Authentication” is required as an additional Application Policy in case you use CEP and CES for key based renewal.

Request Handling and Security tab

NDES EA Certificate Template Configuration Summary

Default NDES service certificate template	CEP Encryption	Exchange Enrollment Agent (Offline Request)
Template to duplicate	CEP Encryption	Enrollment Agent (Computer)
Compatibility settings	Certification Authority: Windows Server 2016 Certificate recipient: Windows 10/Windows Server 2016
General	Provide a name for the new certificate template.
Request Handling	In case the SCEP AppPool is configured to run in the security context of a domain account, you must grant READ access to the private key to the NDES service account. Otherwise, no changes are required on this tab.
Cryptography	If available, configure an HSM backed CSP or adjust the key length as required. Note that Key Storage Providers (KSPs) are not supported for NDES service certificates.
Subject Name	Either choose Build from this Active Directory information or choose Supply in the request + key-based renewal.
Issuance Requirements	Because of NDES’ Enroll-on-behalf capability described above, the NDES service certificates are very powerful. We therefore recommend enforcing CA certificate manager approval for enrollment. Please keep in mind that this will interrupt the automatic renewal process of the certificate if not using KBR.
Extensions	The default Application Policy is Certificate Request Agent. Do not change it. In case key based renewal is enabled, Client Authentication must be added as an Application Policy.
Security	Grant ENROLL and AUTOENROLL* permissions to the NDES Computer account only. * Autoenrollment only makes sense for option a - Autoenrollment

Housekeeping

After new EA certificates have been enrolled…

Unassign version 1 certificate templates from all CAs
Revoke all previously issued NDES EA certificates and remove them from NDES server.
Restart NDES service (execute to reload the web service and certificates)

Final Thoughts

NDES Enrollment Agent certificates are highly privileged and should never rely on legacy version 1 templates. Replacing them with custom templates that support HSMs and secure automatic renewal significantly reduces outage risk and closes known security gaps.

The Future of Identity: Self-Service Account Recovery (Preview) in Microsoft Entra

Farooque — Thu, 05 Mar 2026 16:47:10 GMT

In the modern enterprise, the "Help Desk" is paradoxically both a vital resource and a massive security liability. As organizations move toward phishing-resistant, passwordless environments using passkeys and FIDO2 tokens, a critical question remains: What happens when a user loses their only authentication device?

Historically, this required a phone call to a support agent. However, in an era of sophisticated social engineering and AI-generated deepfakes, a human agent is often the easiest point of entry for an attacker. Microsoft Entra’s new Self-Service Account Recovery solves this by replacing manual verification with high-assurance, automated identity proofing.

The Fatal Flaw in Traditional Recovery

Most organizations currently rely on one of two methods for recovery, both of which have significant drawbacks:

Self-Service Password Reset (SSPR): Often relies on "weak" factors like SMS codes or security questions. These are easily intercepted or guessed and don't help a user who is trying to move away from passwords entirely.
The Help Desk: Requires an agent to "vouch" for a user. Attackers can impersonate employees, use voice-cloning technology, or provide leaked personal information to trick an agent into issuing a Temporary Access Pass (TAP).

The new Entra flow removes the human element from the validation process, ensuring that the person regaining access is exactly who they claim to be.

How the New Recovery Flow Works:

The recovery process is built on the concept of "identity proofing," utilizing government-issued documents and biometric liveness checks.

Integration with Verification Partners

Microsoft doesn’t store your passport or driver's license. Instead, Entra integrates with specialized Third-Party Identity Verification providers (such as True Credential, IDEMIA, AU10TIX). These services are experts in forensic document analysis.

The Verification Process

When a user begins a recovery, they are redirected to the partner service. The process typically involves:

Document Capture: The user takes a photo of a government ID (Passport, Driver’s License, etc.).
Forensic Analysis: The service checks for security features like holograms, fonts, and watermarks to ensure the ID is genuine.
Liveness Check: The user takes a "selfie" or video. The system uses "Face Check" technology projecting specific light patterns or colors on the user’s face to ensure it is a live person and not a photo, video, or deepfake.

Issuance of a Verified ID

Once the third party confirms the user's identity, Microsoft Entra issues Verified ID. This is a decentralized, digital credential that sits in the user's Microsoft Authenticator app. It serves as digital proof of their identity that Entra can trust.

The Final Handshake: Face Check

To bridge the gap between the digital credential and the person at the keyboard, Entra performs a Face Check. It compares the live user's face against the photo contained within the Verified ID. If they match, Entra considers the identity "proven."

Bootstrapping the New Device

Once verified, Entra automatically issues a Temporary Access Pass (TAP). This allows the user to log in and immediately register their new device, passkey, or Authenticator app, effectively "bootstrapping" their new secure environment without ever speaking to a human.

Strategic Advantages for IT Leaders

Zero Trust Maturity: This process fulfills the Zero Trust requirement of "explicit verification" even during the recovery phase.
Scalability: By automating the most time-consuming part of help desk tickets identity verification IT teams can focus on more complex tasks.
Phishing Resistance: Because the recovery is tied to physical ID and biometrics, there is no "code" for an attacker to phish.
Global Compliance: Leveraging government-issued IDs allows organizations to meet high-bar regulatory requirements for identity assurance (such as NIST IAL2).

Deployment and Prerequisites

To implement this, administrators need to ensure a few things are in place:

Verified ID Setup: You must configure Microsoft Entra Verified ID within your tenant.
Matching Logic: Entra uses attributes like First Name and Last Name to match the Verified ID to the user account. Ensuring your HR data is clean and synchronized is essential.
License & Costs: While the recovery flow is a feature of Entra, the verification partners and the Face Check service (typically a per-check fee) must be provisioned through the Microsoft Security Store.

Conclusion

The transition to a passwordless world is incomplete if the "back door" (recovery) remains open and insecure. By integrating government-grade identity verification directly into the login flow, Microsoft Entra provides the final piece of the puzzle: a recovery method that is as secure as the primary login itself.

Demystifying the Client Repeatable Feature in Edge

hewagen — Mon, 02 Mar 2026 07:09:40 GMT

Autofill behavior in modern browsers can sometimes feel confusing—especially when suggestions suddenly stop appearing even though data is still being entered correctly. In Microsoft Edge, this behavior is often caused by a feature called the Client Repeatable Feature.

This article explains how Autofill works in Edge, how Frequently Saved Data (FSD) and Parsable Name are used, why Autofill suggestions get blocked, and how this behavior differs from other Chromium-based browsers like Google Chrome.

How Autofill Works in Edge

At a basic level, Microsoft Edge stores and reuses form data based on the name of a form field. More precisely, it uses a value called the Parsable Name.

If two input fields share the same Parsable Name, Edge assumes they represent the same type of data and will show the same Autofill suggestions for both fields.

For example, if a field called EmailAddress exists in two different forms, Edge will show the same Autofill values in both—even if those forms are completely unrelated.

This behavior is part of the Frequently Saved Data (FSD) feature.

Frequently Saved Data (FSD) and Chromium

The Frequently Saved Data (FSD) feature originates from the Chromium project and is used by Microsoft Edge. Because of this, this part of Autofill behavior should be identical to other Chromium-based browsers, such as Google Chrome.

An important detail is that FSD works across domains. It is not limited to a specific website or URL.

This means that a field with the Parsable Name EmailAddress on
www.contoso.com/someform
will show the same Autofill suggestions as a field with the same Parsable Name on
www.microsoft.com/someotherform.

FSD only cares about the Parsable Name, not the website, URL, or form structure.

What Is the Client Repeatable Feature?

The Client Repeatable Feature is a Microsoft Edge–specific feature. It does not originate from the Chromium project. Because of this, its behavior may differ from what you see in Google Chrome or other Chromium-based browsers.

This feature is designed to reduce noisy or repetitive Autofill suggestions. It does this by monitoring how many different values are entered into a field within the same form.

When and Why Autofill Gets Blocked

If five different values are entered consecutively into the same field within the same form, the Client Repeatable Feature becomes active.

When this happens:

Autofill suggestions are blocked
No suggestion popup is shown
New values are still saved internally

The key point is that this blocking is form-specific.

Edge identifies a form using a hash value called Form SignatureV2. The Autofill block applies only to the form with that specific Form SignatureV2.

If another form exists with:

a different Form SignatureV2
but the same Parsable Name

Autofill suggestions will still appear in that other form—until the same five-value rule is triggered there as well.

How to Unblock Autofill Suggestions

Blocking caused by the Client Repeatable Feature is not permanent.

To remove the block, one of the five previously entered values that were stored as Frequently Saved Data (FSD) must be typed again in full.

Partial input is not enough. Typing only part of a previously used value will not lift the block.

Once a complete previously saved value is entered:

Autofill suggestions become visible again
All values that were saved during the blocked phase will also appear

However, unblocking only resets an internal counter. If five new, different values are entered consecutively again, the block will be reactivated.

Clearing Autofill Data via Edge Settings

In addition to unblocking Autofill by re-entering a previously saved value, all Autofill suggestions can also be removed manually via the Edge settings.

Autofill data can be cleared under:

edge://settings/privacy/clearBrowsingData

In the Delete browsing data dialog:

Set Time range to All time
Enable Autofill form data (includes forms and cards)
Click Clear now

This removes all saved Autofill entries, including data affected by the Client Repeatable Feature.

Debugging Autofill Behavior in Edge

Microsoft Edge provides a useful debugging option to better understand Autofill behavior.

By enabling Show Autofill Predictions under
edge://flags
you can inspect Autofill metadata directly.

After enabling the flag, hovering over a form field will display values such as:

Parsable Name
Form SignatureV2

This makes it much easier to understand why Autofill suggestions appear—or why they don’t.

For hands-on testing, Autofill behavior can also be explored on the Autofill Smoke Test page: https://rsolomakhin.github.io/autofill/

Inspecting Autofill Data on Disk (Advanced)

Autofill data in Microsoft Edge is stored locally on disk in a SQLite database file named Web Data.

The file can be found at:

C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\<profilename>\Web Data

Key details:

The file uses SQLite format
It contains Autofill-related tables and metadata
It can be inspected using common SQLite viewers such as DB Browser for SQLite
https://sqlitebrowser.org/dl/

This is useful for advanced debugging scenarios, for example when validating which values are stored internally or confirming that data is still saved even when Autofill suggestions are temporarily blocked.

The Last Used Feature

For completeness, Edge also includes the Last Used Feature. This feature does not affect the blocking behavior described above and is mentioned here for informational purposes only.

Last Used uses information from the entire form—not just the field name—to determine which value was entered most recently. Differences in labels or surrounding text can be enough to distinguish forms.

To do this, the feature also relies on Form SignatureV2.

Final Thoughts

Understanding the difference between Parsable Name, Frequently Saved Data (FSD), and the Client Repeatable Feature helps explain many Autofill behaviors that might otherwise look like bugs.

In short:

FSD is Chromium-based and works across domains
Client Repeatable Feature is Edge-specific and form-scoped
Autofill blocking is temporary and counter-based

Once these concepts are clear, Autofill behavior in Edge becomes far more predictable—and much easier to debug.

Running Text to Image and Text to Video with ComfyUI and Nvidia H100 GPU

HoussemDellai — Fri, 27 Feb 2026 23:35:57 GMT

This guide provides instructions on how to set up and run Text to Image and Text to Video generation using ComfyUI with an Nvidia H100 GPU on Azure VMs.

ComfyUI is a node-based user interface for Stable Diffusion and other AI models. It allows users to create complex workflows for image and video generation using a visual interface. With the power of GPUs, you can significantly speed up the generation process for high-quality images and videos.

Steps to create the infrastructure

Option 1. Using Terraform (Recommended)

In this guide, the provided Terraform template available here: ai-course/550_comfyui_on_vm at main · HoussemDellai/ai-course will create the following:

Create the infrastructure for Ubuntu VM with Nvidia H100 GPU
Install CUDA drivers on the VM
Install ComfyUI on the VM
Download the models for Text to Image (Z-Image-Turbo) and Text to Video generation (Wan 2.2 and LTX-2)

Deploy the Terraform template using the following commands:

# Initialize Terraform terraform init # Review the Terraform plan terraform plan tfplan # Apply the Terraform configuration to create resources terraform apply tfplan

This should take about 15 minutes to create all the resources with the configuration defined in the Terraform files. The following resources will be created:

If you choose to use Terraform, after the deployment is complete, you can access the ComfyUI portal using the output link shown in the Terraform output. It should look like this http://<VM_IP_ADDRESS>:8188. And that should be the end of the setup. You can then proceed to use ComfyUI for Text to Image and Text to Video generation as described in the later sections.

Option 2. Manual Setup

0. Create a Virtual Machine with Nvidia H100 GPU

Create an Azure virtual machine with Nvidia H100 GPUs like sku: Standard NC40ads H100 v5. Choose a Linux distribution of your choice like Ubuntu Pro 24.04 LTS.

1. Install Nvidia GPU and CUDA Drivers

SSH into the Ubuntu VM and install the CUDA drivers by following the official Microsoft documentation: Install CUDA drivers on N-series VMs.

# 1. Install ubuntu-drivers utility: sudo apt-get update sudo apt-get install ubuntu-drivers-common -y # 2. Install the latest NVIDIA drivers: sudo ubuntu-drivers install # 3. Download and install the CUDA toolkit from NVIDIA: wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt-get update sudo apt-get -y install cuda-toolkit-13-1 # 4. Reboot the system to apply changes sudo reboot

The machine will now reboot. After rebooting, you can verify the installation of the NVIDIA drivers and CUDA toolkit.

# 5. Verify that the GPU is correctly recognized (after reboot): nvidia-smi # 6. We recommend that you periodically update NVIDIA drivers after deployment. sudo apt-get update sudo apt-get full-upgrade -y

2. Install ComfyUI on Ubuntu

Follow the instructions from the ComfyUI Wiki to install ComfyUI on your Ubuntu VM using Comfy CLI: Install ComfyUI using Comfy CLI.

# Step 1: System Environment Preparation # ComfyUI requires Python 3.12 or higher (Python 3.13 is recommended). Check your Python version: python3 --version # If Python is not installed or the version is too low, install it following these steps: sudo apt-get update sudo apt-get install python3 python3-pip python3-venv -y # Create Virtual Environment # Using a virtual environment can avoid package conflict issues python3 -m venv comfy-env # Activate the virtual environment source comfy-env/bin/activate # Note: You need to activate the virtual environment each time before using ComfyUI. To exit the virtual environment, use the deactivate command. # Step 2: Install Comfy CLI # Install comfy-cli in the activated virtual environment: pip install comfy-cli # Step 3: Install ComfyUI using Comfy CLI with NVIDIA GPU Support # use 'yes' to accept all prompts yes | comfy install --nvidia # Step 4: Install GPU Support for PyTorch pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130 # Note: Please choose the corresponding PyTorch version based on your CUDA version. Visit the PyTorch website for the latest installation commands. # Step 5. Launch ComfyUI # By default, ComfyUI will run on http://localhost:8188. # and don't forget the double -- comfy launch --background -- --listen 0.0.0.0 --port 8188

Note that you can run ComfyUI with different modes based on your hardware capabilities:

--cpu: Use CPU mode, if you don't have a compatible GPU

--lowvram: Low VRAM mode

--novram: Ultra-low VRAM mode

3. Using ComfyUI for Text to Image

Once ComfyUI is running, you can access the web interface via your browser at http://<VM_IP_ADDRESS>:8188 (replace <VM_IP_ADDRESS> with the actual IP address of your VM).

Note that you should ensure that the VM's network security group (NSG) allows inbound traffic on port 8188.

You can create Text to Image generation workflows using the templates available in ComfyUI.

Go to Workflows and select a Text to Image template to get started. Choose Z-Image-Turbo Text to Image as an example.

After that, ComfyUI will detect that there are some missing models to download.

You will need to download each model into its corresponding folder. For example, the Stable Diffusion model should be placed in the models/Stable-diffusion folder. The models download links and their corresponding folders are shown in the ComfyUI interface. Let's download the required models for Z-Image-Turbo.

cd comfy/ComfyUI/ wget -P models/text_encoders/ https://huggingface.co/Comfy-Org/z_image_turbo/resolve/main/split_files/text_encoders/qwen_3_4b.safetensors wget -P models/vae/ https://huggingface.co/Comfy-Org/z_image_turbo/resolve/main/split_files/vae/ae.safetensors wget -P models/diffusion_models/ https://huggingface.co/Comfy-Org/z_image_turbo/resolve/main/split_files/diffusion_models/z_image_turbo_bf16.safetensors wget -P models/loras/ https://huggingface.co/tarn59/pixel_art_style_lora_z_image_turbo/resolve/main/pixel_art_style_z_image_turbo.safetensors

Note that here you can either use comfy model download command or wget to download the models into their corresponding folders.

Once the models are downloaded, you can run the Text to Image workflow in ComfyUI. You can also change the parameters as needed like the prompt.

When ready, click the Run blue button at the top right to start generating the image. It will take some time depending on the size of the image and the complexity of the prompt. Then you should see the generated image in the output node.

5. Using ComfyUI for Text to Video

To use ComfyUI for Text to Video generation, you can select a Text to Video template from the Workflows section. Choose Wan 2.2 Text to Video as an example. Then you will need to install the required models.

wget -P models/text_encoders/ https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/resolve/main/split_files/text_encoders/umt5_xxl_fp8_e4m3fn_scaled.safetensors wget -P models/vae/ https://huggingface.co/Comfy-Org/Wan_2.2_ComfyUI_Repackaged/resolve/main/split_files/vae/wan_2.1_vae.safetensors wget -P models/diffusion_models/ https://huggingface.co/Comfy-Org/Wan_2.2_ComfyUI_Repackaged/resolve/main/split_files/diffusion_models/wan2.2_t2v_low_noise_14B_fp8_scaled.safetensors wget -P models/diffusion_models/ https://huggingface.co/Comfy-Org/Wan_2.2_ComfyUI_Repackaged/resolve/main/split_files/diffusion_models/wan2.2_t2v_high_noise_14B_fp8_scaled.safetensors wget -P models/loras/ https://huggingface.co/Comfy-Org/Wan_2.2_ComfyUI_Repackaged/resolve/main/split_files/loras/wan2.2_t2v_lightx2v_4steps_lora_v1.1_high_noise.safetensors wget -P models/loras/ https://huggingface.co/Comfy-Org/Wan_2.2_ComfyUI_Repackaged/resolve/main/split_files/loras/wan2.2_t2v_lightx2v_4steps_lora_v1.1_low_noise.safetensors

Models for LTX-2 Text to Video can be downloaded similarly.

wget -P models/checkpoints/ https://huggingface.co/Lightricks/LTX-2/resolve/main/ltx-2-19b-dev-fp8.safetensors wget -P models/text_encoders/ https://huggingface.co/Comfy-Org/ltx-2/resolve/main/split_files/text_encoders/gemma_3_12B_it_fp4_mixed.safetensors wget -P models/latent_upscale_models/ https://huggingface.co/Lightricks/LTX-2/resolve/main/ltx-2-spatial-upscaler-x2-1.0.safetensors wget -P models/loras/ https://huggingface.co/Lightricks/LTX-2/resolve/main/ltx-2-19b-distilled-lora-384.safetensors wget -P models/loras/ https://huggingface.co/Lightricks/LTX-2-19b-LoRA-Camera-Control-Dolly-Left/resolve/main/ltx-2-19b-lora-camera-control-dolly-left.safetensors

Models for Qwen Image 2512 Text to Image can be downloaded similarly.

wget -P models/text_encoders/ https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/resolve/main/split_files/text_encoders/qwen_2.5_vl_7b_fp8_scaled.safetensors wget -P models/vae/ https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/resolve/main/split_files/vae/qwen_image_vae.safetensors wget -P models/diffusion_models/ https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/resolve/main/split_files/diffusion_models/qwen_image_2512_fp8_e4m3fn.safetensors wget -P models/loras/ https://huggingface.co/lightx2v/Qwen-Image-Lightning/resolve/main/Qwen-Image-Lightning-4steps-V1.0.safetensors

Models for Flux2 Klein Text to Image 9B can be downloaded similarly.

wget -P models/text_encoders/ https://huggingface.co/Comfy-Org/flux2-klein-9B/resolve/main/split_files/text_encoders/qwen_3_8b_fp8mixed.safetensors wget -P models/vae/ https://huggingface.co/Comfy-Org/flux2-dev/resolve/main/split_files/vae/flux2-vae.safetensors wget -P models/diffusion_models/ https://huggingface.co/black-forest-labs/FLUX.2-klein-base-9b-fp8/resolve/main/flux-2-klein-base-9b-fp8.safetensors wget -P models/diffusion_models/ https://huggingface.co/black-forest-labs/FLUX.2-klein-9b-fp8/resolve/main/flux-2-klein-9b-fp8.safetensors

Important notes

Secure Boot is not supported using Windows or Linux extensions. For more information on manually installing GPU drivers with Secure Boot enabled, see Azure N-series GPU driver setup for Linux. Src: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/hpccompute-gpu-linux

Sources

- Install CUDA drivers on N-series VMs: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/n-series-driver-setup#install-cuda-drivers-on-n-series-vms

- Install ComfyUI using Comfy CLI: https://comfyui-wiki.com/en/install/install-comfyui/install-comfyui-on-linux

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Managed Identity on SQL Server On-Prem: The End of Stored Secrets

RyadB — Mon, 23 Feb 2026 12:49:56 GMT

The Problem with Credentials in SQL Server

For an On-Premises SQL Server to access Azure services, you traditionally need to store secrets:

Common Scenarios Requiring Credentials

Scenario	Required Credential
Backup to URL (Azure Blob)	Storage account key or SAS token
Extensible Key Management (Azure Key Vault)	Service principal + secret
Calling Azure OpenAI from T-SQL	API key
PolyBase to Azure Data Lake	Service principal or key

Associated Risks

Manual Rotation

Secrets expire. You need to plan and execute rotation and not forget to update all references.

Secure Storage

Where to store these secrets? In SQL Server via CREATE CREDENTIAL? In a config file? Each option has its risks.

Attack Surface

A compromised secret gives access to associated Azure resources. The more secrets you have, the larger the attack surface.

Complex Auditing

Who has access to these secrets? When were they used? Tracking is difficult.

The Solution: Azure Arc + Managed Identity

SQL Server 2025 connected to Azure Arc can geta Managed Identity :

This identity:

Is managed by Microsoft Entra ID
Has no secret to store or rotate
Can receive RBAC permissions on Azure resources
Is centrally audited in Entra ID

How It Works

SQL Server 2025 On-Prem
- Azure Arc Agent installed on the server
  - Managed Identity (automatically created in Entra ID)
    - RBAC assignment on Azure resources
      - -free access to Blob Storage, Key Vault, etc

Step-by-Step Configuration

Step 1: Enable Azure Arc on the Server and/or Register SQL Server in Azure Arc

Follow the procedure describes in this article to onboard your server in Azure Arc.

Connect Your SQL Server to Azure Arc

Remember that you can also evaluate Azure Arc on a Azure VM (test use only)
How to evaluate Azure Arc-enabled servers with an Azure virtual machine

Step 2: Retrieve the Managed Identity

The Managed Identity can be enabled and retrieved from Azure Arc | SQL Servers > “SQL Server instance” > Settings > Microsoft Entra ID

Note: The Managed Identity is server-wide (not at the instance level)

Step 3: Assign RBAC Roles

Granting access to a Storage Account for backups

$sqlServerId = (az resource show --resource-group "MyRG" --name "ServerName" --resource-type "Microsoft.HybridCompute/machines" --query identity.principalId -o tsv) az role assignment create --role "Storage Blob Data Contributor" ` --assignee-object-id $sqlServerId ` --scope "/subscriptions/xxx/resourceGroups/MyRG/providers/Microsoft.Storage/storageAccounts/mybackupaccount"

Ex:

Backup to URL Without Credential

Before (with SAS token)

-- Create a credential with a SAS token (expires, must be rotated) CREATE CREDENTIAL [https://mybackup.blob.core.windows.net/backups] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'sv=2022-11-02&ss=b&srt=sco&sp=rwdlacup...' BACKUP DATABASE [MyDB] TO URL = 'https://mybackup.blob.core.windows.net/backups/MyDB.bak' WITH COMPRESSION

After (with Managed Identity

--No secret anymore CREATE CREDENTIAL [https://mybackup.blob.core.windows.net/backups] WITH IDENTITY = 'Managed Identity' BACKUP DATABASE [MyDB] TO URL = 'https://mybackup.blob.core.windows.net/backups/MyDB.bak' WITH COMPRESSION

Extensible Key Management with Key Vault

EKM Configuration with Managed Identity

CREATE CREDENTIAL [MyAKV.vault.azure.net] WITH IDENTITY = 'Managed Identity' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;

How Copilot Can Help

Infrastructure Configuration

Walk me through setting up Azure Arc for SQL Server 2025 to use Managed Identity for backups to Azure Blob Storage @mssql Generate the PowerShell commands to register my SQL Server with Azure Arc and configure RBAC for Key Vault access

Identify Existing Credentials to Migrate

List all credentials in my SQL Server that use SHARED ACCESS SIGNATURE or contain secrets, so I can plan migration to Managed Identity

Migration Scripts

I have backup jobs using SAS token credentials. Generate a migration script to convert them to use Managed Identity

Troubleshooting

My backup WITH MANAGED_IDENTITY fails with "Authorization failed". What are the steps to diagnose RBAC permission issues? @mssql The Azure Arc agent shows "Disconnected" status. How do I troubleshoot connectivity and re-register the server?

Audit and Compliance

Generate a report showing all Azure resources my SQL Server's Managed Identity has access to, with their RBAC role assignments

Prerequisites and Limitations

Prerequisites

Azure Arc agent installed and connected SQL Server 2025, running on Windows

Azure Extension for SQL Server.

Current Limitations

Failover cluster instances isn't supported.
Disabling not recommended
Only system-assigned managed identities are supported
FIDO2 method not currently supported
Azure public cloud access required

Documentation

Windows Hello for Business - Registered Methods and Last-used Method

MichaelHildebrand — Thu, 19 Feb 2026 12:00:02 GMT

Hi folks – Mike Hildebrand here! Today, I bring you a short post about gaining more awareness of Windows Hello for Business (WHFB) configuration information from across your fleet of Windows PCs.

Over time, we’ve improved the built-in "Authentication Methods" reporting in the Entra portal. As far as WHFB goes, at this point, the Entra Portal provides high-level counts of WHFB registration and usage:

However, we IT Pros are a curious bunch, always looking for more information and more detail about what’s going on in our enterprise.

A while back, after being asked by numerous customers for a way to get more details about their WHFB deployment, I published a post about using Entra sign-in log data and a custom Log Analytics Workbook to obtain that information.

That post/report has proven helpful - from Entra sign in logs, we can determine who is using WHFB, from which device (and there’s even a map to show where in the world it’s happening).

Nice.

But that's only the 'cloud-side' of the situation - there are almost always two follow up questions that can only be answered from the endpoint:

What WHFB methods has a user registered on the endpoint(s)? PIN only? PIN + fingerprint? Face?
Which WHFB method was last used by a given user on a given endpoint?

Ask, and yee shall receive

Here are two easy/quick Intune Proactive Remediation detection scripts you can use that send configurations to a Windows endpoint and retrieve the local device details (via reg-values) around WH4B enrollment methods and the last-used WHFB method.

NOTE: In my 12 days of Christmas blog-a-thon, I posted about creative uses of Intune Proactive Remediations.
Once again, thanks to Marius Wyss and his core scripts to collect the WHFB registration and 'last used' info from local endpoints. They’re the real magic here.

!! CAUTION !!

There is PowerShell code involved here.
Due diligence is required on your part.
Raise your right hand and read this out loud: “Like everything else, I will thoroughly test this and all code/changes that I work with before I deploy to production. I will document the before-change state to ensure I can revert any changes I make.”

CODE DISCLAIMER – These sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

REMINDER/NOTE - When using your scripting editing tool of choice, always be aware of any additional spaces or odd quotation marks or other issues that may result from edit/copy/paste.

“Enrollment Types” Detection

The ‘Enrolled Methods’ script from Marius

o Intune-Remediation-Scripts/WH4B/Enrolled Methods at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub

o My Remediation Script Settings:

o My results:

“As of 2/2/2026 at 9:40 AM, Adele registered a PIN (default/required) - a face - and a fingerprint - for WH4B on the SURFACEPRO5 device”

“Last Used Method” Detection

The ‘Last Used Method’ script from Marius

o Intune-Remediation-Scripts/WH4B/Last Used Method at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub

o My Remediation Settings:

o My results:

“As of 2/2/2026 at 9:40 AM, Adele last used a face/camera for WHFB on the SURFACEPRO5 device”

Additional Examples of Results

Enrollment Types Registered

o NOTE: Remember, a PIN is required, so where you see ‘Fingerprint configured’ in the output, it means ‘PIN + Fingerprint’

Last-used method

There you have it folks - by combing these two Detection Scripts with the Log Analytics Workbook mentioned at the start of the post, you have a solid solution for ‘end to end’ WH4B reporting.

Hilde

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

TysonPaul — Thu, 12 Feb 2026 14:54:34 GMT

Member: TysonPaul | Microsoft Community Hub

From classroom to workforce: Helping higher ed faculty prepare students for what’s next

Team Blog: Microsoft Learn

Author: RWortmanMorris

Published: 01/15/2026

Summary: Microsoft is partnering with higher education institutions to prepare students and faculty for an AI-driven workforce. Through tools like AI Skills Navigator, Microsoft Learn for Educators, and the Microsoft Student Ambassadors program, they offer free, flexible training, credentials, and community support to develop practical AI and digital skills. These initiatives help faculty integrate AI into teaching, empower students with job-ready skills, and provide recognized certifications valued by employers. Microsoft also provides free access to Microsoft 365 and LinkedIn Premium, aiming to support lifelong learning, teaching innovation, and successful career pathways in the evolving educational landscape.

Azure Arc Portal Update: Simplifying Onboarding and Management at Scale

Team Blog: Azure Migration and Modernization

Author: MarcoB

Published: 01/16/2026

Summary: The updated Azure Arc portal streamlines onboarding and management of hybrid and multi-cloud resources. Key improvements include a redesigned landing page, guided onboarding via interactive questionnaires, and unified machine onboarding flows for greater simplicity. Navigation is reorganized for better clarity, and dashboards now offer adaptive summaries and actionable insights, transforming management tasks into intuitive actions. These enhancements aim to make Azure Arc more accessible and scalable, enabling users to efficiently manage external resources and focus on delivering business value instead of dealing with complexity.

Resolve-DnsName vs. nslookup in Windows

Team Blog: Networking

Author: JamesKehr

Published: 01/08/2026

Summary: The article compares nslookup and Resolve-DnsName for DNS troubleshooting in Windows. Nslookup is widely used but operates independently of Windows DNS client resolver, potentially causing inaccurate results due to quirks like DNS suffix handling and lack of support for modern DNS features. Resolve-DnsName, a PowerShell cmdlet, integrates with Windows DNS-CR, providing accurate results, support for DNSSEC, secure DNS, and flexible parameters. For Windows-centric troubleshooting and automation, Resolve-DnsName is recommended, while nslookup remains useful for basic queries and diagnosing DNS client issues. Understanding their differences ensures reliable DNS troubleshooting.

Data Center Quantized Congestion Notification: Scaling congestion control for RoCE RDMA in Azure

Team Blog: Azure Networking

Author: VamsiVadlamuri

Published: 01/13/2026

Summary: Microsoft Azure uses Data Center Quantized Congestion Notification (DCQCN) to enable high-throughput, low-latency RDMA-based storage across its global data centers. DCQCN, combined with Priority Flow Control, dynamically manages congestion using ECN-based feedback, ensuring reliable performance even with diverse hardware and network conditions. Azure addressed interoperability challenges between NIC generations by tuning DCQCN parameters and optimizing feedback mechanisms. As a result, Azure achieves line-rate RDMA performance, significant CPU savings, reduced latency, and near-zero packet loss, making DCQCN essential for scalable and resilient cloud storage infrastructure.

What is going on with RC4 in Kerberos?

Team Blog: Ask the Directory Services Team

Author: WillAftring

Published: 01/26/2026

Summary: Microsoft is phasing out RC4 usage in Kerberos authentication due to security concerns, with major changes starting in January 2026. RC4 will be removed as a default encryption type, and new auditing tools will help identify dependencies. Enforcement begins April 2026, with rollback options until July 2026. While DES is already removed, RC4 remains supported for critical legacy needs if properly configured. Microsoft encourages users to migrate away from RC4 and offers resources and support for environments still dependent on it.

Redis Keys Statistics

Team Blog: Azure PaaS

Author: LuisFilipe

Published: 01/21/2026

Summary: The article explains how to gather Redis key statistics, focusing on Time-to-Live (TTL) and key size, to troubleshoot cache usage and performance. It provides two Bash+LUA script solutions: one for key statistics (counting keys by TTL and size thresholds), and another for listing key names meeting specified TTL and size criteria. The article highlights the importance of managing TTL and key sizes for optimal Redis performance and warns that running these scripts can impact Redis workloads due to their need to scan all keys. Usage instructions, parameters, and performance considerations are detailed.

Azure Arc Server Jan 2026 Forum Recap

Team Blog: Azure Arc

Author: Aurnov_Chattopadhyay

Published: 01/20/2026

Summary: The January 2026 Azure Arc Server Forum highlighted new machine management features in Azure Compute Hub, updates on Windows Server Hot Patch and its billing, a preview of TPM-based onboarding to Azure Arc, and a recap of major 2025 SQL Server announcements. Attendees are encouraged to stay updated with the latest Arc agent, provide feedback, and register for SQL Con 2026. The session’s recording is available on YouTube, and registration for future forums and newsletters is open, with the next session scheduled for February 19, 2026.

Azure File Sync: Azure Arc Integration, Additional Regions, and Secure Syncing

Team Blog: Azure Storage

Author: grace_kim

Published: 01/16/2026

Summary: Azure File Sync now integrates with Azure Arc, enabling simplified deployment and management of hybrid file services. The service expands to four new regions—Italy North, New Zealand North, Poland Central, and Spain Central—offering improved regional data residency and performance. Enhanced security is provided through managed identities, eliminating the need for manual credential management. From January 2026, File Sync will incur no per-server cost for Windows Server Software Assurance customers using Azure Arc and File Sync agent v22+. These updates streamline onboarding, ensure secure access, and support scalable, predictable hybrid storage solutions.

Announcing Public Preview of User delegation SAS for Azure Tables, Azure Files, and Azure Queues

Team Blog: Azure Storage

Author: ellievail

Published: 01/16/2026

Summary: Microsoft has announced the public preview of user delegation SAS (UD SAS) for Azure Tables, Azure Files, and Azure Queues in all regions, expanding secure access beyond Azure Blobs. UD SAS ties SAS tokens to user identities via Entra ID and RBAC, enabling more granular, delegated access to storage resources. There’s no additional cost, and it’s available through REST APIs, SDKs, PowerShell, and CLI. Eligible storage accounts can use UD SAS without special settings, and setup involves assigning RBAC roles, obtaining a user delegation key, creating the SAS token, and sharing it securely.

Deploy PostgreSQL on Azure VMs with Azure NetApp Files: Production-Ready Infrastructure as Code

Team Blog: Azure Architecture

Author: GeertVanTeylingen

Published: 01/15/2026

Summary: The article details how deploying PostgreSQL on Azure VMs with Azure NetApp Files is simplified using production-ready Infrastructure as Code (IaC) templates. These templates automate setup, optimize storage performance, and enhance security, eliminating manual configuration and reducing deployment time from hours to minutes. Teams can use Terraform, ARM templates, or PowerShell for flexible, repeatable workflows across development and production environments. Key benefits include consistent environments, enterprise-grade features, rapid provisioning, cost efficiency, and support for AI/ML workloads and database migrations. The solution ensures scalable, secure, and high-performance PostgreSQL deployments on Azure.

Unlocking Advanced Data Analytics & AI with Azure NetApp Files object REST API

Team Blog: Azure Architecture

Author: GeertVanTeylingen

Published: 01/15/2026

Summary: The article details how the Azure NetApp Files object REST API enables S3-compatible object access to enterprise file data stored on Azure NetApp Files, eliminating the need for data copying or restructuring. This dual-access approach allows analytics and AI platforms, including Azure Databricks and Microsoft OneLake, to operate directly on NFS/SMB datasets, preserving performance, security, and governance. Integration scenarios, technical implementation, and video guides are provided to help organizations streamline data architectures, minimize data movement, and accelerate real-time insights across analytics and AI workflows.

Release of Bicep Azure Verified Modules for Platform Landing Zone

Team Blog: Azure Tools

Author: ztrocinski

Published: 01/20/2026

Summary: **Summary:** Microsoft has released Azure Verified Modules (AVM) for Platform Landing Zones using Bicep, providing a modular, customizable, and officially supported approach to Infrastructure as Code (IaC). The framework features 19 independently managed modules, supports full configuration, and integrates Azure Deployment Stacks for improved resource lifecycle management. Bicep AVM replaces classic ALZ-Bicep, which will be deprecated by 2027. Key benefits include end-to-end customization, faster innovation, independent policy management, and modernized parameter files, making Azure deployments more flexible, maintainable, and aligned with enterprise best practices. Migration guidance will be provided for existing users.

Improving Efficiency through Adaptive CPU Uncore Power Management

Team Blog: Azure Compute

Author: PulkitMisra

Published: 01/21/2026

Summary: The article discusses Microsoft Azure’s adoption of adaptive CPU uncore power management, focusing on Efficiency Latency Control (ELC) co-designed with Intel for Xeon 6 processors. ELC enables dynamic adjustment of uncore frequency based on CPU utilization, improving power efficiency without sacrificing performance. Real-world tests show up to 11% power savings at moderate loads and 1.5× performance-per-watt improvements at low loads. This approach allows Azure to deploy more servers within existing datacenter power constraints, enhancing sustainability and responsiveness to evolving cloud workload demands through hardware–software co-design.

Announcing General Availability of Azure Da/Ea/Fasv7-series VMs based on AMD ‘Turin’ processors

Team Blog: Azure Compute

Author: ArpitaChatterjee

Published: 01/27/2026

Summary: Microsoft has announced the general availability of Azure’s new AMD-based Da/Ea/Fasv7-series Virtual Machines powered by 5th Gen AMD EPYC ‘Turin’ processors. These VMs offer improved CPU performance, scalability, memory capacity, network, and storage throughput, with up to 35% better price-performance than previous AMD v6 VMs. They cater to diverse workloads, including general, memory, and compute-intensive tasks, and feature enhanced security and flexible configurations. Available across multiple Azure regions, these VMs deliver significant workload-specific gains and are praised by customers and technology partners for performance and efficiency improvements.

Determine Defender for Endpoint offboarding state for Linux devices

Team Blog: Core Infrastructure and Security

Author: edgarus71

Published: 01/21/2026

Summary: The article describes a method for quickly determining the Microsoft Defender for Endpoint onboarding or offboarding state on Linux devices. Since the Defender portal can take up to 7 days to update offboarding status, a provided Bash script checks key indicators such as the onboarding file, Defender package installation, and service status. The script outputs whether the device is "ONBOARDED" or "OFFBOARDED," streamlining endpoint management and troubleshooting. It can be deployed at scale via Linux management tools and also run remotely from the Live Response console for onboarded devices.

Conditional Access for Agent Identities in Microsoft Entra

Team Blog: Core Infrastructure and Security

Author: Farooque

Published: 01/27/2026

Summary: Microsoft Entra introduces Agent Identities for AI systems and extends Conditional Access to them, but with limited controls compared to human users. Currently, Conditional Access only allows blocking agent identities and assessing agent risk during token acquisition, without supporting MFA, device compliance, or session controls. This is due to agents’ machine-driven authentication methods. Despite limitations, Conditional Access helps prevent compromised agents, enforce separation of duties, and manage AI sprawl. Agent Blueprints are not governed by Conditional Access. Future enhancements are expected, but for now, CA remains a minimal, identity-focused security layer for AI agents.

Announcing Azure CycleCloud Workspace for Slurm: Version 2025.12.01 Release

Team Blog: Azure High Performance Computing (HPC)

Author: xpillons

Published: 01/07/2026

Summary: The 2025.12.01 release of Azure CycleCloud Workspace for Slurm introduces integrated Prometheus monitoring with managed Grafana dashboards, Entra ID Single Sign-On for secure authentication, support for ARM64 compute nodes, and compatibility with Ubuntu 24.04 and AlmaLinux 9. These enhancements streamline HPC cluster management, improve security, and offer real-time performance insights, empowering technical teams to build scalable and efficient environments. The update simplifies monitoring setup and user access, reinforcing Azure’s commitment to flexible, secure, and innovative HPC solutions for scientific and technical communities.

Scaling physics-based digital twins: Neural Concept on Azure delivers a New Record in Industrial AI

Team Blog: Azure High Performance Computing (HPC)

Author: lmiroslaw

Published: 01/12/2026

Summary: Neural Concept, leveraging Azure HPC infrastructure, achieved record-breaking accuracy and efficiency in automotive aerodynamic predictions using MIT’s DrivAerNet++ dataset. Their geometry-native Geometric Regressor outperformed all previous methods in predicting surface pressure, wall shear stress, velocity fields, and drag coefficients. The workflow transformed 39TB of CFD data into a production-ready model within a week, enabling real-time predictions and significantly shortening design cycles. Customers have realized up to 30% faster development and $20M savings per 100,000 vehicles. This demonstrates the industrial impact of scalable, AI-driven engineering workflows in automotive design.

Intune my Macs: Accelerating macOS proof of concepts with Microsoft Intune

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 01/22/2026

Summary: Intune my Macs is an open-source starter kit from Microsoft that streamlines macOS management proof of concepts using Intune. It deploys over 31 recommended enterprise configurations—including security, compliance, identity, and applications—via a single PowerShell script, operating in dry-run mode by default. The project helps organizations quickly evaluate and implement Intune for macOS, offers practical configuration examples, reduces setup time to minutes, and includes documentation and analysis tools. It’s ideal for learning, testing, and customizing Intune policies for macOS environments, saving significant time and effort.

Silicon to Systems: How Microsoft Engineers AI Infrastructure from the Ground Up

Team Blog: Azure Infrastructure

Author: Alistair_Speirs

Published: 01/27/2026

Summary: The article details how Microsoft engineers its AI infrastructure by designing custom silicon, servers, accelerators, and data centers as an integrated system optimized for performance, power efficiency, and cost. Highlighting custom chips like Cobalt 200 and the Maia AI Accelerator platform, Microsoft emphasizes purpose-built hardware, advanced cooling solutions, and end-to-end system integration. This approach ensures reliable, efficient AI workloads at global scale, powering services like Copilot and Teams. The engineering process involves close coordination between hardware and software development, from silicon design to datacenter deployment, prioritizing power and thermal management throughout.

Deep dive into the Maia 200 architecture

Team Blog: Azure Infrastructure

Author: sdighe

Published: 01/26/2026

Summary: Maia 200 is Microsoft’s first custom AI inference accelerator, designed for efficiency and scalability in Azure. It features advanced silicon, memory hierarchy, and data movement architecture, delivering 30% better performance per dollar than previous hardware. Optimized for narrow precision arithmetic and large language models, Maia 200 supports high-throughput, low-latency inference, and integrates seamlessly with Azure’s cloud infrastructure and developer tools. Its innovative interconnect and software stack enable reliable, scalable multi-tenant AI deployments, powering workloads like GPT-5.2 in Microsoft Foundry and 365 Copilot. Maia 200 sets a new standard for cloud-native, cost-effective AI inference.

Implementing Azure Lighthouse: A Technical Guide for Service Providers and Enterprises

Preston_Romney — Thu, 19 Feb 2026 18:30:46 GMT

Managing resources across multiple tenants is a common challenge for managed service providers (MSPs) and large enterprises. There are many scenarios where you may need to manage resources in many tenants, whether those tenants belong to your organization or they belong to your customers. Without a unified approach, administrators must create accounts in each customer tenant or rely on guest identities, which increases credential sprawl and makes it hard to enforce consistent governance. This also doesn’t scale, as an administrator who needs to manage many customers would need to separately login to each customer tenant in order to view and work on subscription resources across tenants. This is cumbersome and time consuming. Without a delegated access model such as Azure Lighthouse, this is how most organizations manage resources across tenants. While the focus of this article is Azure Lighthouse, there are other delegated access models available which I will compare further below.

Figure 1: Access subscriptions across Entra tenants using guest login.

Microsoft’s Azure Lighthouse addresses the challenge of managing resources across tenants at scale by allowing service providers and customers to delegate access to specific scopes in the customer’s tenant. Users sign in to their own tenant and manage delegated resources across all customers through a logical projection model. These subscriptions appear as if they are in the service providers’ tenant and they no longer have to login to each separate tenant. This article introduces the core architecture and operational model of Azure Lighthouse and provides guidance for implementers along with lesser-known tips to help you succeed.

Figure 2: Access subscriptions across Entra tenants using Azure Lighthouse, with your member login account in the Service Provider tenant.

For clarity and simplicity, this article uses variations of two consistent terms. The Service Provider refers to the managing entity, or the tenant that contains the identities used to manage resources in another tenant. The Customer refers to the entity whose resources are being managed. Accordingly, the tenant hosting those managed resources is referred to as the Customer Tenant, while the tenant hosting the managing identities is the Service Provider Tenant.

Understanding Azure Lighthouse

Azure Lighthouse isn’t a separate management portal, it’s a set of delegated resource management capabilities that operate through Azure Resource Manager (ARM) and the Azure portal. When a customer delegates a subscription or resource group, two resources are created in the customer tenant:

Registration definition – describes the managing tenant, the built-in role assignments (principal IDs + roles) and metadata for the managed service offer. One definition exists per subscription.
Registration assignment – binds the registration definition to a specific scope (subscription or resource group).

Azure Resource Manager verifies the presence of these two resources when a user in the service provider’s tenant performs an operation on customer resources. The customer’s resources are logically projected into the managing tenant, so users can stay signed in to their own tenant and still manage delegated resources without switching directories. All activity performed by managing-tenant users is logged in the customer’s activity log, enabling accountability.

Onboarding Customers to Azure Lighthouse Methods

There are two supported onboarding methods:

ARM template deployment – The service provider creates a JSON template specifying the managedByTenantId (the provider’s tenant), an authorizations array containing principal IDs and built-in role IDs, and optional metadata (offer name/description). The provider then delivers the template to the customer, who deploys it into their subscription or resource group. You must know the customer’s tenant ID and subscription ID (or resource group names) and the provider’s tenant ID. Each authorization requires the principal ID (user, group or service principal) and the built-in role definition ID.
Managed service offer via Azure Marketplace – Partners who meet competency requirements can publish public or private offers in the Azure Marketplace. Customers accept the offer via the Marketplace, which automatically deploys the registration definition and assignment into their tenant. Offers apply identically across all purchasers. To customize roles for specific customers, you must publish separate private offers or use the ARM template method.

Figure 3: Workflow for onboarding Azure Lighthouse using either the Azure Marketplace or an ARM template.

Once deployed, these resources produce a logical projection of the delegated subscriptions/resource groups.

Scope and Role Considerations

Tenant and subscription IDs – When deploying via ARM, you must know the tenant ID of both the service provider and the customer, plus the subscription ID(s) or resource group names you intend to onboard.
Role definitions – Any Azure built-in role except Owner is supported; custom roles and classic administrator roles are not supported. Roles containing DataActions (e.g., storage listKeys) or certain Microsoft.Authorization actions aren’t allowed. Always assign roles that follow the principle of least privilege; for example, use Reader for monitoring tasks, Contributor for VM management or custom roles where data access isn’t needed. Assigning the Managed Services Registration Assignment Delete Role is recommended so that service-provider users can remove their own access later.
Group vs. individual assignments – It’s best practice to assign permissions to Microsoft Entra security groups or service principals rather than individual users. This allows you to add or remove users without redeploying the delegation and simplifies the management of large teams. Ensure the group type is set to Security.
Eligible authorizations (just-in-time) – Azure Lighthouse supports Azure Privileged Identity Management (PIM). You can create eligible authorizations that require users to activate their role for a defined duration (up to eight hours) and optionally require approval or multi-factor authentication. This model reduces the number of permanent privileged assignments.

Working with Delegated Resources

Navigating the Azure Portal

Service providers manage delegated tenants through the My customers blade in the Azure portal. Users must have at least the Reader role to access this view. From My customers, you can:

View all customers that have delegated subscriptions or resource groups to your tenant.
Inspect customer details, offers and delegations; drill down to see which subscriptions or resource groups have been delegated and which roles are assigned.
Review delegation change activity; the activity log lists every delegation and removal (requires Monitoring Reader at root scope).
Remove delegations – If the delegation was created with the Managed Services Registration Assignment Delete Role, your users can revoke their own access via the trash-can icon; otherwise, only the customer can remove the delegation.

Within other Azure services, you can work directly in the context of a delegated subscription. Use the Directories + subscriptions filter to choose delegated subscriptions and resource groups (turn off Advanced filters) and set them as your default scope. The portal will automatically scope your operations (e.g., creating VMs, assigning policies) to the selected delegated subscription.

CLI and API Support

All Azure Resource Manager APIs and management tools (Azure CLI, Azure PowerShell, Terraform, etc.) work with delegated resources. Use Get-AzSubscription in PowerShell or az account list in CLI to list your subscriptions; these commands include homeTenantId and managedByTenantIds fields to differentiate between your own and delegated subscriptions. If you do not see these fields, run az account clear then log in again.

Cross-Tenant Scenarios and Services

Azure Lighthouse enables cross-tenant management across many services as long as the user has the appropriate role. Example scenarios include:

Azure Arc – Onboard servers, Kubernetes clusters and SQL resources outside Azure into delegated subscriptions; enforce consistent policy and use GitOps across customers.
Azure Backup – View and manage backups across delegated subscriptions. Backup center and Backup Explorer provide aggregated views for delegated resources.
Azure Automation / Functions – Use automation accounts or serverless functions in your tenant to run tasks against delegated resources.
Cost Management – CSP partners can view consumption costs (pre-tax, retail rates) for delegated subscriptions.
Key Vault and Kubernetes – Create Key Vaults in customer tenants and manage AKS clusters; monitor container performance across customer tenants.

These services reflect only a subset of supported capabilities; most ARM-based operations will work cross tenant.

Security and Governance Best Practices

Implementing Azure Lighthouse is not just about technology; it requires strong governance:

Require multi-factor authentication (MFA) – Users in your managing tenant should always be subject to Microsoft Entra MFA. Encourage customers to do the same.
Conditional Access Policies: Conditional access policies defined in the customer tenant do not apply to delegated users; only the managing tenant’s policies are enforced. For example, it would be wrong for a customer to assume that if they enforce an MFA conditional access policy, that a delegated user from the service providers tenant would be forced to use MFA when accessing customer resources. MFA would need to be enforced in the service providers tenant to ensure that delegated users would access the customer resources with MFA.
Principle of least privilege – Use Azure RBAC roles with the minimum permissions necessary. Limit the number of users with high privileges and regularly review memberships.
Use groups / service principals – Assign roles to security groups or service principals instead of individuals; this simplifies management when people join or leave your team.
Assign the Registration Assignment Delete role – Always include the built-in Managed Services Registration Assignment Delete Role in your authorizations so that your users can remove their own access without customer intervention.
Understand role limitations – The Owner role isn’t supported; neither are roles with DataActions permissions (e.g., retrieving storage account keys). Roles with specific Microsoft.Authorization actions are also not allowed.
Monitor activity and use logs – The customer’s activity log records all write and action operations performed by delegated users. Encourage customers to review these logs and ensure compliance.
Opt for eligible authorizations – Where practical, use Azure PIM to create eligible authorizations for just-in-time elevation.
Pay attention to subscription transfers – If a delegated subscription is transferred to another Microsoft Entra tenant, the registration definition and assignment remain so long as the subscription hasn’t been delegated to that tenant before. If it has, the delegation resources for that tenant are removed and access via Azure Lighthouse stops.

Comparing Delegation and Packaging Models

Azure Lighthouse, Administer on behalf of (AOBO), and Azure Managed Applications are all Azure delegation models that enable one organization to manage resources owned by another without fully transferring ownership. Each is designed to support scenarios where a service provider, partner, or central IT team needs some level of administrative control over customer or business unit subscriptions. They share a common goal of simplifying operations while maintaining separation between the managing party and the resource owner. However, they differ substantially in how access is granted, how permissions are scoped and enforced, and whether the focus is ongoing environment administration or tightly controlled application management. Understanding these differences is essential for choosing the right model for governance, security, and scale.

Azure Lighthouse is designed for cross-tenant, large-scale management, allowing a service provider or central IT team to manage multiple customer or internal tenants through Azure RBAC-based delegation without adding guest accounts; permissions are explicit, least-privilege, auditable, and can span subscriptions, resource groups, or management groups. AOBO is an older, Commerce-era mechanism primarily tied to CSP subscriptions that allows partners to administer customer subscriptions, but it relies on broad, often implicit permissions and Entra ID guest access, lacks fine-grained RBAC control, and does not scale well for modern governance scenarios. Azure Managed Applications, by contrast, focus on application lifecycle control rather than general administration: they allow a publisher to deploy and manage specific Azure resources on a customer’s behalf while the customer retains ownership, with access restricted to only the managed resource group defined by the application.

Architectural differences

AOBO – The provider logs in as a guest into the customer’s Azure AD tenant and is assigned RBAC roles manually. The provider must switch directories to operate within each customer’s environment.
Azure Lighthouse – Delegated assignments are created at the ARM control plane. No guest accounts are needed; the provider uses its own Microsoft Entra tenant and can see delegated subscriptions under My customers. The customer remains in full control and can remove the delegation at any time.
Azure Managed Applications – The provider packages an entire solution into an ARM template and publishes it privately or publicly via a service catalog or marketplace. When deployed, Azure creates a managed resource group in the customer’s subscription. That resource group is hidden from the customer; only an application resource and configurable parameters are exposed. The provider automatically receives owner access on the managed resource group to operate the solution

Access and control

AOBO – Access is granted via individual RBAC assignments to guest users. Providers juggle multiple customer tenants and must maintain least privilege manually. Customers must remove each role assignment if they want to revoke access to services.
Azure Lighthouse – Access is granted via delegated roles defined in an offer or through portal‑based delegation. Providers work under their own tenant context, and customers can revoke the entire delegation in one action. Operations by the provider are logged in the customer’s activity logs and are subject to the customer’s policies.
Azure Managed Applications – Access is tied to the managed resource group; Management is done in the provider tenant and not the customer tenant. Customers cannot see underlying resources or modify them directly. Providers control the life‑cycle of the solution (deployment, updates, operations). Customers interact with the application through exposed parameters and can remove it by deleting the application resource, which cleans up the managed resource group.

Figure 4: Example of delegation methods.

	AOBO	Azure Lighthouse	Azure Managed Applications
Access model	Guest accounts with manual role assignments in the customer tenant; cross‑tenant administration is done via individual RBAC assignments.	Delegated resource management assignments created at the control plane through ARM; provider uses its own tenant identity.	ARM templates package resources into a managed resource group; provider gets owner access to that group via the Managed Application’s authorization definition.
Scalability	Manual; each tenant must assign roles per provider user; difficult to scale across many customers.	High; one offer can onboard many customers and delegated scopes appear automatically in the provider portal.	Scalable for packaging repeatable solutions; each deployment creates its own managed resource group but does not provide cross‑tenant visibility.
Governance	Hard to enforce least privilege; guest users may accumulate high‑privilege roles and require per‑user, per‑subscription revocation.	Strong governance; customers can remove the entire delegation with one action and providers request only the roles they need.	Provider controls a hidden managed resource group; customers have limited oversight but can delete the application to remove the solution.
Identity management	Providers manage multiple guest accounts and switch Azure AD directories.	Providers remain in their own Azure AD tenant; no guest accounts; context switching is eliminated.	Providers operate via a service principal with owner access on the managed resource group; customers interact via an application resource.
Billing / commerce	None; AOBO is purely an access model with no built‑in billing.	Can be combined with private or Marketplace plans for management services.	Pricing defined in the Marketplace or service catalog; supports usage‑based or flat‑rate charges for the packaged solution.
Purpose	Historical mechanism for delegated admin in partner programs; largely superseded by Lighthouse.	Delegate access to existing resources across tenants for operations such as monitoring, compliance and support.	Deliver packaged solutions to run in the customer’s subscription as a managed service under provider control.
Resource location	Existing resources remain in the customer’s subscription; no separate resource groups created.	Existing resources remain in the customer’s subscription; no new resource groups are created by the delegation.	Resources are deployed into a dedicated managed resource group that is hidden from the customer.
Customer control	The customer holds full control but must revoke individual role assignments; risk of lingering privileges.	The customer retains full visibility and can revoke the entire delegation at any time.	The customer’s control is limited to application parameters; underlying resources are hidden but can be removed by deleting the application.
Provider control	Provider’s access depends on assigned roles; may result in over‑privileged guest users.	Provider’s access is scoped by delegated roles; cannot exceed what is granted by the customer; operations are audited.	Provider has owner access to the managed resource group and manages the entire solution life‑cycle.
Common scenarios	Legacy cross‑tenant administration patterns in partner programs, now considered less secure and hard to scale.	Multi‑tenant monitoring, patching, policy enforcement, security posture management or support services for existing workloads.	Turnkey Marketplace offerings, SaaS extensions, complex enterprise architectures or packaged infrastructure solutions.

Lesser-Known Features and Tips

Partner ID linkage for earned credit – Members of the Microsoft AI Cloud Partner Program can associate their Partner ID with a service principal or user account. This allows Microsoft to identify partners driving Azure success and earn Partner Earned Credit (PEC). The account linked to the Partner ID must have access to every onboarded subscription.
Azure Resource Graph – Use Azure Resource Graph (ARG) to query resources across all delegated subscriptions from a single endpoint. For example, query compliance status of virtual machines across your customer base using Resources | where type =~ 'Microsoft.Compute/virtualMachines' along with tags or policy states. ARG provides aggregated visibility at scale.
Cost management nuances – Cost management via Azure Lighthouse displays pre-tax consumption at retail rates; purchases and discounts are not included. Ensure that your organization is aware of this when providing cost reporting to customers.
Role updates and deprecations – Roles can change over time; if a previously supported role gains DataActions permissions, it becomes ineligible for new delegations, though existing assignments remain. Always review role definitions when updating templates.
Support for ISVs and multiple delegations – Customers can delegate the same subscription or resource group to multiple service providers. This allows independent software vendors (ISVs) to project their own management resources into the customer tenant while other service providers manage operations.

Conclusion

Azure Lighthouse provides a robust and secure framework for multi-tenant management. By logically projecting delegated resources into a managing tenant, service providers and enterprises gain centralized visibility and automation while customers retain control over scopes and roles. Implementing Azure Lighthouse requires careful design of role assignments, adherence to security best practices, and continuous governance. For further reading and template samples, consult the Azure Lighthouse documentation.

CRL & AIA Publishing Guidance (Practical PKI Part 2)

RonArestia — Mon, 09 Feb 2026 05:00:00 GMT

My name is Ron Arestia, and I am a Security Researcher with Microsoft’s Detection and Response Team (DART). We respond to customer cybersecurity incidents to assist with containment and recovery from threat actors. In this blog post, we will be covering CRL and AIA publishing guidance with a focus on the Active Directory Certificate Services (ADCS) offline root Certificate Authority (CA). This is part 2 of a series on practical PKI implementation based around my experience with customer interactions working as a Microsoft engineer.

Feel free to catch up on previous blog posts or jump right into this one:

Secure Configuration and Hardening of Active Directory Certificate Services

Implementing and Managing an ADCS Offline Root Certificate Authority (Part 1)

In Part 2 of our series, we will focus on the certificate revocation list (CRL) and authority information access (AIA) extensions with an example of manual maintenance on an offline root certificate authority (CA).

The Certificate Revocation List
Delta Certificate Revocation Lists
The Authority Information Access Extension
Publishing Considerations

The Certificate Revocation List

The IETF RFC 5280 defines a Certificate Revocation List (CRL) as “a time-stamped list identifying revoked certificates that is signed by a CA or CRL issuer and made freely available in a public repository.” Since there are a number of nuances for both scope and application, this section will cover a standard two-tier public key infrastructure (PKI) where the root CA manages revocation for subordinate certificates, and the issuing CA manages revocation for issued endpoint certificates. It is important to note that CRLs and their repositories can be scoped for specific purposes, but we are focused on PKI basics in this blog and will cover custom implementations at a later time. In this section we will not address the Online Certificate Status Protocol (OCSP). This concept will be covered later.

Everything about your PKI relies on proper maintenance of and access to the CRL. If the CRL is not available due to expiration or an outage of the endpoint hosting it, certificate revocation checking fails which means end users will receive a programmatic error from a web browser or the operating system itself.

For instance, Figure 1 below shows that the CA in my lab is offline.

Figure 1

When I try to start the issuing CA, I receive the error shown in Figure 2.

Figure 2

The CRYPT_E_REVOCATION_OFFLINE error indicates that a revocation lookup failed somewhere in the process of starting the issuing CA. If we open PKIView.msc (Figure 3), we can check the overall health of our PKI to determine what, if anything, is not functioning.

Figure 3

Here you see that the CRL for my root CA expired back in August 2025 (Figure 4). This would cause the issuing CA to not start up properly, supporting the idea that the CRL is important for the functionality of your PKI.

Figure 4

To resolve this issue, we need to go to our offline root CA, generate a new CRL, and publish it to the location specified in the CA extension for proper lookup. My lab root CA is hosted on a Hyper-V server without connectivity to any network (Figure 5).

Figure 5

Notice that there are no network adapters for this Hyper-V VM. I can only access it from the host itself using the local console. Once logged in, note that I can see the root CA did, in fact, issue a CRL (Figure 6) the last time it was online (5 November 2025), but since the root CA is offline, and I did not manually copy the CRL from the machine, it did not update for the PKI globally, which is expected behavior.

Figure 6

To remedy this, I am going to manually publish an updated CRL from the root CA (Figures 7 & 8) and copy it to the issuing CA for publishing.

Figure 7

Figure 8

Once complete, we can view the CRL in the OS to verify the new timestamp (Figure 9)

Figure 9

Finally, we change the local administrator password on the offline root CA and shut it down. Since this is a virtual machine, we can browse on the Hyper-V host to the VM hard drive, mount it, and pull the CRL off of the disk (Figure 10).

Figure 10

Note: as per our last blog post, this is not considered secure since anyone with access to the file system of the Hyper-V host, including a threat actor, could perform the exact same action but with the root CA private key, effectively compromising your entire PKI. For the purposes of this blog series and in a non-production lab environment, this practice is overriding security in lieu of convenience. If, however, you have a proper Tier 0 virtualization host and are using an HSM, this could be functional for a production environment with adherence to cybersecurity best practices.

Now we can drop the CRL on the issuing CA and copy it over to the web publishing endpoint (Figure 11).

Figure 11

This resolves the broken revocation check during startup of the issuing CA and brings the PKI back into the green in PKIView.msc (Figure 12).

Figure 12

In this section, we showed one of the common issues arising from an expired CRL and illustrated the importance of maintaining a healthy CRL publishing environment. We also walked through how to resolve this issue by issuing and publishing a new CRL from the root CA.

Delta Certificate Revocation Lists

IETF RFC 5280 defines a delta certificate revocation list as a CRL that “only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete [base] CRL.” Delta CRLs are supplemental to the base CRL and allow for a “fresher” certificate revocation list without having to re-publish the base CRL every time a certificate is revoked. Delta CRLs can also help to reduce revocation lookup delays in an environment with particularly large base CRLs, but delta CRLs are functionally rolled up into the base CRL at the next base CRL publishing interval, so they do not provide any advantage over base CRLs with regards to overall size long term. Delta CRLs are especially useful in high-revocation environments where revocation needs to be respected quickly, as they are published at a more rapid interval than the base CRL. It is important to note, however, that delta CRL publishing intervals are not instantaneous, so a priority revocation such as for a compromised certificate would still require manually re-publishing either the base or delta CRL.

It is critical to understand that delta CRLs are accepted and functional for Windows, but delta CRLs may not be respected by non-Windows systems. Some enterprise distributions of Linux do accept delta CRLs, but you may need to work with your distribution vendor to allow them otherwise. In the case of a CRL lookup by a system without delta CRL support, any certificates in the delta CRL would be overlooked during a CRL lookup in lieu of using the base CRL.

By default, delta CRLs are configured for use in ADCS. When guiding customers, I make the case that unless they anticipate a high revocation load, using delta CRLs is unnecessary. Additionally, if the customer is leveraging non-Windows systems in their environment, I urge caution around delta CRLs to prevent a false sense of security around revocation. There is nothing inherently wrong with using delta CRLs out of the box but understanding their main purpose (faster revocation publishing out-of-band from the base CRL publishing) is important to drive outcomes.

Delta CRLs have a place and are an accepted extension in PKI discussions, but deciding in advance if you will truly leverage their utility goes a long way to reduce administrative overhead of the PKI long term. If you do not anticipate doing regular revocation, they are an additional administrative touchpoint that will not serve your immediate or long-term needs. If, however, you are concerned about rapid response for revocation or having to manually issue out-of-band CRLs, then delta CRLs can help.

The Authority Information Access Extension

IETF RFC 3280 defines the Authority Information Access (AIA) extension as “how to access CA information and services for the issuer of the certificate in which the extension appears.” This is an extension, similar to the CRL, that is not critical but recommended for the functionality of your PKI. This location, stamped on every certificate issued by a CA, is used to help end entities construct a valid certificate chain in the event there are any missing or outdated certificates. Without this extension, all certificates in an end entity chain would need to be trusted in advance by the system using the certificate.

The publishing of the AIA location is separate from the CRL, but most PKI implementations use the same publishing endpoint for both. However, it is not necessary to publish to the same location. The AIA location will contain a copy of the public certificate for the root, policy, and issuing CAs in a PKI. You should never publish private keys to this location. The certificates are necessarily accessible by any system. The private key is exactly that: private. It should only exist on the CA itself or, preferably, on an HSM.

The AIA publishing location is part of the CA extension configuration on every ADCS CA (Figure 13) and can also be added to the Online Certificate Status Protocol (OCSP) extension, if desired.

Figure 13

Note the limited options for this configuration. This is by design. You are simply providing a web-based (or LDAP) endpoint to which an endpoint can refer to download additional certificates to build a trust chain. Publishing certificates to this endpoint is usually a manual process since CA certificate updates are a less frequent operation. It is possible to automate this using something like DFS-R or a scripted process, but that also increases your risk footprint.

It is also important to note that the certificate file name in the publishing location must match exactly the name input into the extension. Any characters, including spaces, beyond what it explicitly declared in the extension will cause the AIA lookup to fail.

A lack of a proper certificate in the AIA location will not generally cause a problem unless an endpoint needs a certificate from the chain. Unlike the CRL, missing AIA information will not cause a CA to not start, and end users will not be warned about missing the CA certificate unless it is necessary to build a chain which might otherwise present as a trust issue vs. a critical error. If the certificate chain is present in the local system or application trust store, the AIA location is not parsed.

In summary, the AIA location is used to build certificate trust chains. They are often published to the same location as the CRLs and are simply copies of the public certificate for the root, policy, and/or issuing CA servers. This is a non-critical extension, but best practice is to make these available to consumers of your certificates.

Publishing Considerations

The most common question I have heard around CRL and AIA publishing is “what’s the best publishing interval?” The answer depends on your organization’s use of certificates and how aggressive you are with revocation. Our standard guidance provided to customers with low revocation and light usage is approximately one (1) year for a base CRL from the root CA. In the event you have to revoke a subordinate CA or policy CA certificate, you will be manually publishing a new CRL along with a new certificate for their replacements, so one (1) year provides a decent window for operation without completely forgetting the root CA exists. This helps to keep processes around root CA maintenance fresh for your administrative teams. Since issuing CAs are online and can be configured to write the CRL directly to publishing endpoints, a more rapid publishing cadence can be used. I normally recommend anywhere from one (1) week to one (1) month, depending on your anticipated revocation needs.

For AIA publishing, we haven’t discussed CA certificate lifetimes yet, but given a standard two-tier PKI validity period of ten (10) years for the root CA and five (5) years for the issuing CA(s), the certificates published to the AIA location will usually be approximately five (5) years and two-and-a-half (2.5) years old, at most, respectively. (More on CA certificate lifetimes in a future blog post.) As a result, AIA publishing will be a manual process (but can be automated, if desired).

Another common question is what protocols to use for publishing. Technically IETF RFC 5280 Section 3.4 defines LDAP, HTTP, FTP, and X.500 for distribution. Out of the box, ADCS, when configured as an enterprise deployment, will define an HTTP and LDAP endpoint for CRL and AIA publishing. For the purposes of modern security best practice, I advise customers to stick to HTTP for a few reasons:

HTTP is platform agnostic and acceptable for any network-based platform (Windows, Linux, Mac, mobile devices, network devices, etc.)
HTTP presents little network overhead compared to LDAP
Port 80 connectivity is much more palatable to a network security team than allowing communications broadly to port 389

In 15 years of working with ADCS, I have never come across an implementation using FTP. While it is supported as per the specifications, FTP presents a big target for threat actors and should be avoided. I have never seen a pure X.500 distribution configuration.

If you are working in a majority Windows enterprise where everything is domain joined, it could be argued that LDAP is sufficient. LDAP is fault tolerant across all of your AD domain controllers, easily configured from PKIView.msc, endpoints easily managed by group policy, and when configured properly, secure. However, I do not advise relying solely on LDAP for CRL/AIA distribution, as non-Windows systems in your organization (i.e., network, storage, and virtualization platforms) will likely rely on your PKI and may or may not support LDAP calls for lookups.

Additionally, as stated previously, LDAP calls are “expensive” compared to simple HTTP. When you have a conversation with your network security team about accessibility, you are likely to run into opposition to blanket TCP 389 access for your entire organization. Most enterprises with whom I have worked try to lock down port 389 as much as possible, and if you have a proper tier 0 or network segmentation, opening 389 globally introduces a level of risk I would not advise any organization to endeavor. If you or your team are insistent on relying on LDAP, I recommend using HTTP as your second option for fault tolerance and platform accessibility.

HTTP is the best route for CRL and AIA publishing. It is fast, reliable, easily extensible using load balancers, and, in an IIS/Windows implementation, it is possible to configure ADCS to write the CRL directly to the file system of a web server(s) for publishing. It is also natively more secure to just open port 80 to serve up what amount to basic text files vs. opening port 389 to your entire AD infrastructure, allowing access to more than just the published files.

Finally, it is critical to understand that your HTTP publishing endpoint must use port 80. We get the question from time to time about whether or not you can put a certificate in front of the HTTP endpoint to “make it secure.” The problem with that is how are endpoints going to check for revocation of the certificate protecting that web endpoint if the web endpoint uses a certificate with a CRL published to the same location? You will create a loop condition, and the CRL lookup will fail.

Can you put a certificate in front of it? Technically you could, but it would have to be a certificate with a CRL serviced from a different endpoint, likely publicly accessible, which means you are spending money and administrative cycles to maintain a certificate outside of your own PKI which, in my opinion, defeats the purpose of standing up the PKI in the first place.

There is nothing inherently risky about having port 80 open to the specific endpoint, and you can implement security measures on the web server to ensure that a threat actor cannot abuse the web server. All you are serving from that endpoint are some plain text files with information that is necessarily public. There is not anything inherently sensitive in the CRL or AIA that would necessitate protecting the connection with SSL/TLS.

As with many points discussed in this blog, your outcomes may vary. You may have different revocation needs or perhaps you just do not want to deal with booting your root CA annually to do CRL maintenance. For a basic enterprise PKI, the numbers called out in this blog post for publishing intervals should be sufficient to keep things functional without casting aside the need to keep your root CA top-of-mind for your administrative team. Take the time to discuss your needs with your larger organization and set expectations for regular maintenance of your PKI to ensure it remains functional and secure.

That is all for part 2 of our ADCS blog. In part 3, we are going to start shifting away from the root CA as the primary focus to discuss PKI purpose and common hierarchies.

Core Infrastructure and Security Blog articles

Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access

Customer Offerings: Azure Local - Implementation, Migration, and Management

Customer Offerings: Hyper-V - Implementation, Migration, and Management

Auditing FIDO2 authentication for Windows Sign-in

Table of Contents

Entra ID

FIDO2 Security Key authentication in Windows

Authentication flow (high-level)

Mapping the steps to WebAuthN events

WebAuthN Events

Challenge generation

Request construction

How to parse the CBOR-encoded request

Translating Entra key identifier to WebAuthN Credential Id

Authenticator processing

Authenticator PIN Validation

How to parse the CBOR-encoded request

Authenticator GetAssertion operation

Response processing

Tying it all together

Azure Database Security Newsletter - April 2026

Feature highlights 💡

Customer-Managed Keys in Fabric SQL Database

Versionless keys for Transparent Data Encryption in Azure SQL Database

Auditing in Fabric SQL Database

Best Practices Corner

Retain all historical TDE keys and key versions

Apply the Principle of Least Privilege

Enable Auditing on Azure SQL and SQL Server

Blogs and Video Spotlight 🅱️

Community & Events 👥

Previous events

Upcoming events

Call to action 📢

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

Implementing Intune RBAC and Scope Tags for Zero Trust and Least Privilege

TL;DR

Zero Trust and Least Privilege in Modern Endpoint Management

Understanding Intune RBAC Roles and Permissions

Implementing Scope Tags for Distributed IT Management

Establishing a RACI Model for Intune Management

RACI Matrix for Security Policies and Compliance

Application and Conditional Access Management Responsibilities

GPO Migration to Intune: Roles and Responsibilities

RACI Model for GPO Migration

Integrating Conditional Access with Device Compliance

Device-Based Conditional Access Implementation

Measuring Success and Continuous Improvement

Disclaimer

References

What Changed in RC4 with the January 2026 Windows Update and Why it is Important

Why Microsoft Is Targeting RC4

Update Timeline: From Audit to Full Enforcement

Phase 1 – Initial Deployment (January 2026)

Phase 2 – Enforcement Enabled by Default (April 2026)

Phase 3 – Full Enforcement (July 2026)

How to prepare for the changes

Audit events

Identify High Risk Dependencies

Validate Kerberos Encryption Configuration

Establish a Remediation Baseline Before April

Why the January Update Matters (Even If Nothing Breaks Yet)

Remove Unnecessary Azure Storage Account Dependencies in VM Diagnostics

1) Retire the legacy IaaS Diagnostics extension

2) Switch boot diagnostics to Microsoft-managed storage

Wrap-up

Bulk enable Azure Arc Connected Machine Agent Automatic Upgrade (Tag Scoped) with Azure Cloud Shell

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

The Nightmare of renewing NDES Enrollment Agent Certificates

NDES EA Certificates – Quick Recap

Configuring custom NDES Service Certificate Templates

NDES service account

(Source) Certificate Templates to duplicate

Subject and SAN for NDES Service Certificates

a) Build (subject) from this Active Directory information (option 1 from above – using common autoenrollment)

b) Supply (subject) in the request (option 2 from above – using key-based renewal)

NDES EA Certificate Template Configuration Summary

Housekeeping

Final Thoughts