Graph API Change Detected: deviceManagement/intents and deviceManagement/templates deprecated for endpoint security policies

[ugurkocde]

Summary

Two related Microsoft Graph Beta API deprecations affect this project's endpoint security policy retrieval. The project already handles these gracefully (querying configurationPolicies first with deduplication), but the deprecated API calls should be planned for removal.

1. deviceManagement/intents and deviceManagement/templates — Deprecated (MC955748)

Effective: Late March 2025 (over 1 year ago)

Per MC955748, the following Beta APIs no longer support creation/management of Windows endpoint security policies:

• deviceManagement/templates
• deviceManagement/intents

The replacement is deviceManagement/configurationPolicies. Security baselines are exempted and still use intents.

Current project status: The project already queries configurationPolicies as the primary source for each endpoint security category (Antivirus, Disk Encryption, Firewall, EDR, ASR, Account Protection), then falls back to intents with ID-based deduplication. This is correct transitional behavior. However, the intents fallback is now redundant for endpoint security policies since Microsoft has been auto-migrating them for over a year, and these beta APIs could be fully removed at any time.

Affected files (intents fallback queries)

Each of these files queries deviceManagement/intents as a secondary source for 6 endpoint security categories:

File	Example lines
Public/Get-IntuneUserAssignment.ps1	338, 393, 448, 503, 558, 613
Public/Get-IntuneDeviceAssignment.ps1	420, 473, 526, 579, 632, 685
Public/Get-IntuneAllUsersAssignment.ps1	196, 235, 274, 313, 352, 391
Public/Get-IntuneAllDevicesAssignment.ps1	217, 254, 291, 328, 365, 402
Public/Get-IntuneAllPolicies.ps1	335, 387, 439, 491, 543, 595
Public/Get-IntuneUnassignedPolicy.ps1	116, 130, 144, 158, 172, 186
Public/Compare-IntuneGroupAssignment.ps1	348, 364, 380, 396, 412, 428
Public/Test-IntuneGroupMembership.ps1	416, 470, 524, 578, 632, 686
Public/Test-IntuneGroupRemoval.ps1	417, 471, 525, 579, 633, 687
Public/Search-IntunePolicy.ps1	325, 365
Public/Get-IntuneGroupAssignment.ps1	258, 267
html-export.ps1	866, 873

Affected supporting files

File	Usage
Private/Get-IntentTemplateFamilyLookup.ps1	Fetches deviceManagement/templates (line 8) to map templateId → templateFamily for intent enrichment
Private/Add-IntentTemplateFamilyInfo.ps1	Enriches intent policies with template family info
Private/Get-IntuneEntities.ps1	Special-case routing for deviceManagement/intents and deviceManagement/templates (line 17)

Suggested approach

1. Verify completeness: Confirm that configurationPolicies now returns all endpoint security policies (including those originally created as intents). This can be checked by comparing results from both APIs in a test tenant.
2. Remove intents fallback: Once confirmed, remove the deviceManagement/intents fallback queries for endpoint security categories. This eliminates ~72 unnecessary API calls across the module.
3. Clean up supporting code: Remove Get-IntentTemplateFamilyLookup, Add-IntentTemplateFamilyInfo, and the special-case routing in Get-IntuneEntities if no longer needed.
4. Consider keeping intents for security baselines only if the project plans to add security baseline support in the future.

2. deviceManagement/deviceConfigurations — Active Migration to Unified Settings Platform

Started: July 2025

Per the Intune Customer Success blog, Windows device configuration profiles are being auto-migrated from deviceConfigurations to configurationPolicies with new PolicyIDs. The deviceConfigurations API continues to work but will return progressively fewer results as migration proceeds.

The project already queries both deviceConfigurations and configurationPolicies as separate categories, so migrated policies will appear under Settings Catalog. No immediate action required, but monitor whether deviceConfigurations returns empty results in test tenants — at that point the queries can be removed.

Affected files (deviceConfigurations queries)

These files query deviceConfigurations via Get-IntuneEntities:

• Public/Get-IntuneUserAssignment.ps1 (line 112)
• Public/Get-IntuneDeviceAssignment.ps1 (line 160)
• Public/Get-IntuneAllUsersAssignment.ps1 (line 41)
• Public/Get-IntuneAllDevicesAssignment.ps1 (line 41)
• Public/Get-IntuneAllPolicies.ps1 (line 72)
• Public/Get-IntuneUnassignedPolicy.ps1 (line 31)
• Public/Compare-IntuneGroupAssignment.ps1 (line 169)
• Public/Get-IntuneGroupAssignment.ps1 (line 140)
• Public/Get-IntuneEmptyGroup.ps1 (line 51)
• Public/Search-IntunePolicy.ps1 (line 111)
• Public/Test-IntuneGroupMembership.ps1 (line 170)
• Public/Test-IntuneGroupRemoval.ps1 (line 171)
• Private/Get-AssignmentFailures.ps1 (line 80)
• html-export.ps1 (line 625)

What's already handled

For reference, the following API changes have already been addressed in v4.0.0:

• ✅ groupPolicyConfigurations (Administrative Templates) — removed
• ✅ DeviceManagementScripts.Read.All permission — added (MC1107490, enforced July 31, 2025)
• ✅ Dynamic $GraphEndpoint — hardcoded URLs replaced

References

• MC955748 — Updates to Beta APIs for Windows Endpoint security and Administrative templates
• MC1107490 — Updates to required permissions for Graph Beta API deviceManagement
• Windows device configuration policies migrating to unified settings platform
• Endpoint security policies migrating to unified settings platform

[ugurkocde]

Codebase Analysis

Dug into the module to map the full scope of this cleanup. Here's a concrete breakdown.

How the intents fallback works today

Every endpoint security category (Antivirus, Disk Encryption, Firewall, EDR, ASR, Account Protection) follows the same two-phase pattern. Taking Antivirus in Get-IntuneUserAssignment.ps1:314-367 as the representative example:

1. Phase 1 — configurationPolicies (lines 320-335): Fetches all configurationPolicies, filters by templateReference.templateFamily -eq 'endpointSecurityAntivirus', uses Get-IntuneAssignments to get assignments, and adds matching policy IDs to a HashSet[string].

2. Phase 2 — intents fallback (lines 337-366): Fetches all deviceManagement/intents, calls Add-IntentTemplateFamilyInfo to synthetically inject a templateReference property by looking up the intent's templateId against deviceManagement/templates, filters by the same templateFamily, then uses HashSet.Add() to skip any IDs already seen from Phase 1.

This exact pattern is repeated 6× per file across 11 public files plus html-export.ps1.

Supporting infrastructure to remove

File	Purpose
Private/Get-IntentTemplateFamilyLookup.ps1	Fetches deviceManagement/templates (line 8), builds a templateId → templateFamily cache using the $script:IntentTemplateSubtypeToFamily mapping
Private/Add-IntentTemplateFamilyInfo.ps1	Calls the lookup above, injects a synthetic templateReference onto each intent object
Private/Get-IntuneEntities.ps1:17	Special-case URI routing for deviceManagement/intents and deviceManagement/templates to use /beta instead of /beta/deviceManagement
IntuneAssignmentChecker.psm1:10-19	Declares $script:TemplateIdToFamilyCache and the $script:IntentTemplateSubtypeToFamily mapping dictionary

Suggested implementation

Step 1 — Remove the intents fallback blocks from all 11 public files + html-export.ps1

In each file, for each of the 6 endpoint security categories, delete the "Phase 2" block. For example in Get-IntuneUserAssignment.ps1, remove lines 337-366 (Antivirus intents), and the equivalent blocks at lines ~393, ~448, ~503, ~558, ~613 for the other categories.

Also remove the HashSet declarations and the processedXxxIds.Add() guards in Phase 1 — they become unnecessary without Phase 2. Phase 1 simplifies to:

# Get Endpoint Security - Antivirus Policies
$currentCategory++
Write-Host "[$currentCategory/$totalCategories] Fetching Antivirus Policies..." -ForegroundColor Yellow

$configPoliciesForAntivirus = Get-IntuneEntities -EntityType "configurationPolicies"
$matchingConfigPoliciesAntivirus = $configPoliciesForAntivirus | Where-Object {
    $_.templateReference -and $_.templateReference.templateFamily -eq 'endpointSecurityAntivirus'
}

if ($matchingConfigPoliciesAntivirus) {
    foreach ($policy in $matchingConfigPoliciesAntivirus) {
        $assignments = Get-IntuneAssignments -EntityType "configurationPolicies" -EntityId $policy.id
        $reason = Resolve-AssignmentReason -Assignments $assignments -GroupMembershipIds $groupMemberships.id -IncludeReasons @("All Users")
        if ($reason) {
            $policy | Add-Member -NotePropertyName 'AssignmentReason' -NotePropertyValue $reason -Force
            [void]$antivirusPoliciesFound.Add($policy)
        }
    }
}
$relevantPolicies.AntivirusProfiles = $antivirusPoliciesFound

Step 2 — Delete supporting files

• Delete Private/Get-IntentTemplateFamilyLookup.ps1
• Delete Private/Add-IntentTemplateFamilyInfo.ps1

Step 3 — Clean up Get-IntuneEntities.ps1:17

Remove deviceManagement/templates and deviceManagement/intents from the special-case condition:

# Before
if ($EntityType -like "deviceAppManagement/*" -or $EntityType -eq "deviceManagement/templates" -or $EntityType -eq "deviceManagement/intents") {

# After
if ($EntityType -like "deviceAppManagement/*") {

Step 4 — Clean up module variables in IntuneAssignmentChecker.psm1

Remove lines 10, 12-19 ($script:TemplateIdToFamilyCache and $script:IntentTemplateSubtypeToFamily).

Impact

• ~72 fewer API calls per run (6 categories × 1 intents call + 1 templates call per file, cached after first)
• ~700+ lines removed across the module
• No user-visible behavior change — Microsoft has been auto-migrating intents to configurationPolicies for over a year, so Phase 1 already captures everything

Note on deviceConfigurations (item 2 in this issue)

Agree with the assessment — no action needed yet. The module already queries both deviceConfigurations and configurationPolicies as separate categories. Worth monitoring in a test tenant, but safe to defer until Microsoft signals end-of-life for that endpoint.

---

Generated by Claude Code