All projects

Redesigning Intune enrollment for classrooms, meeting rooms and staff laptops

2 min read

The problem
Laptops, classroom PCs, meeting rooms and phones managed the same way, and all working badly.
What I built
One Intune enrollment profile per device role, with its own baseline, policies and app slice.
What came of it
Onboarding a device became choosing a profile; classrooms stopped asking for passwords at 9 am.
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 lecturerMeeting 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 screen in a meeting room, a personal phone with work mail on it. Four kinds of device, four 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 covered Windows, macOS, iOS and Android, and most of that difference between roles 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.

  • 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 fails, a class of eighty people is 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.

All projects