{"id":3268,"date":"2026-10-08T12:10:37","date_gmt":"2026-10-08T12:10:37","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/microsoft-md-102-automating-intune-graph-powershell\/"},"modified":"2026-10-11T17:39:15","modified_gmt":"2026-10-11T17:39:15","slug":"microsoft-md-102-automating-intune-graph-powershell","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/microsoft-md-102-automating-intune-graph-powershell\/","title":{"rendered":"Microsoft MD-102: Automating Intune with Graph and PowerShell"},"content":{"rendered":"

Microsoft Intune automation is built on Microsoft Graph. PowerShell can call Graph directly or use the Microsoft Graph PowerShell SDK to inventory devices, create and assign policy, trigger supported device actions, export reports, and integrate endpoint management with broader operations. The current MD-102<\/a> training path explicitly includes automating Intune with PowerShell and Microsoft Graph, along with Endpoint Analytics and Remediations.<\/p>\n

Automation should make endpoint management more repeatable and auditable, not create a privileged script collection that bypasses the Intune admin model. Register applications deliberately, choose delegated or application permissions according to the workflow, use least-privilege Graph scopes, prefer v1.0 APIs where available, and treat beta endpoints as change-prone interfaces that require version awareness.<\/p>\n

Use Microsoft Graph as the API layer for Intune<\/h2>\n

Intune resources are exposed through Microsoft Graph under deviceManagement and related endpoints. Administrators can query managed devices, configuration, compliance, applications, scripts, reports, and supported actions using REST calls or the Graph PowerShell SDK.<\/p>\n

Start with a documented automation objective rather than browsing for the broadest permission. Read-only inventory, reporting, configuration deployment, script management, and privileged remote actions require different Graph permissions. Separate these workflows when possible so one automation identity does not become an Intune super-administrator.<\/p>\n

Choose delegated or application permissions deliberately<\/h3>\n

Delegated permissions act in the context of a signed-in user and are useful for interactive administrative tooling. Application permissions support unattended automation and service workflows but can operate without an interactive user, which increases the importance of tightly scoped consent and credential protection.<\/p>\n

Use certificate-based authentication, managed identity, or another strong workload-identity pattern where supported instead of long-lived client secrets. Record the app registration owner, tenant consent, Graph permissions, and intended automation so stale app identities can be reviewed and removed.<\/p>\n

Prefer Microsoft Graph v1.0 where the required API exists<\/h3>\n

Microsoft documents many Intune APIs in both v1.0 and beta, but beta interfaces are subject to more frequent change. Microsoft explicitly recommends v1.0 when possible. Production automation should therefore check endpoint availability and avoid beta merely because an example was easier to find.<\/p>\n

When beta is genuinely required, isolate the dependency, log the API version, and add regression tests. Monitor Microsoft Graph change notices and be prepared for schema or behavior changes. A script that silently depends on beta should not become an invisible production control.<\/p>\n

Design scripts for pagination, throttling, and partial failure<\/h2>\n

Graph list operations can return paged results. Automation must follow @odata.nextLink<\/code> rather than assuming the first response contains the entire device estate. Large tenants should also handle throttling and transient errors using bounded retry and backoff instead of immediately rerunning the whole job.<\/p>\n

Write operations should be idempotent where practical. Query current state before creating or assigning resources, use stable identifiers, and log the exact object changed. A rerun after a network timeout should not create duplicate assignments or overwrite unrelated configuration.<\/p>\n

Use the report export APIs for repeatable operational reporting<\/h3>\n

Intune exposes reporting through Microsoft Graph, including the \/deviceManagement\/reports\/exportJobs<\/code> endpoint for migrated reports. Automation can submit an export request, poll for completion, download the generated file, and feed it into governance, inventory, or service-management workflows.<\/p>\n

Reporting automation needs data handling controls. Device and user reports can contain sensitive operational information. Store exported files securely, define retention, and avoid creating uncontrolled copies on administrator workstations or general-purpose file shares.<\/p>\n

Endpoint Analytics provides telemetry for proactive operations<\/h2>\n

Endpoint Analytics helps administrators measure device startup performance, application reliability, battery health, resource performance, and other user-experience signals. Automation can use reporting and analytics data to identify device populations that need replacement, configuration change, application remediation, or deeper support.<\/p>\n

Do not automatically apply disruptive changes solely because a score is low. Use analytics to build a targeted population, validate the suspected cause, and then automate a bounded response. Performance signals need operational context just as security signals do.<\/p>\n

Remediations combine detection and corrective PowerShell<\/h3>\n

Intune Remediations use a detection script and, when needed, a remediation script delivered through the Intune Management Extension. The detection script must return exit code 1 for Intune to run the remediation script. Scripts can run on a schedule, and Microsoft also provides an on-demand remediation action in preview for supported Windows devices.<\/p>\n

Treat remediation code as production endpoint code. The guidance in secure PowerShell<\/a> applies: validate inputs, avoid embedded secrets, use clear error handling, and keep output free of sensitive data. Detection should be safe to run repeatedly, and remediation should be idempotent whenever possible.<\/p>\n

Test automation before broad assignment<\/h2>\n

Use test tenants, pilot groups, read-only dry runs, and staged rollout for scripts that create or assign policy. Validate Graph responses and confirm the current state before performing bulk changes. For PowerShell logic, unit or infrastructure testing can catch assumptions before the script reaches thousands of devices.<\/p>\n

Testing approaches such as Pester-based PowerShell validation<\/a> are useful for functions, policy-generation logic, and remediation scripts. Combine code tests with live pilot validation because Graph permissions, tenant configuration, and endpoint state cannot be fully simulated in a unit test.<\/p>\n

Build Intune automation as governed platform engineering<\/h2>\n

Store scripts and Graph automation in source control, require review, use workload identities with least privilege, log each change, and keep rollback procedures. Separate reporting identities from policy-deployment identities and privileged device-action identities. Review permissions when workflows change instead of continually adding scopes to one long-lived app registration.<\/p>\n

Good Intune automation reduces repetitive administration while preserving the same governance expected in the admin center. The end state is not \u201ceverything scripted\u201d; it is repeatable inventory, reporting, remediation, and configuration workflows that are observable, testable, reversible, and attributable to a controlled identity.<\/p>\n

For bulk automation, separate discovery from mutation. First query and export the objects that would be affected, calculate the intended change, and produce a dry-run summary. Only then execute the write phase under an identity that has the required permissions. This two-stage pattern is especially valuable for assignment changes, device actions, and policy updates where an incorrect filter can affect thousands of endpoints at once.<\/p>\n

Microsoft Graph requests also return request identifiers and HTTP status that should be preserved in automation logs. Use them when troubleshooting throttling, permission failures, and service errors. Respect Retry-After where provided, cap retries, and stop when failure rates exceed a threshold. A script that keeps retrying a permanent authorization error can create noise and hide the first useful diagnostic evidence.<\/p>\n

Treat every automation script as an owned service. Keep source control, tests, documentation, secrets, permissions, monitoring, and retirement criteria together. When a Graph endpoint moves from beta to v1.0, migrate deliberately. When an automation is no longer needed, remove its scheduled execution and revoke its application permissions. The endpoint estate stays safer when automation privilege shrinks as old workflows disappear rather than accumulating indefinitely.<\/p>\n

Automation should distinguish inventory, reporting, configuration, remediation, and privileged device actions because they carry different risk. A nightly read-only inventory job can run with narrow permissions and tolerate eventual consistency, while a bulk wipe, retire, sync, or assignment workflow needs stricter approval, smaller batches, and stronger failure handling. Build separate identities and schedules for these classes instead of one general-purpose script account that can read and modify the whole tenant.<\/p>\n

Microsoft Graph PowerShell cmdlets are wrappers around Graph resources, so administrators should still understand the underlying request and permission model. Log the resource path, HTTP method, important parameters, and resulting object ID for changes. When a cmdlet behaves differently after an SDK update, that record helps engineers compare the generated Graph call with the previous release instead of troubleshooting only at the PowerShell syntax layer.<\/p>\n

Bulk workflows need checkpointing. If a script processes 20,000 devices and fails after 12,000, it should resume from a recorded state or safely re-evaluate completed objects rather than start blindly from the beginning. Store a durable run identifier, input query, object count, last successful checkpoint, and error list. This is especially important when the action changes policy assignment or device state and cannot be rolled back by simply rerunning the inverse command.<\/p>\n

Remediations should be governed as endpoint code packages. Keep detection and remediation scripts in source control, sign scripts where the organization requires it, test on supported Windows versions, and record which package version is deployed to which groups. If the detection logic changes, review whether previously remediated devices should be re-evaluated. A detection script that is too broad can cause repeated unnecessary changes even when the remediation itself is technically safe.<\/p>\n

Reporting automation should preserve schema awareness. Intune report exports and Graph resource shapes can evolve, and beta APIs are especially change-prone. Validate required columns before downstream ingestion, retain the report generation timestamp, and fail the pipeline when a required field disappears rather than silently shifting columns or filling nulls. This prevents a dashboard or compliance export from looking healthy while its source script is parsing the wrong data.<\/p>\n

Finally, treat automation retirement as part of the lifecycle. Remove obsolete scheduled tasks, app registrations, certificates, Graph permissions, service connections, and stored exports when a workflow is replaced. Old automation often retains more privilege than current administrators realize because nobody wants to delete a script that \u201cmight still be used.\u201d An owned catalog of automation jobs, permissions, schedules, and business purpose makes cleanup possible and reduces long-lived privilege in the Intune control plane.<\/p>\n","protected":false},"excerpt":{"rendered":"

Microsoft Intune automation is built on Microsoft Graph. PowerShell can call Graph directly or use the Microsoft Graph PowerShell SDK to inventory devices, create and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,35,134,47],"tags":[],"class_list":["post-3268","post","type-post","status-publish","format-standard","hentry","category-certifications","category-devops-automation","category-exam-md-102","category-microsoft-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3268","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3268"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3268\/revisions"}],"predecessor-version":[{"id":3769,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3268\/revisions\/3769"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}