Intune configuration profiles: catalog, baselines and a starting set

Four ways to configure a Windows device

Intune gives you several places to set the same thing, which is the root of most messy tenants. Microsoft's own summary of when to use each:

Microsoft's best practice is blunt: manage a given setting with endpoint security policies or a security baseline, not both.

Settings catalog or templates?

For new work, the settings catalog is usually the better choice. A few details make it easier to run well:

• What the defaults mean. When you add a setting, the catalog shows it with the operating system's default value. Removing a setting from the policy (the minus sign) means Not configured: Intune stops managing it, and the user or another policy can change it.
• User or device scope. Settings tagged (User) write to the user's part of the registry; settings tagged (Device) apply to everyone who uses the machine. A device-scope setting assigned to a user group still applies to every user of that device once the user signs in and the device syncs. If the same setting is set in both scopes, the user scope wins.
• Copies and exports. Duplicate copies a profile without its assignments, and settings catalog policies can be exported to JSON and imported again. Both are handy for keeping a known-good version before you change something.

Templates still have their place. Wi-Fi, VPN and certificate profiles are simpler to build and read as templates.

Security baselines: read them before you deploy them

A baseline is quick to deploy and easy to regret. Microsoft's documentation makes several points worth taking seriously:

• In almost all cases the baseline defaults are the most restrictive values available. Microsoft says to confirm they don't conflict with your other settings.
• The Windows baseline by default turns on BitLocker for removable drives, requires a password to unlock the device and disables basic authentication, among much else. Staff who rely on USB sticks will notice the first one.
• Different baselines can set the same setting to different values. Intune can't decide which one you meant.
• Microsoft doesn't recommend preview baselines in production.
• When a new baseline version is released, profiles on the old version become read-only. You move them to the new version with the built-in update option.
• Microsoft says the Intune baselines aren't strictly CIS or NIST compliant, although its security team consults those organisations.

For a small fleet, we usually find focused endpoint security policies easier to reason about than a full baseline. Whichever you choose, pilot it first.

Assignment: groups, filters and exclusions

Who receives a profile is decided at assignment, and it is where most surprises come from. Microsoft's guidance, condensed:

• Device groups for settings that should apply whoever signs in, such as encryption, firewall and update rings.
• User groups for things that follow the person, such as email, OneDrive and Office app settings.
• Keep user and device policies separate, and don't mix them across include and exclude. Including a device group and excluding a user group isn't supported: Intune doesn't work out which devices belong to which users, so nobody is excluded.
• Assignment filters narrow a policy by device properties such as operating system version, manufacturer, model or ownership, in include or exclude mode. They are evaluated when the device checks in, with no group membership to wait for. A tenant can have up to 200 filters.
• Avoid dynamic device groups as exclusions. Membership takes time to calculate, so a new device can receive a policy before it lands in the exclusion group. Use a filter instead.
• Watch dynamic groups at enrolment. Policies assigned to dynamic device groups don't arrive until the device joins the group. If something must apply during setup, assign to a user group, use a filter, or use enrolment time grouping.

Windows profiles can also carry applicability rules, which limit them to particular Windows editions or version ranges.

Conflicts, and how Intune settles them

A conflict happens when two policies set the same setting to different values on the same device. Intune handles it differently depending on the policy types:

• Compliance beats configuration. If a compliance policy and a configuration policy cover the same setting, the compliance value applies.
• Compliance against compliance: the most restrictive value applies.
• Configuration against configuration (settings catalog, endpoint security, baselines, templates in any mix): Intune marks the setting as Conflict and you resolve it by hand. The setting may not apply at all until you do.

To find the source, open the device in Intune, select Device configuration, select the profile showing Conflict, and then the conflicting setting. Intune lists every profile that sets it. Each profile's per-setting status shows the same picture across the fleet.

Removing a profile doesn't always undo it on Windows. Each CSP decides whether a setting reverts or stays as it was ("tattooing"). If you need a setting changed back, set it to the value you want rather than just deleting the profile.

Timing matters too. Windows devices check in roughly every eight hours, and more often in the first couple of hours after enrolment. A user can force a sync from the Company Portal app. Report figures lag behind: Microsoft says the device assignment status report can take 24 to 48 hours to reflect recent changes.

A starting set for a small Windows fleet

This is the set we would build first for a business of 10 to 150 people with Entra joined Windows laptops. Each line is one profile, assigned to a pilot group before everyone else.

Then add a compliance policy that checks the results (see our compliance policies guide), because a configuration profile sets things and a compliance policy proves they stuck.

Rolling profiles out

1. Name and describe every profile. Microsoft recommends a description that says what the profile does and who created it. Six months later, that is the only documentation anyone reads.
2. One purpose per profile. Microsoft suggests creating profiles by task. Small, single-purpose profiles make conflicts easy to trace.
3. Pilot group first. Assign to the same people as your pilot update ring, wait a day, then check the per-setting status for errors and conflicts.
4. Tell people before restrictive changes. Microsoft gives the example of a passcode moving from four to six characters. Staff take changes better when they hear about them first.
5. Widen the assignment once the pilot is clean, and record the change.

Pitfalls we see

• A baseline plus endpoint security policies setting the same things differently, leaving devices in Conflict for months.
• Old Group Policy still applied on hybrid devices, quietly overriding what Intune sets. Firewall settings are a common example.
• Profiles assigned to All users and All devices on day one, with no pilot.
• Exclusions built from dynamic device groups, which lose the race against new enrolments.
• Deleting a profile and assuming the setting reverts. On Windows, it often doesn't.
• "Not applicable" read as a failure. It usually means the setting doesn't exist on that Windows edition or version.

How 365msp builds profiles

Configuration is part of our Intune device management service, inside the flat $150 per user monthly fee. Every profile we create is named, described, piloted and listed in the configuration record you keep if you ever leave us. Attack surface reduction rules are part of what we run on managed Windows devices, alongside the controls on our security baseline. App Control for Business takes longer: we audit what your devices run, formulate a policy and work towards it over time.