How to Prepare a Microsoft Intune Tenant Before Enrolling Devices

What you are building, and why the order matters

Intune will happily let any licensed user enrol almost any device until you tell it otherwise, and it will happily let a powerful admin account change everything for everyone. This article closes both gaps before the first PC arrives. You will finish with a lab tenant that has licensed pilot users, safe admin access, three kinds of group, narrowly scoped roles and a first set of enrolment restrictions.

The order is deliberate. Roles and restrictions both point at groups, so the groups come first. Anything that could lock admins out comes before anything that restricts them. The lab is fictional: a made-up business called Lab Co with invented groups named with a LAB- prefix. Swap in your own naming, but keep the habit of making names say what a group is for.

Microsoft occasionally rearranges its portal menus, so check the screen labels against those shown in your tenant. Microsoft uses 'enrollment' in the portal; this guide uses UK spelling in the prose and Microsoft's labels in the steps.

This article does not enrol a device, configure automatic enrolment or create policies. Those are the next steps in the series. It also does not cover Conditional Access, Autopilot, corporate identifier uploads or app protection.

• Use a disposable lab tenant or one your organisation has approved for testing. Do not practise on a production tenant, and do not take the group and restriction settings here as production defaults.
• Licences: Microsoft states that an Intune licence is needed for any user or device that benefits from the service. Microsoft's Business Premium documentation says it includes Intune Plan 1, and Microsoft's Intune pricing page lists Plan 1 as included in Microsoft 365 E3 and E5. We found no Microsoft source confirming Intune Plan 1 in Business Basic or Business Standard, so do not assume it; check the licence list in your own tenant.
• The Intune free trial lasts 30 days. Microsoft describes it as an Enterprise Mobility + Security subscription that includes Microsoft Entra ID P1 or P2 and Intune, which is enough for this lab.
• Entra ID P1 is only needed here if you choose dynamic user groups. We use assigned (manually managed) groups for the pilot rings, so you do not need it for this article.
• Roles you will need during setup: Intune Administrator (a Microsoft Entra role) for restrictions and scope tags, User Administrator to create users, and License Administrator or User Administrator to assign licences. Microsoft says to use these only for setup and then switch to lower-privileged accounts.
• Signing in to the Intune admin centre requires multifactor authentication for every account, including trial tenants. Have an authenticator ready before you start.
• Two to four test users with working mailboxes or at least sign-in capability, and no real staff in the pilot groups yet.

Check licences, MDM authority and your own access

Intune can only manage people who are licensed for it, so start by confirming that, then confirm that the tenant knows Intune is its device manager. The MDM authority setting is how a tenant records which service manages its devices. Microsoft says to set it before users enrol, and in a new trial tenant it is normally set for you.

1. Sign in to the Microsoft 365 admin centre at https://admin.microsoft.com with an account that is at least a License Administrator or User Administrator. Go to Billing > Licenses and select the product that carries Intune (your Business Premium, E3 or E5 plan, or the trial). Check that it has unassigned licences.
2. Go to Users > Active users, select a pilot test user, choose Licenses and Apps, expand Licenses, tick the licence and select Save changes. Repeat for each pilot user. Admins do not need an Intune licence in tenants created after July 2021, so licence your test users, not your admin accounts.
3. Sign in to the Intune admin centre at https://intune.microsoft.com and go to Tenant administration > Tenant status. On the Tenant details tab, check that MDM authority shows Microsoft Intune and that Total licensed users and Total Intune licenses are above zero.
4. If an orange banner says the MDM authority is not set, sign in as an Intune Administrator, select the banner and under Choose MDM Authority pick Intune MDM Authority. Reload Tenant status to confirm it now reads Microsoft Intune.
5. Go to Tenant administration > Roles, expand Monitor and select My permissions. As the tenant creator you should see full permissions to all Intune resources. That is expected today and is exactly what we are about to stop relying on.

Protect admin access before you restrict anything

The account that created a trial tenant holds Global Administrator, which Microsoft says has far more power than Intune needs and which it advises against using for Intune work. The NCSC's identity guidance makes the same point from a security angle: admins should have separate accounts for day-to-day work and for privileged tasks, with privileges reviewed regularly.

So the target is: named admin accounts for people, and a small number of emergency access accounts for the day nobody can sign in normally. An emergency access account is a cloud-only account with Global Administrator that exists only to get you back in if multifactor authentication, a Conditional Access policy or an identity outage locks everyone out. Microsoft recommends at least two, on the onmicrosoft.com domain, with the role permanently active and a phishing-resistant sign-in method such as a passkey (FIDO2) that is not tied to any individual's phone.

Creating Global Administrator accounts is a privileged act and these accounts must never be used for routine work. Do this step in the lab with a deliberate plan for where the credentials are kept.

• Rollback: an emergency account you no longer want can be deleted in Entra ID > Users, and Microsoft keeps deleted users restorable for 30 days.
• We have not repeated Microsoft's passkey registration screens here because they depend on the type of security key you use; follow Microsoft's emergency access guide linked in the sources.

1. Sign in to the Microsoft Entra admin centre at https://entra.microsoft.com as at least a User Administrator and go to Entra ID > Users. Select New user > Create new user.
2. On the Basics tab give the first emergency account a User principal name on your onmicrosoft.com domain and a display name that does not identify a person, for example LAB Emergency Access 1. Go to the Assignments tab, select + Add role and choose Global Administrator. Assigning Entra roles requires Privileged Role Administrator, so you may need to do this as the tenant creator. Select Review + create, then Create. Repeat for a second account.
3. Register a passkey (FIDO2) for each emergency account by following Microsoft's emergency access guide, using a different method from your normal admin accounts. Store the keys and any recovery details somewhere secure that more than one authorised person can reach. Do not register them to anyone's personal phone.
4. Create a named admin account for each person who will administer the lab, separate from their everyday mailbox account, using the same New user route. Do not give these accounts Global Administrator or a permanent Intune Administrator assignment; they will get Intune roles through groups in the next two sections. Whoever performs initial setup holds Intune Administrator only for as long as setup takes, as Microsoft advises.
5. Sign in once with each emergency account to prove it works, then sign out. Put a reminder in your calendar to test them again at least every 90 days, which is Microsoft's stated interval.

Create groups for admins and pilot rings

Intune assigns policies, apps, restrictions and admin roles to groups, and every group you create in the Intune admin centre is really a Microsoft Entra group. Intune needs security groups; Microsoft 365 groups are not security-enabled by default and are not supported. Choose Assigned membership so that you decide exactly who is in each group. Microsoft also warns against mixing users and devices in one group because it causes conflicts and unpredictable behaviour, so keep them apart.

A pilot ring is a group of people (and later their devices) who receive a change before everyone else. Ring 0 is you and one or two IT colleagues. Ring 1 is a handful of friendly users who only join once Ring 0 has been stable for a while. Wider rings come later in the series. A person belongs to one ring only, which keeps later results easy to read.

Group names for the lab: LAB-Admins-PolicyProfile and LAB-Admins-ReadOnly for admins, LAB-Pilot-Users-Ring0 and LAB-Pilot-Users-Ring1 for users, LAB-Pilot-Devices-Ring0 for devices, and LAB-EmergencyAccess for the two emergency accounts. The device group stays empty until the next article, when a device exists to put in it. The emergency group is there so that later Conditional Access work can exclude it in one move, as Microsoft recommends.

• If you later target devices by operating system, manufacturer or ownership, Microsoft suggests an assignment filter rather than a dynamic device group, because filters are evaluated at check-in without waiting for group processing.
• Group changes are not instant. Microsoft says the update that processes user, group and filter assignments between Entra and Intune typically takes up to 15 minutes, so wait a little after changing membership before testing enrolment.

1. In the Intune admin centre select Groups > New group.
2. Set Group type to Security. Enter the Group name, for example LAB-Pilot-Users-Ring0, and an optional description. Set Membership type to Assigned.
3. Select No members selected, use the Users tab to tick the members that belong in this group and confirm. For LAB-Pilot-Devices-Ring0 choose no members for now. Select Create.
4. Repeat for the other five groups. Put only named admin accounts in the two admin groups, directly rather than via a nested group, because Intune role assignments apply only to direct group members when unlicensed admin access is in use. Put the two emergency accounts in LAB-EmergencyAccess.
5. Go to Groups > All groups and check that every group shows Security as its type, Assigned as its membership type and the members you expect.

Assign Intune roles with narrow scope

Intune role-based access control (RBAC) decides what each admin can do. A role assignment links three things: the admin groups who receive the permissions, the Scope (Groups) they may manage, and optionally scope tags that control which objects they can see. Scope (Groups) is the setting that matters most for safety here. If you pick Add all users or Add all devices, a Policy and Profile Manager can target the whole tenant. Choosing only the pilot groups means that, even by accident, they cannot.

It also has a practical consequence for the next articles: an admin can only target groups listed in the Scope (Groups) of their assignment. If a later policy assignment cannot find a group, this is where to look.

Built-in roles that matter now: Policy and Profile Manager (compliance, configuration profiles, Apple enrollment, corporate identifiers and security baselines), Help Desk Operator (remote tasks, assigning apps and policies), Read Only Operator (views everything, changes nothing) and Intune Role Administrator, the only Intune role that can assign permissions to admins. One catch: Microsoft states that only the Intune Administrator Entra role can create, edit, delete and reprioritise enrolment restrictions. Every other built-in Intune role is read-only for them. Plan for restrictions to be an Intune Administrator task done deliberately, not a daily one.

Scope tags are optional for a single-team lab, so we leave the default. Creating them needs Intune Administrator. Do not enable the Scoped permissions toggle under Tenant administration > Roles > Settings. Microsoft currently describes it as an opt-in public preview and says enabling it is a one-time tenant action that cannot be undone. If you ever consider it, run the Permissions Assessment Report first.

• Assignments are made to groups, and permissions from several groups add up for a user. There is no way to deny a permission, so do not put an admin in a group that grants more than their job needs.
• If one admin ends up in several assignments with different scope tags, Intune's default behaviour merges permissions and can give broader access than intended. A single-team lab with default tags will not hit this, but remember it when you add tags.

1. In the Intune admin centre go to Tenant administration > Roles > All roles. You need Intune Role Administrator, or Intune Administrator during setup, to assign roles. Select Policy and Profile Manager, then Assignments > + Assign.
2. On the Basics page enter an assignment name such as LAB Policy and Profile - pilot rings and select Next.
3. On the Admin Groups page select Add groups, choose LAB-Admins-PolicyProfile and select Next.
4. On the Scope (Groups) page add LAB-Pilot-Users-Ring0, LAB-Pilot-Users-Ring1 and LAB-Pilot-Devices-Ring0. Do not select Add all users or Add all devices. Select Next.
5. On the Scope (Tags) page leave the default for this lab, select Next, then Create. The assignment appears in the Assignments list.
6. Repeat for the Read Only Operator role using LAB-Admins-ReadOnly as the admin group and the same pilot groups for scope.
7. Check the result without signing in as the admin: go to Tenant administration > Roles, expand Monitor, select Admin permissions and specify a named admin user. The permission list should match the role you assigned and nothing broader. If you see more, look for another group that user belongs to.
8. Switch from your setup account to a named admin account that holds only the roles you assigned and carry on from there. Sign out of Global Administrator and Intune Administrator work as soon as the setup tasks are finished.

Set the first enrolment restrictions

An enrollment restriction is a gate that is checked when a device tries to enrol. Intune has two kinds: device platform restrictions (platform, OS version, manufacturer, personal versus corporate ownership) and device limit restrictions (how many devices one user can enrol, from 1 to 15). Each kind has one default policy that applies to everyone until you assign a higher-priority policy. When a user matches several policies, only the highest-priority one applies. Edits affect new enrolments only; devices already enrolled are untouched. Microsoft is clear that restrictions are a best-effort barrier for non-malicious users, not a security control.

Here is the trap worth knowing about before you touch the ownership setting. Microsoft documents that if you block personally owned Windows devices, Intune checks that each new enrolment is authorised as corporate. Autopilot, Group Policy or Configuration Manager co-management enrolment, bulk provisioning packages and device enrollment manager accounts qualify. Automatic MDM enrollment with Entra join during Windows setup or from Windows Settings, plus the Company Portal route, are blocked unless the device is registered with Autopilot or matched by Windows corporate identifiers. The next article enrols a PC the ordinary way, so this lab allows personally owned Windows devices for the pilot users and revisits the block once Autopilot or corporate identifiers exist.

Do not upload Windows corporate identifiers yet either. Microsoft says that once you add them, devices matching all three identifiers are marked corporate and every other enrolling device in the tenant is marked personal at enrolment time.

The first policy below is created on a Windows tab, but the device limit policy is created from its own Device limit restriction option; Microsoft documents the two screens separately, so follow each as written.

• The device limit policy will not bite on some Windows routes. Microsoft says device limits cannot be applied to Microsoft Entra joined enrolments, Autopilot, Group Policy, co-management or device enrollment manager enrolments because they use shared device mode. It mainly governs user-driven routes such as Company Portal. Set it anyway as a baseline, and do not read a missing block as a fault.
• The optional step that blocks other platforms edits the default policy for every user not covered by a higher-priority policy. Do it only in a lab or a tenant you have permission to change. Rollback is setting the same options back to Allow, and it never affects devices that are already enrolled.

1. Sign in as an Intune Administrator. In the Intune admin centre go to Devices, and under Device onboarding select Enrollment. Under Enrollment options select Device platform restriction, then the Windows restrictions tab, then Create restriction.
2. On Basics, name it LAB Windows pilot - allow and select Next. On Platform settings set MDM to Allow and Personally-owned to Allow. Optionally set the Allow min/max range minimum to 10.0.22000.0, which is the first Windows 11 build, to keep Windows 10 out; Microsoft says to enter 0 for the revision number. Leave the maximum blank and select Next.
3. Skip Scope tags with Next. On Assignments select Add groups, choose LAB-Pilot-Users-Ring0 and LAB-Pilot-Users-Ring1, and do not choose Add all users. Select Next, check the summary and select Create.
4. In the Device type restrictions table, check that your new policy sits above the default. If not, drag it up to change its priority number. A lower number wins.
5. Now create the device limit policy. Under Devices > Enrollment, choose the Windows tab, select Device limit restriction, then Create restriction. Name it LAB pilot - 3 devices, set Device limit to 3, skip Scope tags, assign the same two pilot user groups and select Create. Confirm it sits above the default.
6. Optional, lab only: for the Android, macOS and iOS/iPadOS tabs of Device platform restriction, open the default policy at the bottom of the table, choose Properties > Edit, change each platform or MDM option from Allow to Block, then Review + save and Save. This keeps a Windows-only lab free of stray phone and Mac enrolments.
7. Open each new policy and check Properties. The assigned groups should be exactly the pilot user groups, and the priority should be above Default. You cannot see a restriction work until the next article enrols a PC, so this is the end of the checking you can do for now.

Optional: take a read-only snapshot with Microsoft Graph PowerShell

Everything above can be inspected with two cmdlets, which is handy for a dated record or a second pair of eyes. These commands only read. They change nothing in the tenant and can be run as often as you like, though the output is a snapshot of that moment.

They run in a PowerShell session on your admin PC. The first time you connect, Microsoft Graph asks you to consent to the two read permissions listed in the Connect command, and a tenant may require an admin to approve them. Intune data is also limited by the Intune permissions of the account you sign in with, so a 403 or empty result usually means a missing role rather than a broken script. We have not run these commands against a live tenant, and the property names come from Microsoft's cmdlet reference, so treat the first run as a test and compare it against what the portal shows.

Install-Module downloads from the PowerShell Gallery into your own profile. Skip the install if you already have the Microsoft Graph PowerShell SDK.

1. Install the two modules you need if they are missing. This changes only your user profile and also pulls in the Microsoft.Graph.Authentication module that provides Connect-MgGraph.
   powershellCopy

   Install-Module Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser
   Install-Module Microsoft.Graph.DeviceManagement.Enrollment -Scope CurrentUser

2. Connect with a named admin account and read-only scopes. A browser window opens for sign-in and multifactor authentication.
   powershellCopy

   Connect-MgGraph -Scopes "LicenseAssignment.Read.All","DeviceManagementServiceConfig.Read.All"

3. List the subscribed licences. Expect one row per product SKU. SkuPartNumber is a short Microsoft product code rather than the marketing name, and Purchased is the number of enabled units.
   powershellCopy

   Get-MgSubscribedSku | Select-Object SkuPartNumber, CapabilityStatus, ConsumedUnits, @{Name='Purchased';Expression={$_.PrepaidUnits.Enabled}} | Format-Table -AutoSize

4. List the device enrollment configurations. Expect your LAB policies plus the default ones, ordered by priority. The Type column shows the kind of configuration, such as a platform restriction or a device limit. Check the priorities against the portal's Device type restrictions table.
   powershellCopy

   Get-MgDeviceManagementDeviceEnrollmentConfiguration -All | Select-Object DisplayName, Priority, @{Name='Type';Expression={$_.AdditionalProperties['@odata.type']}} | Sort-Object Priority | Format-Table -AutoSize

5. Disconnect when you are done so the session does not stay signed in.
   powershellCopy

   Disconnect-MgGraph

Check it worked, record the baseline and know how to undo it

You are done when the checklist below is true and written down. A short baseline record is what lets you, or a colleague, tell later whether something changed. Keep it in your normal documentation but never put emergency credentials, recovery details or tenant secrets in it.

Most of what you did can be reversed. Remove a restriction by deleting it or removing its group assignment; remove a role assignment from the role's Assignments list; delete a group from Groups > All groups; delete an emergency account in Entra ID > Users. Two things are not reversible: enabling Scoped permissions, which we told you not to do, and the Allow access to unlicensed admins setting on tenants created before July 2021, which Microsoft says cannot be undone once on. In a tenant created after July 2021 that second setting is already enabled by default.

• Licences: every pilot user is licensed, and Tenant status shows MDM authority as Microsoft Intune with sensible licence totals.
• Admin access: two emergency accounts exist, have been signed into once, and sit in LAB-EmergencyAccess; named admins are in the admin groups; nobody uses Global Administrator for daily Intune work.
• Groups: Ring 0 and Ring 1 user groups, a Ring 0 device group (empty), two admin groups, all Security and Assigned, with no mixed users and devices.
• Roles: each assignment lists only the pilot groups under Scope (Groups), and the Admin permissions view matches the role you intended.
• Restrictions: a Windows pilot policy and a device limit policy sit above their defaults and are assigned to the pilot user groups only.
• Record to keep: lab name, group purposes and owners, role assignments with scope, restriction names with priority order, who may use the emergency accounts and where the credentials are held, and the date you last reviewed it.
• Not covered or tested: no device has enrolled, no restriction has been seen blocking anything, and nothing here has been tried in a production tenant. The next article enrols one test Windows 11 PC and is where these settings get their first real test.

If something does not look right

These are the blockers that most often stop this particular preparation from working. Anything deeper belongs in a separate troubleshooting guide.

• Tenant administration or Roles will not open: your account lacks an Intune or Entra role. In tenants created before July 2021, admins also need an Intune licence unless the Allow access to unlicensed admins setting is on, and Microsoft says access changes can take up to 48 hours.
• An admin cannot find a pilot group when assigning something: the group is missing from the Scope (Groups) of their role assignment, or they are in a nested group. Add it to the scope, or move the admin directly into the assigned group.
• A group you picked as an exclude group for an assignment does not work: Microsoft says it must be nested inside one of the scope groups or listed as a scope group on its own.
• A restriction does not seem to apply: check it is assigned to a group the user actually belongs to, that its priority is above the default, that the user is not in another group with a higher-priority policy, and that 15 minutes have passed since any group change. Edits never change devices that have already enrolled.
• A user is blocked with an enrolment restriction message: look in Devices > Enrollment failures. Microsoft's corporate identifiers page lists Enrollment restriction not met as the failure reason; if your menu differs, search the Devices area for the enrolment failures report.
• An Entra-joined Windows PC is blocked after you turned on the personally owned block: that is the documented behaviour described above. Allow personally owned Windows devices for the pilot users, or use Autopilot or corporate identifiers.
• Graph returns 403 or no data: consent for the two read scopes has not been granted, or your account lacks an Intune role that can read enrolment settings. Read-only is not the same as permissionless.