The architecture article explained why modular baselines are the right approach. This one covers how to actually deploy OIB – what you need before you start, how the import works, what to watch for, and how to roll it out without breaking things.
What you’re importing
OIB v3.8 – the current Windows release, targeting Windows 25H2 – ships as a set of JSON files organized into policy types. Settings Catalog policies live in one folder. Endpoint Security policies in another. Templates in a third. The naming convention encodes everything you need to know about each policy: platform, framework, type, category, scope, function, and version.
The full Windows baseline at v3.8 includes policies covering Defender Antivirus, ASR rules, BitLocker encryption, LAPS, firewall, Edge security and user experience, OneDrive, Microsoft Store, Windows Update rings, device security hardening, script file associations, printing restrictions, and more. You don’t have to deploy all of it. The modular structure means you can import the categories relevant to your environment and leave the rest.
Import tooling
There are now two good ways to bring OIB into a tenant, and the difference is worth understanding. The purpose-built one is the OIB Deployer, a browser-based tool by the baseline’s own author that reads the current release straight from GitHub and writes the policies you select through Graph. It is the path I now lead with, and I cover what it is in [5.1.3] and the deployment decisions in [5.1.4]. The general-purpose one is the IntuneManagement tool by Mikael Karlsson, which predates the Deployer and does far more than OIB alone: exporting, documenting, and moving arbitrary policy between tenants. The Deployer’s import is built to match IntuneManagement’s behaviour, so the result is the same either way, and IntuneManagement stays the tool to reach for once you are working beyond the baseline itself.
The IntuneManagement tool handles all policy types – Settings Catalog, Endpoint Security, Templates, Compliance, and others. This matters because Intune’s native import function is limited to Settings Catalog policies only. If you try to use the native import for Endpoint Security policies you’ll find the option simply isn’t there. The IntuneManagement tool removes that constraint.
When importing, set the root folder to the platform folder you’re importing from – the WINDOWS folder for Windows policies. The tool will discover the policy type subfolders automatically. Import the types you want, leave the rest. The import process creates the policies in your tenant as drafts – they’re not assigned to anything yet. Assignment comes after review.
Import first, review second, assign third. Never import directly to a production assignment group.
Before you import
Read the OIB README and the notes for each policy before importing. This isn’t optional. Several OIB policies have documented caveats that will cause problems in specific environments if you deploy them without understanding what they do.
The Script File Associations policy is the clearest example. It remaps script file types – .ps1, .bat, .cmd, .js, .vbs, and others – to open in Notepad rather than execute. This is a strong security control. It’s also something that will break any workflow where users or processes expect those file types to run on double-click. If you have PowerShell scripts that run in the user context via Intune, this policy will break them. The OIB documentation says this explicitly. Read it before you deploy.
The Windows Package Manager policy restricts winget behavior. If you’re using winget for app deployment or updates, review this policy carefully before enabling it. Disabling the App Installer or the Microsoft Store source will break Store app delivery from Intune – again, documented explicitly in OIB.
ASR rules in OIB ship in Audit mode by default. This is deliberate. Audit mode logs what would have been blocked without actually blocking anything. Review the audit data before switching rules to Block. The architecture article on ASR covers this in detail – the short version is that some ASR rules generate significant noise in environments with LOB applications, and promoting to Block without reviewing that noise first causes application failures that are hard to diagnose after the fact.
Rollout sequence
After importing, the recommended sequence is: assign to pilot, monitor, assign to production. Don’t skip pilot. The OIB policies are well-designed but your environment has specifics that a community baseline can’t anticipate – application dependencies, legacy configurations, user workflows that interact with security controls in unexpected ways. Pilot surfaces those before they affect everyone.
Assign to your pilot device group first. Let the policies apply and check in. Review the Intune policy report for each policy – look for devices reporting errors or conflicts. Review the Defender console for ASR audit events – look for rules generating significant event volume, which usually indicates a rule is interacting with something in your application stack. Give it at least a week of real usage before assigning to production. Two weeks is better.
When you assign to production, consider staggering the rollout if your production group is large. Assign to a subset of production first, wait for the reporting to settle, then expand. Intune doesn’t have a built-in staged rollout mechanism – you approximate it by temporarily using an assigned group rather than your dynamic production group, then migrating to the dynamic group once you’re confident.
Handling conflicts with existing policy
If you’re deploying OIB into an environment that already has Intune policies in place, conflicts are likely. Intune reports conflicting settings in the device configuration report – look for settings marked as “Conflict” rather than “Success.” The conflict means two policies are configuring the same setting with different values, and Intune doesn’t know which one to apply.
The resolution is always to consolidate – remove the setting from one of the conflicting policies rather than trying to establish a winner. In most cases the right approach is to remove the setting from your existing policy and let OIB own it. If you have a specific value that differs from OIB’s recommendation and you have a reason for it, remove the setting from OIB’s policy and document why. Don’t leave conflicts in place and assume everything will work out.
Keeping OIB current
OIB releases track Windows feature updates and security benchmark revisions. When a new version drops, it’s worth reviewing the changelog – the OIB GitHub releases page documents every change, addition, and removal. Not every release requires an immediate update to your production policies, but security-relevant changes should be evaluated promptly.
Updating OIB in an existing deployment means importing the new JSON files and comparing the changes against your current policies. Both the OIB Deployer and the IntuneManagement tool support this, and the Deployer’s Existing Deployment path reports your tenant against the latest release directly. I walk that whole workflow, including the discipline that keeps your own adjustments from being flattened, in [5.1.5]. The version number in the policy name tells you immediately which policies are running an older version. That’s the naming convention paying off.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1] The Security Policy Landscape: Microsoft Baselines, OIB, and How They Fit Together
Next: [5.1.2] CIS Level 1 vs Level 2 in an Intune World ›
