A baseline is only worth as much as your ability to get it into the tenant and keep it honest over time. For a long while that meant one path: a PowerShell module written for a broader job that happened to do this one well. There is now a purpose-built way to ship OpenIntuneBaseline, and it changes the calculus of adopting it. Not because it is easier, though it is, but because of what it deliberately refuses to do.
The tool, and the argument its architecture makes
The OIB Deployer is a web application by James Robinson, the same person behind the baseline itself. You sign in with a work account, it reads the current baseline straight from the OpenIntuneBaseline repository on GitHub, and it writes the policies you select into your tenant through Microsoft Graph. Described that way it sounds like a convenience, and it is one. The part that matters to me sits behind it, and behind it is nothing.
There is no server. The application runs entirely in your browser, authenticates through Microsoft’s own MSAL library, and every call goes directly to Graph. Your tenant data and your access token never touch infrastructure belonging to the author or to anyone else, because there is no such infrastructure to touch. This is the whole security argument, and it is a strong one: you cannot leak what you never transmit. The permission it asks for is a single delegated scope, DeviceManagementConfiguration.ReadWrite.All, which any Intune Administrator already carries. No application permission granted tenant-wide, no broad consent that outlives the session, nothing that keeps working after you close the tab.
That design is precisely why I am comfortable running a copy of it myself, and why you should be comfortable running your own.
Whose tool this is
The instance I link to on this site, at deploy.virtualcaffeine.io, is a self-hosted replica. I want to be exact about that word. The tool is James Robinson’s work, not mine. Because it is open source and carries no backend, standing up your own copy is a few minutes of static hosting, and I keep one purely so that links from these articles resolve to something whose uptime I control rather than depending on a service I do not operate. It is the same application, byte for byte, and the credit for it belongs entirely to him. His repository and the official instance are linked at the end of this article. If you would rather point at his instance, or fork and host your own, the behaviour is identical and nothing in the articles that follow depends on which one you use.
What it will not do, and why that is correct
It deploys. It does not assign. Every policy lands in the tenant unassigned, and the tool states this plainly rather than hiding it. That is not a gap waiting to be filled. Assignment is the one decision in this entire exercise that is genuinely yours to make: which ring, which pilot group, in what order, gated behind what validation. A tool that guessed at assignment would be a tool reaching past its authority into yours. The Deployer draws the line exactly where it belongs, at the boundary between importing a known-good artifact and deciding whom that artifact touches. The ring strategy that lives on the far side of that line is the subject of [5.1.1] The Modular Baseline Playbook, and I will not repeat it here.
It also does not customise. It writes the OIB policies as they are published, under their canonical names, and stops. That restraint is deliberate as well, and it is the quiet thing that makes version management possible at all. A tool that let you edit on the way in would produce policies that are neither yours nor upstream’s, and no future comparison could tell you what had drifted from what. By refusing to blur that line, the Deployer keeps the door open to the update workflow I cover in [5.1.5].
The Deployer or IntuneManagement
IntuneManagement, Mikael Karlsson’s PowerShell module, is still the tool I reach for across the wider job. Exporting an entire tenant, documenting policy for a handover, moving arbitrary objects between environments, comparing configurations that have nothing to do with OIB: that is its ground, it is actively maintained, and it is not going anywhere. The Deployer is not a replacement for it, and treating the choice as a contest misreads both.
The distinction is scope, not quality. The Deployer does one thing, the OIB round trip, and it does it natively. It understands the baseline’s structure, pulls the current release without you fetching anything, and reports what your tenant already holds against what upstream now offers. Its import is built to match IntuneManagement’s behaviour, so you are not choosing between two different results, only between a general instrument and a specific one. For standing up OIB and keeping it current, the specific one wins on every axis that matters. For everything that surrounds the baseline, the general one stays in the drawer where it belongs.
The Deployer takes the ceremony out of adopting OIB. It does not take out the judgment, and it is careful not to pretend otherwise. What to deploy and what to leave to Autopatch, which policies to fork before you ever touch them, and how to carry a live deployment from one version to the next without your decisions silently reverting, those are the questions that remain. They are the subject of the next two articles, and they are where the real work was always going to be.
The OIB Deployer is built and maintained by James Robinson (SkipToTheEndpoint), author of the OpenIntuneBaseline. Source: github.com/SkipToTheEndpoint/OIBDeployer. Official hosted instance: deploy.openintunebaseline.com. The copy linked from this site is a self-hosted replica of that tool, run for convenience only.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1.2] CIS Level 1 vs Level 2 in an Intune World
Next: [5.1.4] Deploying OIB with the Deployer: Empty Tenant to Green Baseline ›
