All projects

Redesigning Intune enrollment for classrooms, Zoom Rooms and 2,000 laptops

March 2025 2 min read

  • Intune
  • Autopilot
  • Endpoint
  • Zoom Rooms
Intune enrollment profiles by device roleDevice roleEnrollmentSecurity baselineApps scoped to the roleWho signs inStaff laptopAutopilot, user-drivenStandard + BitLockerOffice, VPN, LoB appsOne named userPersonal phoneMAM, no enrollmentApp protection onlyMail, Teams, filesThe ownerClassroom PCAutopilot, self-deployingHardened, no local adminPresenting, AV, browserAny lecturerZoom RoomAutopilot, kioskLocked, auto-sign-inZoom Rooms onlyRoom accountMeeting roomAutopilot, sharedHardened + auto-resetTeams, whiteboard, browserAny employeeSame catalogue of applications for the whole company; each profile sees only its slice.

A laptop for a professor, a PC at the front of a lecture theatre, the Zoom Room that streams a class to the other campus, the screen in a meeting room, a personal phone with work mail on it. Five kinds of device, five different definitions of “working”. Managed the same way, they all work badly: the classroom PC asks for credentials at nine in the morning in front of eighty people, and the professor’s laptop carries a kiosk policy that removes the Start menu.

When I took over endpoints at IESE the estate was over 2,000 devices across Windows, macOS, iOS and Android, and most of that difference was handled by hand.

One profile per role

The work was to write down, for each device role, what it needs and what it must never do, and turn that into an Intune enrollment profile with its own security baseline, its own policies, and its own slice of the company application catalogue.

  • Staff laptops: Autopilot, user-driven, a standard baseline with BitLocker, the productivity apps and VPN.
  • Personal phones: no enrollment at all, app protection policies only. The company controls its data, not the phone.
  • Classroom PCs: self-deploying, shared, hardened, no local admin. Any lecturer walks in, signs in, presents. Audio-visual control software is there; nothing else is.
  • Zoom Rooms: kiosk. The device signs in as the room and runs one application. It does not ask anyone anything, ever.
  • Meeting rooms: shared, auto-reset between uses, Teams and a browser.

The application catalogue is one catalogue for the whole company, but each profile sees only the part that belongs to its role. Adding a device to the estate stopped being a checklist and became a choice: which profile is this?

Why it mattered there

Classrooms at a top business school are a critical environment in the plain sense: if the PC or the Zoom Room fails, a class of eighty people and a remote campus are waiting. The profiles were designed so that failure modes were boring: a device that loses its state resets to a known-good configuration on its own, and the person at the front never sees a prompt.

What you could take from this

Start from the roles, not from the devices you have. Five or six honest answers to “who uses this and what must it never do” produce a set of profiles that will outlive any particular hardware refresh, and the migration of existing devices becomes a sorting exercise.

All projects