Configuring Windows Device Policies in Intune: Settings Catalog, OMA-URI, ADMX, and GPO Migration (MD-102)
MD-102 Study Guide: Configuring Your Tenant for Windows Devices (Intune)
What this section is really about (exam framing)
In MD-102 terms, this content maps to how you configure Windows devices using Microsoft Intune, including:
- Which policy type to use for a given requirement
- How to create and assign policies in the Intune admin center
- How conflicts happen, and why “Not configured” is not always a rollback
- How to migrate GPOs using Group Policy analytics
- How to automate policy creation with Microsoft Graph and PowerShell
Core concepts you must know
1) Intune policies are “cloud GPOs” but behave differently
Intune configuration profiles are equivalent in purpose to GPOs, but:
- They are delivered through MDM (Intune), not traditional AD processing.
- Policies generally apply while the user is logged in (not as a blocking login step).
- More policies does not automatically mean slower logons (unlike some heavy on-prem GPO processing).
MD-102 exam trap: expecting Intune policies to behave like GPO “at logon” processing.
2) Policy conflicts: “same setting in two places” still shows conflict
If the same setting is configured in multiple profiles/blades, Intune can flag a conflict even if both values match.
Practical takeaway: Don’t duplicate settings across:
- Settings catalog profiles
- Endpoint security blade profiles
- Security baselines
- Legacy templates
MD-102 exam trap: “No issue because both settings are the same.” Intune can still show a conflict in the UI.
3) Tattooing: “Not configured” might not undo the setting
“Tattooing” means a setting can remain on the device after you change the policy to Not configured.
Rule of thumb:
- Not configured = “Intune stops managing this setting”
- It does not always mean “revert to Windows default”
- Some settings require you to explicitly set an opposite value to undo.
MD-102 exam trap: assuming Not configured is a rollback action.
Policy types you need to recognize quickly
The “go-to” choices for Windows devices
| Need | Best fit in Intune | Why |
|---|---|---|
| Most Windows settings (modern) | Settings catalog (Unified Settings catalog) | Huge coverage, easier UI, direction Microsoft is moving |
| CSP setting with no template | Custom (OMA-URI) | Direct CSP control when not in catalog |
| Third-party GPO-style settings | Imported Administrative Templates (ADMX ingestion) | Avoid hand-building OMA-URI and keep admin template structure |
| Migrate existing GPOs | Group Policy analytics | Import GPReport.xml, evaluate support, migrate settings |
| Device inventory attributes | Properties catalog (Device Inventory) | Controls what device properties Intune collects |
Settings catalog: what to remember (MD-102)
When to use it
Use Settings catalog for nearly all Windows configuration that is supported natively.
Design best practice
Avoid giant “mega policies.”
- Create multiple policies with fewer settings (OneDrive, Edge, Office, Windows UI, etc.)
- Easier troubleshooting
- Faster editing/loading in the portal
Portal path (must know)
Intune admin center → Devices → Windows → Configuration → Create → New policy
Platform: Windows 10 and later
Profile: Settings catalog
Typical exam scenario
You need to deploy OneDrive settings such as:
- Files On-Demand
- Silent sign-in
- Known Folder Move (KFM)
Answer pattern:
- Create Settings catalog profile
- Add OneDrive settings
- Configure values
- Assign to a user group (because these are user settings)
Custom policies (OMA-URI): what to remember
When to use it
Use Custom when:
- The setting exists as a CSP, but no Settings catalog template exists
- You have exact OMA-URI and value type details from Microsoft documentation
Key OMA-URI exam rule
OMA-URI policies are exact:
- Wrong URI path, wrong data type, wrong value format → policy fails
Portal path
Devices → Windows → Configuration → Create → New policy
Platform: Windows 10 and later
Profile: Templates → Custom
Common example in this section
Skip the User Status Page portion of Enrollment Status Page (ESP):
- OMA-URI points to DMClient / FirstSyncStatus setting
- Value type: Boolean
- Value: True
ADMX ingestion: what to remember
When to use it
Use ADMX ingestion for:
- Third-party administrative templates (example: Firefox)
- Scenarios where Settings catalog does not include those settings
High-value exam points
- Some templates have dependencies (example: Mozilla base templates must be imported before Firefox templates).
- After ingesting ADMX/ADML, you create a profile using:
Templates → Imported Administrative templates (Preview) (wording may vary over time)
Portal path (ingest)
Devices → Windows → Configuration profiles → Import ADMX
Typical flow
- Import base ADMX/ADML (prerequisite)
- Import product ADMX/ADML
- Create Imported Administrative Templates profile
- Configure policy (example: browser homepage)
- Assign to users or devices based on the policy class type
Group Policy analytics (GPO migration): what to remember
Purpose
- Evaluate which on-prem GPO settings are supported by MDM/Intune
- Optionally migrate supported settings into Intune policies
What you need
- An exported GPReport.xml from a GPO backup
Portal path
Devices → Group Policy analytics → Import → Upload GPReport.xml → Review MDM support → (optional) Migrate
Exam angle
When asked “you want to move GPO settings to Intune,” the answer is often:
- Use Group Policy analytics to assess and migrate supported settings
Properties catalog (Device Inventory): what to remember
Purpose
Controls what hardware/software properties Intune collects for reporting (Device Inventory).
Portal path
Devices → Configuration → Create → New policy
Platform: Windows 10 and later
Profile: Properties catalog
Exam angle
If the question is about collecting additional device attributes (BIOS, battery, WMI-derived properties) for reporting, the best match is Properties catalog.
Automation basics you should recognize (Graph + PowerShell)
You do not need to memorize every endpoint, but you should understand the pattern:
Common automation pattern
- Identify endpoint for the policy type
- POST JSON to create policy
- Capture returned policy ID
- POST assignment JSON to the
/assignendpoint targeting an Entra group
Tools mentioned (worth knowing)
- Graph Explorer
- Browser F12 developer tools to inspect network calls/payloads
- Graph Xray extension to infer PowerShell/Graph operations from portal actions
- PowerShell
Out-GridViewto browse large sets of settings
Pagination concept (exam-friendly)
Graph results can include @odata.nextLink. To retrieve everything:
- Loop while nextLink exists
- Keep appending results
Quick “which one do I use” decision checklist (MD-102)
Use this in exam questions:
- Is it a standard Windows setting and likely supported?
→ Settings catalog - Is it a CSP setting but not in catalog?
→ Custom (OMA-URI) - Is it a third-party app with ADMX templates?
→ Import ADMX + Imported Administrative Templates profile - Are you migrating on-prem GPOs?
→ Group Policy analytics (import GPReport.xml) - Are you trying to collect device properties for reporting?
→ Properties catalog
Knowledge check (mini practice)
- You need to configure OneDrive Known Folder Move and silent sign-in for users. Best policy type?
- You must configure a Windows CSP setting that has no Settings catalog template. Best policy type?
- You want to bring Firefox administrative template settings into Intune. What feature do you use first?
- You need to assess which existing GPO settings are supported by Intune and migrate them. Where do you go?
- You want to collect battery cycle count and BIOS info through Intune reporting. What policy type is used?
