The previous article established why Microsoft’s monolithic baselines create operational friction and introduced the two policy surfaces – Configuration Profiles and Endpoint Security – as distinct tools doing different jobs. This article focuses on the Configuration Profiles layer and how OpenIntuneBaseline organizes it.
OIB’s Settings Catalog policies cover a wide range of control surfaces, each as its own policy object with its own name, scope, and version. The naming convention tells you everything about a policy without opening it. A policy called Win - OIB - SC - Microsoft Edge - D - Security - v3.8 tells you it’s Windows, OIB framework, Settings Catalog type, Microsoft Edge category, Device scope, Security area, version 3.7. That structure is deliberate – it makes the policy list readable at scale and makes changes auditable over time.
The control surfaces OIB covers through Settings Catalog policies include Defender Antivirus configuration, Device Security hardening, Microsoft Edge, Microsoft Office security, Windows Hello for Business, OneDrive, Microsoft Store, and several others. Each gets its own policy. Each can be assigned, versioned, and adjusted independently without touching anything else. That separation is the entire point.
OIB is not a configuration manual – it’s an opinionated starting point built from real deployment experience. Understanding what it does and why lets you adapt it intelligently rather than applying it blindly.
OIB was built against multiple security frameworks – CIS, NCSC, ACSC, Microsoft’s own baselines – but it doesn’t simply implement their recommendations. It filters them through real deployment experience, including user experience considerations that pure security frameworks ignore. Settings that enforce default behavior a standard user can’t change anyway, or that cause compatibility problems in common enterprise environments, get scrutinized rather than included automatically. The changelog and wiki document the rationale for deviations from CIS and Microsoft recommendations explicitly, which is exactly the kind of transparency that makes a baseline trustworthy.
Importing OIB is done with either the OIB Deployer or the IntuneManagement tool, both of which bring in the entire baseline at once rather than one policy at a time. I compare the two, and cover the Deployer in depth, in [5.1.3]. Once imported, policies follow the naming convention exactly as documented and are ready to assign. The recommended approach is to import into a test tenant or assign to a pilot group first – not because OIB is fragile, but because no baseline should ever go to production without validation in your specific environment.
Assignment follows the same ring structure used for everything else in your environment – pilot, UAT, production. OIB policies are not special in this regard. Assign them to your pilot group, validate behavior over a reasonable period, then expand. The modular structure means that if a specific policy causes a problem, you can exclude it from affected devices without touching anything else.
One constraint to understand clearly: OIB is designed for Windows 11, cloud-native, Entra-joined devices in user-driven Autopilot scenarios. It assumes standard users – not local administrators. It does not account for hybrid scenarios, and applying it on top of Group Policy on domain-joined devices is explicitly not recommended. If your fleet includes a mix of Entra-joined and hybrid devices, scope OIB policies to Entra-joined devices only using assignment filters.
A useful filter rule: target OIB policies to devices where the join type is Azure AD Joined. This keeps hybrid devices out of scope without requiring separate groups for every policy.
OIB is versioned, and new releases add settings, adjust existing ones, and occasionally restructure policies as the platform evolves. Keeping current with OIB releases is worth the effort – the changelog is detailed and the reasoning behind changes is documented. When a new version arrives, review the changelog, understand what changed and why, and make a deliberate decision about whether and when to update your deployed policies.
What OIB does not cover is equally important to understand. It doesn’t configure BitLocker, LAPS, Firewall rules, or ASR rules – those live in the Endpoint Security blade and are covered in the next article. It doesn’t manage updates – that’s Autopatch or Update Rings. It doesn’t define compliance – that’s Phase 6. OIB handles the configuration posture of the device. The security enforcement layers sit on top of it.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1.5] Operating OIB: Version Updates Without Drift
Next: [5.3] Endpoint Security Policies: BitLocker, LAPS, Firewall, and ASR ›
