Templates or the settings catalog. Pick wrong once and nobody can audit the estate three years from now.
A template bundles settings around one concept, such as email, kiosk or firmware. The settings catalog puts every configurable setting in a single place, cloud native and closer in shape to Group Policy, with thousands of Windows settings the templates never carried. Two templates are already closed to new policies. When a SOC 2 auditor or a CMMC assessor asks why a device is configured the way it is, the shape of your profile estate decides whether the answer takes a minute or a week.
- Two policy typesTemplates, or the settings catalog
- Four platformsWindows, macOS, iOS and iPadOS, Android
- Two deprecatedEndpoint protection and Extensions templates
- Conflict viewWhich profiles caused a conflicting setting
Seven things that decide whether your profile estate stays maintainable.
The settings catalog is Group Policy, reborn in the cloud
One place, every configurable setting, no grouping imposed on you. That is how Microsoft frames the settings catalog, and it draws the Group Policy comparison itself while noting the catalog is cloud native. Because Windows alone carries thousands of catalog settings, including many that never existed in any template, a configuration that aims for full coverage almost always ends up here.
Templates bundle settings around one idea
Email, kiosk devices and device firmware are the examples Microsoft gives of what a template wraps up: a logical set of related settings for a single feature. There are also templates for resource access, Wi-Fi and VPN among them, and for security areas like antivirus, firewall and certificates. When a template matches your requirement exactly, using it beats rebuilding the same thing from catalog pieces.
Two templates no longer accept new policies
The August 2024 service release deprecated both the Endpoint protection template and the Extensions template. Policies that already exist keep functioning; creating new ones is no longer possible. Microsoft points to the settings catalog as the replacement, naming the FileVault, Firewall and System Policy Control payloads for the first and System Extensions for the second. An estate built on either template is carrying a migration debt.
Resource access profiles are the part users feel
A Wi-Fi profile puts a device on corporate wireless with zero user effort. A VPN profile does the equivalent for remote connectivity. Email profiles push Exchange ActiveSync configuration out and keep it monitored, which cuts setup support tickets and lets people read company mail on a personal device without touching a settings screen.
Certificates instead of typed credentials
Deploying certificates lets people reach VPN, Wi-Fi and email resources without ever entering a username or password at a network prompt. Trusted root, Simple Certificate Enrollment Protocol and Public Key Cryptography Standards certificates are the types Microsoft lists as common, and the same machinery supports signing and encrypting mail.
Scripts pick up whatever the settings cannot
When no built-in setting exists, Windows takes PowerShell through the Intune Management Extension, macOS takes shell scripts, and Linux takes Bash scripts you already have. There are also custom profiles: OMA-URI values on Android, or an imported Apple Configurator file on iOS and iPadOS. These escape hatches work well, provided they go through the same change control as everything else.
Conflicts have a first-class view, not a guessing game
Intune can show you exactly which settings are in conflict and which profiles are supplying them, alongside per-device status and assignments. On an estate where profiles overlap, having that view is what separates a ten minute correction from an afternoon spent unassigning things one at a time to see what changes.
Two templates are deprecated. Existing policies run on. New ones cannot be created.
Microsoft published the same deprecation wording for both, and between them they touch the configurations most Windows and macOS estates stand on.
- The Endpoint protection template closed to new policies in the August 2024 service release. What already exists keeps working. For anything new, Microsoft routes you to the settings catalog and its FileVault, Firewall and System Policy Control payloads.
- The Extensions template, which handled macOS system and kernel extensions, carries the identical notice. Its settings catalog replacement is the System Extensions payload.
- What this produces in practice is a forked estate: legacy policies living on templates, everything new living in the catalog, and two different places to check whenever somebody asks what a setting is and why. Livable for a year. By year three it is a mess nobody wants to own.
- Nothing is breaking, which is exactly why the consolidation never gets scheduled. But the cost of merging the two halves only grows, and doing it on your own timetable is far cheaper than doing it mid-incident.
Four habits that stop a profile estate becoming unreadable.
Catalog by default, templates by documented exception
We standardize new work on the settings catalog because it is the one place that holds everything, including the thousands of Windows settings templates never exposed, and reserve templates for the cases where a specific template is a genuinely better fit. The payoff is a single place to look instead of two, which compounds every time somebody has to answer a question about the estate.
Deprecated templates get mapped before they get urgent
Because policies on the Endpoint protection and Extensions templates continue to run, no deadline ever forces the migration, and that is precisely how it never happens. We inventory what sits on those templates and pair each policy with its settings catalog equivalent, turning a slow-burning liability into a scheduled, sized piece of work.
A conflict is a boundary problem wearing a disguise
When the conflict view lights up, two profiles are overlapping because nobody defined where one ends and the other begins. Patching the individual conflict is quick; redrawing the boundary takes an hour; only the boundary fix prevents the same conflict reappearing next quarter. We always do the second.
Group Policy analytics runs before anything gets recreated
For an estate coming off on-premises Group Policy, the analytics tool reports how each object translates to the cloud, flags deprecated settings, and marks what is or is not available to MDM providers. Running it first means you migrate what still matters instead of faithfully recreating settings that stopped mattering years ago, and it finds those every single time.
Six situations where profile design is the deciding factor.
A company moving off Group Policy
The structured route is analytics first: see how each existing GPO translates, which settings are deprecated, and which have no MDM equivalent. Then rebuild deliberately in the settings catalog, the cloud-native construct Microsoft itself compares to Group Policy. The unstructured route is recreating policies from memory, and it shows for years afterwards.
A business putting corporate Wi-Fi on personal devices
Pair a Wi-Fi profile with a certificate profile and users land on corporate wireless having configured nothing and typed no password, authenticated by trusted root, SCEP or PKCS certificates. One move eliminates both the setup ticket queue and the sticky note with the shared Wi-Fi password on it.
A warehouse or logistics floor full of Zebra devices
Zebra hardware, which Microsoft notes is a fixture of factory floors and retail, gets its own treatment through mobility extensions that add device-specific settings beyond what Intune ships natively. At the scale of hundreds or thousands of scanners, that is what turns enrolled into actually managed.
A regulated firm pushing hardening below the OS
Intune reaches the firmware layer on Windows: BIOS access can be password protected using an OEM-generated configuration file, and DFCI profiles switch UEFI settings on or off centrally. Microsoft points out that firmware-level controls resist attack better than OS-level ones, which is why CMMC assessors, examiners and cyber insurers have begun asking the question.
A school district with shared iPads and testing season
The education settings configure the Take a Test app on Windows so nothing else can run until the test ends. On Apple hardware, Classroom settings manage student devices during instruction, and shared iPad configuration lets one device serve several students cleanly.
An organization with a requirement no setting covers
There is always one. The routes are custom profiles, OMA-URI on Android or an Apple Configurator import on iOS and iPadOS, and scripts: PowerShell through the Intune Management Extension on Windows, shell on macOS, Bash on Linux. All legitimate, and all needing the same change discipline as first-class settings, because an undocumented script is tomorrow's mystery.
How organizations configure managed devices.
| Feature | Designed profile estate | Profiles added as needed | Group Policy only, unmanaged mobile |
|---|---|---|---|
Consistent settings across platforms | Yes | Partly | Windows only |
Settings catalog used for full coverage | Yes | Rarely | Not applicable |
Deprecated templates migrated | Yes | No | Not applicable |
Conflicts reviewed and resolved | Yes | When reported | Not applicable |
Profiles tested in rings | Yes | No | Sometimes |
Certificate-based network access | Yes | Sometimes | Rarely |
Mobile devices configured at all | Yes | Partly | No |
Anybody can explain a given setting | Yes | No | Sometimes |
Naming convention exists | Yes | No | Not applicable |
Effort to add a new requirement | Low | Low then rising | High |
What each type does, and which platforms it covers.
Profile type
Settings catalog
- What it configures
- All available settings in a single cloud-native list
- Platforms
- Windows, macOS, iOS and iPadOS, Android Enterprise, Android AOSP
Profile type
Device restrictions
- What it configures
- Security, hardware, data sharing, app store access, passwords
- Platforms
- Windows, macOS, iOS and iPadOS, Android
Profile type
Wi-Fi
- What it configures
- Corporate wireless without user-side setup
- Platforms
- Windows, macOS, iOS and iPadOS, Android
Profile type
VPN
- What it configures
- Remote access connection profiles
- Platforms
- Windows, macOS, iOS and iPadOS, Android
Profile type
Wired networks
- What it configures
- 802.1x wired connections, EAP types, server trust
- Platforms
- Windows, macOS, iOS and iPadOS
Profile type
Certificates
- What it configures
- Trusted root, SCEP and PKCS for authentication and S/MIME
- Platforms
- Windows, macOS, iOS and iPadOS, Android
Profile type
- What it configures
- Exchange ActiveSync configuration, deployed and monitored
- Platforms
- Windows, iOS and iPadOS, Android
Profile type
Kiosk
- What it configures
- Locked-down single app or multi app experience
- Platforms
- Windows, and via device restrictions on Android and Apple
Profile type
BIOS and firmware configuration
- What it configures
- BIOS password protection, UEFI settings via DFCI
- Platforms
- Windows
Profile type
Domain join
- What it configures
- Target domain and OU for hybrid joined devices
- Platforms
- Windows
Profile type
Shared multi-user device
- What it configures
- Sleep, file saving and credential cleanup on shared PCs
- Platforms
- Windows and Windows Holographic for Business
Profile type
Custom profile
- What it configures
- OMA-URI values, or an imported Apple Configurator file
- Platforms
- Windows, macOS, iOS and iPadOS, Android
Profile type
Scripts
- What it configures
- PowerShell on Windows, shell on macOS, Bash on Linux
- Platforms
- Windows, macOS, Linux
Profile type
Delivery optimization
- What it configures
- How update content is downloaded to devices
- Platforms
- Windows
Profile type
Windows health monitoring
- What it configures
- Event data collection for Endpoint Analytics
- Platforms
- Windows
Five steps, and the naming convention matters more than it sounds.
- 1
Inventory what exists and what conflicts
We list every profile with its platform, its assignments, and an owner where one can still be found, then open the conflict view to capture which settings clash and which profiles supply them. This first pass reliably surfaces profiles nobody can justify and conflicts nobody had noticed.
- 2
Decide the structure and the naming convention
Catalog as the default, template exceptions written down. One baseline profile that every device receives, with targeted profiles layered for specific needs. A per-profile-type rule for user versus device assignment instead of ad hoc choices. And a naming convention, because names are the only navigation the console will ever give you.
- 3
Run Group Policy analytics where relevant
If on-premises Group Policy is still in the picture, we run the analytics tool to see how existing objects translate, what is deprecated, and what has no MDM equivalent. That converts guesswork into a migration list and strips out the settings that no longer serve any purpose.
- 4
Build, test in rings, then assign
Profiles are built to the agreed structure and validated against a pilot ring that deliberately includes the strange devices, not just the convenient ones. Restriction profiles get the most caution, because they propagate fast and users notice instantly. This is the step we will not compress, ever.
- 5
Plan the deprecated template migration and hand over
Everything sitting on the Endpoint protection and Extensions templates gets mapped to catalog equivalents with a migration date attached, since neither template accepts new policies. Then each profile gets an owner, changes get a record, and conflict review gets a cadence instead of waiting for a user complaint.
What organizations ask about configuration profiles.
Fifteen decisions that keep configuration maintainable.
Structure
- Settings catalog or templates by default?Choose one, write down the exceptions.
- How many profiles per platform?Fewer and larger beats many and scattered.
- Assigned to users or to devices?Mixing without a rule breeds confusion.
- Is there a baseline every device gets?The pattern Microsoft itself describes.
- What is the naming convention?The console gives you no other map.
Platform reality
- Still using Android device administrator?Deprecated on Google Mobile Services devices.
- Policies on the Endpoint protection template?Closed to new policies.
- Policies on the Extensions template?Also closed to new policies.
- Need multi app kiosk on Windows 11?Only single app kiosk is supported there.
- macOS preference files still required?The catalog now replaces some of them.
Operations
- Who reviews conflicts?The view is useless unless somebody opens it.
- Are profiles ring-tested first?A bad restriction hits everyone fast.
- Is there a change record?Without one, settings become unexplainable.
- Run Group Policy analytics yet?It reports what translates and what does not.
- Does each profile have an owner?Orphan profiles never get cleaned up.
The pages around this one.
Open the conflict view. Empty means clean, or it means nobody has looked.
Two minutes in the console tells you which. It is the fastest available read on whether your profile estate was designed or merely accumulated, and both conditions are fixable, though only one gets more expensive by the month.
Related Services
Explore more solutions that work great with this service