How to Set Up Microsoft Intune for a Small Business (Step by Step)

If you pay for Microsoft 365 Business Premium, you are already paying for Intune. Most small businesses never turn it on, because the setup path looks like enterprise work and the documentation reads like it was written for a company with a dedicated endpoint team.

It is not that bad. For 25 Windows laptops, a competent admin can get from nothing to enrolled, compliant, and encrypted in about two working days spread across a couple of weeks of soak time. This is the order to do it in.

One warning before you start: Microsoft restructured both the Intune documentation URLs and the admin center navigation in the last year. A lot of guides you will find have dead links and menu paths that no longer exist. The paths below were checked in August 2026.

What you are licensed for

Intune comes in three tiers. Plan 1 is the base cloud device management product and is what matters here. Plan 2 is additive, adding Remote Help, Advanced Analytics, Microsoft Tunnel for mobile app management, and firmware-over-the-air management. Intune Suite adds Endpoint Privilege Management, Enterprise App Management, and Cloud PKI on top.

Business Premium includes Intune at the Plan 1 feature level, along with Entra ID P1 and Defender for Business. Microsoft’s Business Premium documentation says subscribers are licensed to use full Intune capabilities for iOS, Android, Mac, and other cross-platform device management.

Business Standard does not include Intune. At $14 versus $22 per user, the $8 difference buys Intune, Defender for Business, and Entra ID P1 — considerably cheaper than adding Intune Plan 1 at $8 and Entra P1 at $7 onto Standard.

Worth knowing: the July 2026 packaging update gave E3 customers Intune Plan 2 features in the box. Business Premium did not get them. If you want Remote Help on Premium, it is still $3.50 per user per month.

Before you touch a device

Six things, in order.

1. Check your network endpoints. Firewall and port blocking is one of the top causes of “the policy applied but nothing happened.” Microsoft publishes the required endpoints; get them allowed before you start rather than debugging it later.

2. Confirm your custom domain is configured so users are [email protected] rather than @yourcompany.onmicrosoft.com.

3. Assign licenses before enrollment. Unlicensed enrollment fails. This sounds obvious and catches people constantly.

4. Verify the MDM authority. Tenant administration → Tenant status → Tenant details → MDM authority. For any tenant created in recent years this is already set to Intune, so treat it as a check rather than a task. If it is unset you will see an orange banner under Devices. Changing it takes up to eight hours to propagate.

5. Create your groups. Entra security groups. Make at least two device groups now — a pilot group and an all-devices group — because you will want to target policies at a handful of machines first.

6. Turn on automatic enrollment. This is the single most important switch. Devices → Enrollment → Windows Enrollment → Automatic Enrollment.

There are two scopes and getting them wrong is the classic misconfiguration:

• MDM user scope: All (or Some, targeting your pilot group). This means the device joins Entra ID and is managed by Intune.
• MAM user scope: None for a company-owned Windows fleet.

Setting both to All is the mistake. MAM scope can win on personal devices and you end up with machines that are registered but not enrolled — visible in the portal, ignoring every policy you deploy. If you also have on-prem Active Directory, our comparison of Active Directory versus Entra ID covers where each fits, and the Entra ID setup guide covers the identity side.

Getting Windows devices enrolled

For a 10 to 50 person company with no on-premise domain controller, cloud-only Entra join with automatic enrollment is the answer. Entra hybrid join exists to keep on-prem AD as the source of truth; if you do not have a domain controller, hybrid join drags in Entra Connect, Group Policy, and an entire second failure domain for no benefit at your size.

The end-user path is Settings → Accounts → Access work or school → Connect. And here is where users go wrong: entering just an email address registers the device — the work account is managed, the machine is not. They have to click “Join this device to Azure Active Directory” at the bottom of that dialog to actually join it. Screenshot this for your rollout instructions, because half of them will pick the wrong one.

The honest truth about Autopilot

Classic Autopilot requires the device to be pre-registered, either by the manufacturer or reseller at purchase, or by you uploading the hardware hash. Laptops bought from Amazon, Best Buy, or Costco are not pre-registered.

Registering them yourself means unboxing each machine, booting to the setup screen, extracting the hardware hash, uploading a CSV, resetting the machine, and running setup again. For 25 devices that is more work than plain Entra join, not less. Autopilot pays off when you buy through a reseller who registers devices at the factory and drop-ships to remote staff.

If you do go that route: run Get-WindowsAutopilotInfo -Online, or export to CSV. The import has real constraints — maximum 500 devices per file, no extra columns, no quotation marks, plain ANSI text, case-sensitive headers. Use Notepad, not Excel. On Windows 11 you can also press Ctrl+Shift+D during setup to reach the diagnostics page and export the hash.

Autopilot device preparation is the newer approach and most guides miss it. It requires no hardware hash registration — policies target user groups, and the device gets added to a device group automatically once the user signs in during setup. That removes the exact barrier that made classic Autopilot impractical for retail purchases. Two limits: it currently supports user-driven physical devices only, and it caps at 10 apps plus scripts per policy during setup. Find it under Devices → Enrollment → Device preparation policies.

One thing not to do: self-deploying mode is the wrong tool for staff laptops. It assigns no primary user, which breaks self-service BitLocker recovery and user-assigned app installs from Company Portal. It is for kiosks and shared devices.

Compliance policies

Devices → Compliance. A sensible Windows baseline for a small business:

Setting	Value
Require BitLocker	Require
Require Secure Boot	Require
Require code integrity	Require
Minimum OS version	Your actual floor — do not set it above your fleet
Firewall	Require
TPM	Require
Antivirus / Antispyware	Require
Defender real-time protection	Require
Security intelligence up to date	Require
Defender for Endpoint risk score	Medium
Password settings	Leave Not configured

That last row is deliberate and goes against a lot of published advice. On Entra-joined Windows devices using Windows Hello for Business, compliance password requirements interact badly with the PIN and generate false non-compliance tickets. Enforce credential policy through Entra password protection and Windows Hello instead.

Set the non-compliance action to 1–3 days, not immediately. The default marks a device non-compliant instantly. Add a “send email to end user” action ahead of it. Do this before you touch Conditional Access, or you will flip 25 people to blocked in one afternoon.

When you do connect compliance to Conditional Access, build the policy in report-only mode first, exclude your break-glass admin account, and validate for a week before enabling it. Also check what your tenant does with devices that have no compliance policy assigned — that setting lives under Devices → Compliance → Compliance policy settings.

The why behind these settings — threat models, frameworks, risk posture — is a security policy question rather than a configuration one. Our sibling site covers device encryption and zero trust if you want the reasoning.

Configuration profiles, in deployment order

Devices → Configuration → Create → New policy. Prefer the Settings catalog profile type — it is searchable and exposes everything.

1. BitLocker. Endpoint security → Disk encryption → Create Policy. This is first for a reason: it is the setting with the most real-world consequence, and escrowing recovery keys to Entra ID is what makes a lost laptop a non-event.
2. Windows Update rings. Set your deferral periods and set feature-update deferral to 0 if you plan to use feature update policies.
3. Endpoint protection — Defender settings, firewall configuration.
4. Device restrictions — the guardrails you actually want, not everything available.
5. Wi-Fi and VPN profiles, if you have infrastructure that needs them.

On security baselines: Microsoft publishes prebuilt baselines and it is tempting to deploy one wholesale on day one. Do not. They are built for enterprise environments and will conflict with settings you have already deployed, producing confusing overlap that is hard to unpick later. Deploy your own profiles first, get them stable, then evaluate a baseline against what you already have.

Apps

The minimum viable setup is smaller than you think:

• Microsoft 365 Apps — deploy directly from Intune, no packaging required. Do this one first.
• Microsoft Store apps — also no packaging.
• Win32 apps — anything with its own installer needs wrapping into a .intunewin file with the Content Prep Tool, plus install and uninstall commands and detection rules.

Start with the first two. Win32 packaging is worth learning, but it is not day-one work, and detection rules are where most first attempts fail.

Updates

Configure update rings under Devices → Windows → Update rings. Give your pilot group a shorter deferral than everyone else so problems surface on machines you control.

Windows Autopatch is worth checking: Microsoft 365 Business Premium qualifies, and Premium already includes the Entra ID P1 and Intune prerequisites. Devices must be corporate-owned and Intune-enrolled — BYOD is excluded — and there is no documented minimum device count. For a small shop that does not want to manage update rings by hand, it is the closest thing to setting this on autopilot.

A realistic timeline for 25 devices

• Day 1, ~3 hours: prerequisites, groups, automatic enrollment, MDM authority check.
• Day 2, ~4 hours: compliance policy, BitLocker profile, update rings, M365 Apps deployment — all targeted at the pilot group only.
• Days 3–10: enroll 2–3 pilot devices. Watch. Fix. This is where you find the firewall rule you missed.
• Week 3: expand to about a third of the fleet, in batches.
• Week 4–5: everyone else, then Conditional Access in report-only mode.
• Week 6: enable Conditional Access enforcement.

Roughly two working days of hands-on effort spread over five to six weeks of deliberate soak time. Compressing it is how you generate tickets.

Mistakes that cause the most tickets

• Both MDM and MAM user scope set to All. Devices register instead of enrolling and silently ignore policy.
• Conditional Access enabled before any device is compliant. Everyone gets locked out at once. Report-only mode exists for this reason.
• No break-glass account excluded from Conditional Access. If the policy misfires, you have locked yourself out of fixing it.
• Compliance password settings on Entra-joined machines. Fights with Windows Hello, produces phantom non-compliance.
• Deploying a full security baseline on day one, then spending a week untangling conflicts.
• Assigning policies to user groups when you meant device groups, or the reverse. Device configuration generally wants device groups; app deployment usually wants user groups.
• The Apple push certificate on a personal Apple ID. If you manage any iPhones or iPads, that certificate expires every 365 days and must be renewed with the same Apple account. Create it under a company address monitored by a distribution list. The classic failure is discovering it was created on the departed office manager’s iCloud account, thirty days after it expired.

Key takeaways

• Business Premium already includes Intune at Plan 1 level — you are likely paying for it already.
• Set MDM user scope to All and MAM user scope to None for a company-owned Windows fleet.
• Cloud-only Entra join beats hybrid join for any company without an on-prem domain controller.
• Classic Autopilot is more work than plain enrollment for retail-bought laptops. Autopilot device preparation removes the hardware-hash barrier.
• Leave compliance password settings unconfigured on Entra-joined Windows devices.
• Build Conditional Access in report-only mode and exclude a break-glass account.
• Deploy BitLocker first; skip prebuilt security baselines until your own profiles are stable.
• Budget two working days of effort across five to six weeks of soak time for 25 devices.

Frequently asked questions

Do I need Intune if I only have 15 laptops? If those laptops leave the building, yes. The value is not scale, it is control — enforced disk encryption with escrowed recovery keys, the ability to wipe a lost device, and knowing patch state without asking anyone. At 15 devices you can do a lot manually; you just cannot prove any of it happened.

Can I manage Macs and iPhones with the same setup? Yes, and Business Premium covers it. Macs enroll through Company Portal. iOS and iPadOS require the Apple MDM Push certificate described above, with its annual renewal. The Windows configuration above does not carry over — you build platform-specific policies for each.

What happens to a device if someone leaves? Retire removes company data and management while leaving personal data intact; wipe returns the device to factory state. For a company-owned laptop being reissued, wipe and re-enroll. Getting this into your standard offboarding process — alongside license removal and account disablement — is what keeps devices from drifting out of management. Our laptop management guide covers the wider lifecycle, and the IT Onboarding and Offboarding Pack has the checklist form.

For the broader Microsoft 365 administration picture, see our admin center basics and Microsoft 365 setup guide. If you want the routine tasks written down as a repeatable runbook, the M365 Admin SOP covers the recurring work.