Settings catalog vs administrative templates: what Intune still supports

The Templates > Administrative Templates profile type in Intune is deprecated and read-only, and has been since the December 2412 service release. Its settings now live in the settings catalog. So the comparison people still search for, settings catalog vs administrative templates, is no longer a choice between two supported options. It is a question about what happens to the profiles you already own, and which behaviours change when you rebuild them somewhere else. Every fact below was verified against Microsoft Learn on 13 September 2026.

That distinction matters because the two can sit on the same device for as long as you leave the old profiles assigned. When both set the same value differently, Intune does not pick a winner: it raises an Intune policy conflict and applies neither. Most of the work in this migration is finding those overlaps before a user does.

What changed in the 2412 release

Microsoft’s current ADMX documentation carries the notice directly:

Starting with the December 2412 release, the Templates > Administrative Templates profile type in the Intune admin center is deprecated and read-only.

Read-only is the operative word. The node is still in the admin centre, the profiles are still listed, and nothing was deleted. What you lose is the ability to create a new one. Microsoft’s guidance is now to create the same policy as a settings catalog profile instead, and the documentation itself has moved: the ADMX article is filed under the settings catalog section of Microsoft Learn rather than alongside the other device configuration templates. That is a reasonable signal of where this ends.

Microsoft has run this pattern before. The macOS Endpoint protection and Extensions templates were deprecated in the 2408 release on the same terms, with existing policies continuing to work and new ones blocked. I have not seen Microsoft publish a removal date for administrative templates profiles, and I would not plan around one appearing with much notice.

Settings catalog vs administrative templates: the differences that matter

Most comparison tables for this pair were written before the deprecation and still present it as a preference. It is not. These are the differences that change what you actually do:

The third row is the one that catches people. Settings catalog ADMX settings are generated from CSPs, so what you get is whatever Windows currently exposes to an MDM provider, not a reproduction of what Group Policy exposed on a domain-joined machine. The set is large and it grows, but it is not a guaranteed one-to-one map from your old GPO. Check the specific settings you rely on before you plan a cutover, not after. Microsoft’s settings catalog documentation is the reference for what the catalogue covers per platform.

What happens to the profiles you already have

Nothing, immediately. Read-only describes the editing experience, not the evaluation engine, and the profiles remain in the console with their assignments. The practical constraint is that you cannot change them. Every adjustment to a setting that lives in an administrative templates profile is now a rebuild in the settings catalog, which means the first change request you receive against one of those profiles is the real start of your migration, whether you planned it for that week or not.

I have not verified in a production tenant whether assignments on a read-only profile can still be edited, and that is worth ten minutes in your own tenant before you write a cutover plan. If assignments are locked too, then deleting the old profile is your only way to stop it applying, and deleting it is not reversible. Test that first.

Custom ADMX is the part the settings catalog does not absorb

Built-in Windows ADMX settings are in the catalogue already. Third-party templates are not, so Chrome, Firefox, Adobe and anything else shipping its own ADMX still has to be imported, and that path carries hard limits rather than soft guidance. From Microsoft’s import documentation, verified today:

• A maximum of 20 ADMX files can be uploaded, and each file must be 1 MB or smaller.
• One ADML file per ADMX file, and only en-us ADML files are supported.
• The combo box setting type is not supported. An ADMX file containing one fails to import outright.
• Dependency files must be imported first. If you upload an ADMX without its dependency, the error names the missing namespace.
• Windows 10 and later only, and not every area of the registry can be reached this way.

The dependency rule is the one that wastes an afternoon. Dependencies are declared at the top of the ADMX file, so read them before you upload rather than working backwards from the error:

1<!-- policyNamespaces in an ADMX file. Every "using prefix" entry
2     is a dependency that must already be imported into Intune. -->
3<policyNamespaces>
4    <target prefix="kerberos" namespace="Microsoft.Policies.Kerberos" />
5    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
6</policyNamespaces>

Twenty files sounds generous until you count a browser suite and its dependencies. If you are near the limit today, that constraint belongs in the migration plan rather than in a support ticket six months from now.

The failure modes

Conflict, not a winner. This is the single most common outcome of a half-finished migration. Microsoft’s own wording is plain: if a configuration policy setting conflicts with a setting in another configuration policy, the conflict is shown in Intune and you resolve it manually. There is no precedence rule that quietly favours the newer policy. Leave an old administrative templates profile assigned while you pilot its settings catalog replacement and you will produce conflicts on every device in both assignment groups. The Intune policy and profile troubleshooting reference sets out how this is evaluated, including the separate rule that compliance policy settings take precedence over configuration profile settings.

Not Applicable is usually correct. A setting reporting Not Applicable on a Windows client means that setting is not supported on that device’s Windows version or edition. Home, Professional, Enterprise and Education do not expose the same set. This is not a broken policy and rebuilding it changes nothing. Check the SKU on one affected device before touching the profile.

The combo box import failure gives you no partial success. The file fails, not the setting. If a vendor ADMX will not import, open it and search for the unsupported type before assuming the upload is at fault.

The device has not checked in. Half of what looks like a settings catalog problem in the first hour is a device that has not received the policy yet. Confirm the check-in before you debug the policy, because the two look identical in the console. Forcing an Intune sync separates them in about a minute.

Scope tags hide the policy you are looking for. If a colleague reports that the new settings catalog policy does not exist, check whether their role sees it before you check whether it applies. Intune scope tags control visibility as well as delegation, and a policy nobody can see is indistinguishable from a policy nobody created.

What I would do differently

My tenant is a lab with no enrolled fleet, so I have not run a large administrative templates migration and I am not going to pretend otherwise. What follows is what the documented behaviour implies, and where I would expect it to bite. Treated properly, settings catalog vs administrative templates is a sequencing problem rather than a product comparison.

I would not bulk-rebuild. The conflict behaviour makes a big-bang cutover the worst available option, because every setting you duplicate before removing its predecessor becomes a conflict rather than a change. Migrate one policy area at a time, and remove the old profile’s assignment in the same change window that adds the new one.

I would start with custom ADMX rather than the built-in settings, because it is the only part of this with numeric limits that can fail the plan outright. Twenty files and 1 MB each are either fine or they are not, and you want to know which in week one.

I would export every settings catalog policy to JSON as I build it. The old profiles cannot be edited, so the JSON export is the first version of this configuration you can actually keep, diff and restore. Treating it as the record rather than as a convenience is worth the small amount of discipline it costs.

And I would stop treating the deprecation as a deadline problem. Nothing switches off on a published date. What changes is that the first urgent edit to a legacy profile becomes an unplanned rebuild under time pressure, which is a much worse day than a scheduled one. That risk is already live, and it is the actual argument for doing this now. If your update policies are in the same queue, the same sequencing logic applies to Intune update rings, where overlapping settings cancel each other in a comparable way.

Last verified: 13 September 2026.