You have a tenant and you have the Deployer. What stands between them is a short sequence of decisions, and most of them you make once and live with for a long time. This is the first deployment, an empty tenant to a green baseline, and the only parts worth slowing down for are the ones that carry consequences: the identity the tool runs as, what you deliberately choose not to deploy, and the fact that the whole thing lands with nothing assigned to anything.
The identity it runs as
The Deployer acts as you. It authenticates through MSAL and carries a single delegated permission, DeviceManagementConfiguration.ReadWrite.All, which anyone holding the Intune Administrator role already has. That is the entire authority model, and it is worth appreciating what it excludes: no directory read beyond your own sign-in, no application permission granted across the tenant, no service principal left behind with standing access to anything. When the tab closes, the access closes with it. I covered why that architecture is trustworthy in [5.1.3]; here it just means the tool cannot do anything you could not already do by hand.
If you self-host, and I keep an instance for exactly the reasons in the anchor article, the one-time setup is an Entra app registration: single tenant, a redirect URI matching where the app is served, ID and access tokens enabled, and the one delegated Graph scope above. That registration is the only persistent object the tool needs, and it grants nothing on its own. It is an empty doorway until a real administrator signs in through it. Register it in the tenant it will manage, scope it to your own directory, and treat it as what it is, a piece of privileged tooling rather than a background service.
Which leads to the one decision here that is genuinely about control: who runs the deployment. Because the tool inherits the signed-in admin’s authority, a deployment session deserves the same handling as any privileged Intune change. A named administrator, activated through PIM for the window rather than standing, never a shared account. The baseline you are about to lay down is the security floor for the whole estate, and the hands that lay it should be accountable.
Choosing what not to deploy
The baseline is offered by policy type, and there is a Select All. On a tenant where you have already made architectural decisions elsewhere in this series, Select All is a quiet mistake. The value of a modular baseline is the right to decline parts of it, and the first deployment is where you exercise that right deliberately rather than discovering later what you swept in.
The clearest case is updates. The tool marks both the Update Policies and the Driver Update Policies with a plain instruction not to deploy them if you use Autopatch, and it is correct to. If Autopatch owns your update rings, and in most of my designs it does, per [5.5], then the OIB update policies are a second hand on the same wheel and the two will fight. Leave them unselected. Deploy them only if you have deliberately chosen rings over Autopatch, and in that case deploy them instead of Autopatch, never beside it.
| Policy type | Take it when | Leave it when |
|---|---|---|
| Endpoint Security | Almost always. This is the security floor: antivirus, firewall, disk encryption, attack surface reduction. | Only the specific policies you are deliberately owning elsewhere. |
| Settings Catalog | Almost always. The modern baseline lives here. | Rarely wholesale; decline individual categories you manage by another design. |
| Compliance | When you have already thought through the Conditional Access that will consume it. | Never before the CA that reads it exists, or you lock people out on day one. |
| Device Configuration | Only for a setting that exists nowhere but the legacy profiles. | By default on a clean cloud-native tenant. Prefer Settings Catalog. |
| Update / Driver Update | Only if you run rings instead of Autopatch. | Whenever Autopatch owns updates. The tool warns you for a reason. |
Compliance deserves a sentence of its own, because the risk there is sequencing rather than inclusion. The OIB compliance policies are sound, but compliance is a signal that feeds Conditional Access, and a compliance policy that goes live before the CA consuming it has been thought through can mark a population noncompliant and cut it off from resources the same afternoon. Take the compliance policies, but take them knowing exactly what reads their output.
The Allow All Trusted Apps setting that reaches into EPM
One cross-series dependency is worth naming before you deploy, because it is the kind of thing you can break later without realising you were the cause. OIB v3.8 changed a Settings Catalog setting called Allow All Trusted Apps from Explicit Deny to an allow state, because the deny was blocking the Endpoint Privilege Management agent and OneDrive from installing their top-level right-click menu entries. EPM’s whole user experience is that right-click Run with elevated access entry, so if you run EPM, covered in [12.2.1], setting Allow All Trusted Apps back to Deny quietly removes the very menu the feature depends on, and takes OneDrive’s shell integration with it. This is exactly the kind of interaction the modular baseline keeps on the surface, where the changelog explains it, and a monolithic baseline would bury three layers down. Read the changelog before you assume a setting means only what its name suggests.
What “deployed” means, and what it does not
When you deploy, the policies are created in the tenant under their canonical OIB names, and that is the end of what the tool does. Nothing is assigned. The Deployer is explicit that assignment is your responsibility, and that division of labor is the right one for reasons I argued in the anchor. So a green baseline immediately after deployment is green only in the sense that the policies exist and are correct. Not one device has received anything yet.
The distance between those two states is the ring rollout, and it is the discipline set out in [5.1.1]: assign to a pilot ring first, watch the device configuration report for conflicts and failures, then widen in deliberate stages. Nothing about using the Deployer changes that sequence. It changes only how you arrive at the starting line, faster and with policies you did not assemble by hand, which is worth a great deal and is not the same as being finished.
One operational caution the tool surfaces itself: it checks for existing policies by name, and if you deploy a policy whose name already exists and select it regardless, you get a duplicate rather than an update. On a truly empty tenant that never bites. The moment a tenant already carries any OIB, updating becomes a different exercise with its own rules, and that is [5.1.5].
Before you assign anything
Three checks earn their place between deployment and the first assignment. Confirm the count of policies the tool created matches what you selected, so nothing failed silently. Spot-check two or three of them by name, because the naming convention from [5.2] tells you the platform, type, and scope at a glance and a wrong token is the fastest thing to catch here. And confirm, deliberately, that nothing is assigned yet. Then put your pilot ring on it and let the rollout begin.
The Deployer got a correct baseline into the tenant quickly and left the one decision with real blast radius, who it touches, entirely in your hands. That is where your attention belongs. Keeping the baseline current once it is live, and doing it without trampling the adjustments you will inevitably make, is the last piece of the story.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1.3] The OIB Deployer: Shipping the Baseline Without the Ceremony
Next: [5.1.5] Operating OIB: Version Updates Without Drift ›
