Someone messaged me last week asking "what license do I actually need for this kiosk in the lobby" and I gave a confident answer that was wrong. Not because I dont know Intune, but because the licensing side of it is scattered across like four different Microsoft pages and none of them agree on vocabulary. So I went and actually sorted it out properly, and figured I'd write it down before I forget it again.
This is the "what license do I need" post. Not pricing, pricing changes constantly and I'm not going to lie to you about numbers that'll be wrong in six months. Just what each license actually covers and when you'd reach for it.
The three Intune plans
Underneath everything, Intune capability is split into three plans. Doesnt matter what bundle you bought, the docs and the admin center both talk in these terms:
Intune Plan 1, the base service. Device enrollment, compliance policies, app protection, config profiles. This covers most of what people think of as "Intune."
Intune Plan 2, additive on top of Plan 1. Adds things like Remote Help and Advanced Analytics.
Intune Suite, additive on top of Plan 1 as well, and it includes everything in Plan 2. This is the one with Cloud PKI, Endpoint Privilege Management, Enterprise Application Management, that kind of thing.
Most people never buy these three directly though. They come bundled.
How you actually get it
Realistically almost nobody buys "Intune Plan 1" as a standalone SKU on purpose. You get it through one of these:
Microsoft 365 E3, E5, or E7, commercial plans, Intune comes bundled at increasing plan levels
Enterprise Mobility + Security (EMS) E3 or E5, this was the original way to get Intune plus Entra ID P1 or P2 without buying full Microsoft 365
Microsoft 365 Business Premium, for the small and mid sized business crowd
Microsoft 365 Education A3 or A5, includes Intune for Education, more on that in a second
Microsoft 365 F1/F3, the frontline worker tiers, if your org has task workers who dont sit at a desk
If you're not sure which bundle your org has, Microsoft 365 admin center > Billing > Your products will tell you, and so will Intune admin center > Tenant administration > Tenant status > Tenant details, which shows total licensed users and total Intune licenses.
Commercial, education, and government arent the same product
Commercial is what almost everyone reading this is on. Standard Intune admin center, standard everything.
Intune for Education is a separate, simplified admin portal built for schools, at intuneeducation.portal.azure.com instead of the regular admin center. It's included with Microsoft 365 Education A3 or A5, and it trims down the enterprise-grade complexity into something a school IT person can actually manage without a full time job doing it. You can still use full Intune alongside it if you need the deeper features.
Government is its own thing entirely. GCC is actually the same commercial instance everyone else uses, just for state and local government tenants that need extra accreditation. GCC High and DoD are different, they run on a physically separate Azure Government Cloud datacenter (referred to as IL4 and IL5). You cant migrate a device between commercial and government clouds either, it has to unenroll and re-enroll clean.
Government cloud is a physically separate instance from commercial. Source: Microsoft Learn.
Assigning the license, step by step
Microsoft 365 admin center > Users > Active users
Pick the unlicensed user
Licenses and apps
Check the box for Intune, or for the EMS bundle if thats what you're assigning, then Save changes
Schools using School Data Sync can assign Intune for Education licenses right in the SDS profile setup instead of doing it user by user.
Assigning an Intune license to a user. Source: Microsoft Learn.
One thing worth knowing, admins dont always need their own Intune license just to manage the service. Tenants created after July 2021 support unlicensed admin access by default, up to 1000 unlicensed admins per security group. Older tenants can turn this on manually under Tenant administration > Roles > Administrator Licensing.
The one everyone forgets: device-only licenses
This is the one that actually started this whole post. If a device isnt tied to a specific person, kiosks, dedicated devices, phone room devices, digital signage, IoT type stuff, you dont necessarily need a full per-user license for it. Intune has a device-only subscription built exactly for this.
Device licenses apply when the device enrolls through one of these paths:
Windows Autopilot self-deploying mode
Apple Automated Device Enrollment without user affinity
Apple School Manager without user affinity
Apple Configurator without user affinity
Android Enterprise dedicated devices
Using a device enrollment manager account
Notice that last one. Device enrollment manager accounts and device-only licenses show up together a lot, because they're both built for the same problem, devices nobody personally owns.
The tradeoff is real though. A device enrolled on a device-only license doesnt get app protection policies, doesnt get Conditional Access, and loses user-based features like email and calendar. Thats fine for a lobby kiosk showing a product catalog. Its not fine if you were hoping to quietly save money by licensing a real employee's laptop this way, that device needs a proper user license because a person is actually using it day to day.
Putting it together
If someone asks you "which Intune license do I need," the real answer is: figure out what bundle your org already has first, because you probably already own Plan 1 through Microsoft 365 or EMS without realizing it. Then check if you're education (Intune for Education, A3/A5) or government (GCC High/DoD is a separate cloud, not just a setting). Then, separately, figure out which of your devices dont belong to a person at all, because those are candidates for a device-only license instead of burning a full user license on a wall-mounted kiosk.
What can we learn as a person
I keep coming back to the device-only license thing. Its basically Microsoft admitting that not everything needs the full package. A kiosk doesnt need email, doesnt need Conditional Access, doesnt need the whole suite, it just needs the bare minimum to do its one job safely. And I think a lot of us hand out the full package to things in our life that only needed the bare minimum. Full emotional investment in a situation that only needed logistics. Full attention on a problem that just needed fifteen minutes. We license everything at Plan 2 when most of it is a device-only situation.
So where in your week are you over licensing something. What's actually just a kiosk, needing the bare minimum from you, that you keep assigning your full user license to?
Last week I watched a junior admin reset a domain admin password from his regular workstation. The same machine he uses to check email, click sketchy DocuSign links, and play Solitaire on lunch. I didnt yell. I just stared at the screen, took a breath, and decided to build a tiered AD model before someone hands the whole domain to a phishing email.
If your AD is flat, this one's for you. If your domain admins log into print servers, also you. And if you've got one giant Admins group that does everything, oh boy, especially you. Here's the whole thing, tier by tier, and it stops the bleeding.
What a tiered AD model actually is
Microsoft's tier model splits your admin identities into three trust levels based on what they control. The whole point is containment. An attacker who owns a workstation should never be able to climb from there up to your domain controllers.
Tier 0 is the identity control plane. Domain controllers, AD CS, AD FS, Entra Connect, and the accounts that run them.
Tier 1 is every other server. File servers, SQL, Exchange, your line-of-business apps.
Tier 2 is workstations and the people who support them. Help desk, desktop support, end-user devices.
The three tiers and what each one controls. Source: Microsoft Learn.
The rule that makes it work is simple. Credentials never move down. A Tier 0 account never signs into a Tier 1 or Tier 2 box. A Tier 1 account never touches a workstation. Break that rule once and the whole model falls over.
The OU structure
Start with three top-level OUs, one per tier. Under each, split admin accounts, groups, and the machines that belong to that tier.
Tier 0 holds your domain controllers, Tier 0 admin accounts, and Tier 0 groups.
Tier 1 holds member servers, server admin accounts, and server admin groups.
Tier 2 holds workstations, help desk accounts, and workstation admin groups.
Your regular user accounts and department OUs sit off to the side in their own structure. Those are just people doing their jobs, not admins of anything.
The security groups
Every tier gets its own security group. Prefix them so nobody has to guess what they do. I use sg- for security group, then the tier, then the role.
sg-Tier0-Admins, full control over AD and domain controllers
sg-Tier1-ServerAdmins, local admin on member servers
sg-Tier2-WorkstationAdmins, local admin on workstations
sg-Tier2-HelpDesk, workstation support plus delegated password reset
Those groups get pushed to the local Administrators group on the right machines through Group Policy or Restricted Groups. A member server trusts sg-Tier1-ServerAdmins and nothing else. A workstation trusts sg-Tier2-WorkstationAdmins. Domain controllers trust only Tier 0.
Roles and how many accounts each person carries
This is where people groan, because it means carrying more than one login. Good. That groan is the sound of security working. Here's how the accounts break down by role.
The System Administrator: four accounts
Your full-stack sysadmin touches everything, so they need a foot in every tier plus a normal life.
A normal account for email, Teams, and daily work
t0-jsmith in sg-Tier0-Admins for domain controller work
t1-jsmith in sg-Tier1-ServerAdmins for servers
t2-jsmith in sg-Tier2-WorkstationAdmins for workstations
Four accounts, four scopes. The domain admin credential never rides along on the same machine where they read email.
The Server Admin: three accounts
Your server team doesnt need the keys to Active Directory. They manage servers and the workstations they sometimes sit at.
A normal account for daily work
t1-account in sg-Tier1-ServerAdmins for servers
t2-account in sg-Tier2-WorkstationAdmins for workstations
Notice the missing Tier 0 account. That's on purpose. A server admin who gets phished cant hand an attacker the domain, because that person was never holding it.
The Help Desk: two accounts and a delegation
Help desk lives in Tier 2. They fix laptops and reset passwords, nothing deeper.
A normal account for daily work
t2-account in sg-Tier2-HelpDesk for workstation support
The password reset piece isnt a tier privilege. It's a delegation. In Active Directory Users and Computers, right-click each department's user OU, choose Delegate Control, add sg-Tier2-HelpDesk, and grant "Reset user passwords and force password change at next logon." Scope it to the department OUs they actually support, not the whole domain. Help desk can unlock the sales team without ever seeing a server.
The part that makes it real: cross-tier logon deny GPOs
Groups without GPOs are just labels on a whiteboard. The enforcement comes from Group Policy denying higher-tier accounts the right to log into lower-tier machines. Without this step, nothing actually stops a Tier 0 account from signing into a workstation.
You build three deny policies, each linked to the OU one tier down. Every policy sets these User Rights Assignments under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies:
Deny log on locally
Deny log on through Remote Desktop Services
Deny log on as a batch job
Deny log on as a service
Deny access to this computer from the network
Link the first policy to your Tier 1 and Tier 2 OUs, denying the Tier 0 groups. Link the second to Tier 2, denying Tier 1 groups. The result is a one-way street. Credentials flow up when you deliberately elevate, never down by accident.
One warning. Test these against a pilot OU before you link them broadly. A deny right applied to the wrong group can lock real admins out of real machines, and that's a bad afternoon.
Why this setup is worth the extra logins
Attackers rarely land on a domain controller first. They land on a workstation, through a phished user or a bad download. From there they hunt for credentials sitting in memory, then hop machine to machine until they find a domain admin token. Security folks call this lateral movement, and it's how most ransomware actually spreads.
The kill chain the tier model is built to break. Source: Microsoft Learn.
Build a tiered AD model and you cut that chain. If a Tier 0 credential never touches a workstation, then owning the workstation gets an attacker nothing but the workstation. The domain admin token they were hunting for simply isnt there to steal. You shrink the blast radius of every single compromise.
The other half of this is the clean keyboard. Microsoft calls them privileged access workstations, PAWs. The idea is that Tier 0 work happens from a hardened machine that never browses the web or reads email. Trust starts at the physical keyboard you sign in from, not the server you're reaching for.
Supported paths from a clean PAW up to a Tier 0 server. Source: Microsoft Learn.
Putting it together
Three tiers, three OUs, four sg- groups, and three deny-logon GPOs. Give your system admin four accounts, your server admins three, and your help desk two plus a scoped password reset delegation. Test the deny rights on a pilot before you go wide. That's the whole model, and it turns a single compromised laptop from a company-ending event into a Tuesday.
What can we learn as a person
The thing that stuck with me building this is that the whole model runs on one boundary. Credentials dont move down. That's it. Everything else is just enforcement of that one line.
I think about how much of my own stress used to come from having no tiers at all. Work stress logged straight into my home life. A bad day with one friend leaked into how I treated my kids. One compromised area, and the attacker moved laterally through everything I had, because I never denied the logon. I was one giant Admins group that did everything, and every problem had domain rights over my whole self.
Tiering my life didnt mean caring less. It meant the hard server day stays on the server, and doesnt get to sign into the parts of me that were supposed to be off-limits. So what in your life is running flat right now? And where do you need a deny-logon rule so one bad thing stops taking down all the others?
Had a client ask me last week "wait, why did MY personal phone just get a work profile pushed on it" and thats basically how this post started. They werent trying to break anything. They just enrolled a device because Intune let them. Nobody had ever told it not to.
So lets talk about who can actually enroll devices into Intune, where that gets decided, and the one setting most tenants forget even exists until something weird shows up in their device list.
The short answer
By default, in a brand new tenant, any licensed user can enroll a device into Intune. Windows, iOS, Android, macOS, doesnt matter. If they have a license that includes Intune and nobody has restricted anything, they can walk up to Settings on their phone, add a work account, and its managed.
That is rarely what you actually want. So there are two separate settings you need to know about, and people mix them up constantly.
Who's actually allowed in: MDM user scope
This one lives in Microsoft Entra, not Intune, which is why half the admins I talk to dont even know it exists. Go to Microsoft Entra admin center > Mobility (MDM and MAM) > Microsoft Intune. There you'll find MDM user scope, and it has three options: None, Some, and All.
None means nobody auto-enrolls or gets redirected to Intune when they try to add a work account. Enrollment is effectively off tenant-wide.
Some lets you pick specific security groups. Only members of those groups can enroll. This is what most orgs should be running, honestly.
All is the wide open default I mentioned above.
This setting decides whether a user is even allowed in the door. Everything else in Intune is fine tuning after that.
MDM user scope in the Microsoft Entra admin center. Source: Microsoft Learn.
Fine tuning who gets through: enrollment restrictions
Once someone is inside the MDM scope, Intune itself has its own restriction policies under Devices > Enrollment in the Intune admin center. Two kinds matter here.
Device platform restrictions control which operating systems and versions are allowed to enroll. Want to block personally owned Android devices but allow corporate ones? This is where that lives. Want to stop anyone showing up with an ancient iOS version? Same place.
Device limit restrictions control how many devices one person can enroll, from 1 to 15. That default limit has bailed out more than one helpdesk when a user's kid enrolled three tablets under the family Microsoft account by mistake.
Setting a device limit restriction in the Intune admin center. Source: Microsoft Learn.
Both of these are assigned to groups and evaluated by priority order, lowest number wins, with the built in "All users" restriction sitting at the bottom as the fallback. So if you create a custom restriction for a group, give it a lower priority number so it actually gets applied before the default one steps in.
Changing these settings, step by step
For MDM user scope:
Microsoft Entra admin center > Mobility (MDM and MAM)
Select Microsoft Intune
Set MDM user scope to Some, then pick your group (or groups)
Save. Give it a few minutes, Entra caches this stuff sometimes and it doesnt always apply instantly
For enrollment restrictions:
Intune admin center > Devices > Enrollment
Pick either "Enrollment device platform restrictions" or "Enrollment device limit restrictions"
Create a new restriction, configure what you need, assign it to a group
Go back to the restriction list and reorder priority so your custom one sits above the default
Forgetting that last step is probably the most common mistake I see. You build a beautiful restriction, assign it, test it, and nothing changes because the default policy is still winning on priority.
What a user sees when they hit the device limit. Source: Microsoft Learn.
The part people actually ask me about: enrollment managers
This is the piece that trips people up when they're setting up kiosks, shared devices, digital signage, that kind of thing. Normally a device enrolls under a specific user's identity, and it counts against that user's device limit. Fine for a normal employee. Not fine when you're trying to enroll 40 lobby kiosks and none of them belong to a real person.
That's what the Device Enrollment Manager role is for. It's a special account, assigned in the Intune admin center under Devices > Enrollment > Device enrollment managers. An account with this role can enroll up to 1,000 devices without hitting the normal per-user device cap, and it isn't blocked by platform restrictions either.
The workflow usually looks like this: create a dedicated account, something like kiosk-enroll@yourtenant.com, dont give it a real mailbox or normal user permissions, just make it exist. Add it as a device enrollment manager. Then use that account to enroll all your shared kiosk hardware. Every device enrolled under it shows up tied to that account instead of a real person, which also makes cleanup way easier later when you're trying to figure out which devices are "real employee devices" versus "that thing bolted to the wall in the lobby."
A few things worth knowing before you go set this up:
Enrollment manager accounts still need an Intune license, same as any enrolled user
They're meant for shared and dedicated devices, not as a workaround for a regular employee who just hit their device limit
Devices enrolled this way still get whatever compliance and config policies you'd normally assign, nothing about being enrollment manager owned exempts them from policy
Dont delete the enrollment manager account once its enrolled devices, that breaks things for those devices
Putting it together
If you only remember one thing from this, remember there are two gates, not one. MDM user scope in Entra decides who gets in the building at all. Enrollment restrictions inside Intune decide what they're allowed to bring with them once they're in. And enrollment managers are the side door for devices that dont belong to any one person, like your kiosks.
Go check your MDM user scope setting today if you havent looked at it before. Theres a decent chance its still set to "All" from whenever the tenant was first stood up, and thats usually not a choice anyone actually made on purpose.
What can we learn as a person
I think about MDM user scope more than I probably should, because its really just a fancy way of answering "who gets access to me." Set to All, anyone with a login can walk in and start pushing things onto your device. Sound familiar? A lot of us run our own lives that way. Anyone with a phone number gets a work profile pushed straight onto our evenings. Anyone who asks gets a yes. We never set it to Some.
And then theres the enrollment manager thing, one dedicated account taking on the kiosk devices so it doesnt fall on fifteen different people's shoulders. I think thats a good model for life too honestly. Not everything needs to be YOUR device cap. Some stuff, the shared stuff, the repetitive stuff, is better handled by one clear owner instead of everybody carrying a little piece of it and nobody really owning it. That's usually where things fall through the cracks, when its everyone's job a little bit and nobody's job fully.
So what's your MDM user scope set to right now. Who's in it. And is there something in your week that really should have one clear owner instead of quietly being everyone's problem?
If you are new to Microsoft 365 administration, simple room resources are one of the first things people will ask you to fix. Someone double-booked the big conference room. A meeting got auto-declined for no clear reason. The room shows up in Outlook but nobody can actually book it. All of these come down to one object type: the room mailbox.
A room mailbox is a special kind of resource mailbox in Exchange Online. It has a calendar, it has an email address, and it can accept or decline meeting invites on its own. When you book a room in Outlook, you are really sending a meeting request to that mailbox, and the mailbox decides what to do with it.
This post covers how to create and manage simple room resources two ways: through the Exchange admin center, and through PowerShell. The GUI is fine for getting started. PowerShell is where you get the permission controls that actually solve the messy problems.
What a simple room resource actually is
Strip away the marketing and a room mailbox is three things working together:
A mailbox object with its own SMTP address, so it can receive booking requests.
A calendar that holds the bookings.
A set of booking rules, called calendar processing, that decide how the mailbox responds to requests.
There is a sibling object called an equipment mailbox. It works the same way but is meant for things that are not tied to a location, like a projector, a loaner laptop, or a company vehicle. Everything below applies to both. The only real difference is the resource type you pick when you create it.
One rule to memorize early: never make a room mailbox the organizer of a meeting. A room is something you invite, not something that runs the meeting. Add it to the location or attendee field of the invite and let it respond.
Creating simple room resources in the Exchange admin center
The Exchange admin center, or EAC, is the web console for Exchange Online. You get to it at admin.exchange.microsoft.com, or through the main Microsoft 365 admin center by going to Show all > Exchange. You need to be a Global Administrator or have the Exchange recipient management role to do any of this.
Create a room mailbox
In the EAC, go to Recipients > Resources. This page lists every room and equipment mailbox in the tenant.
Click Add a resource. A panel opens on the right and walks you through four steps:
Resource setup. Choose Room or Equipment. For a conference room, pick Room.
General information. Give it a display name, set the email alias, and add the capacity. Capacity matters more than it looks. Outlook's Room Finder uses it to filter rooms by how many people you are inviting.
Booking options. This is where you decide whether the room accepts meetings automatically, whether it allows conflicting bookings, and how far out people can book it.
Review resource. Confirm the settings and click Create.
Give Exchange a few minutes after you create it. The mailbox and its calendar do not always appear instantly.
Edit booking behavior
Back on the Recipients > Resources page, click the room you just made. A details pane opens. The settings you care about live in two spots:
Under General, you can edit the resource details, capacity, and contact information for the room.
Under Booking, click Manage booking settings. This is the heart of room behavior.
Inside booking settings you can control:
Whether to auto-accept meeting requests or send them to a delegate for approval.
Whether to allow conflicting meetings (almost always leave this off for a real room).
The booking window, which is how many days in advance someone can reserve the room.
The maximum duration for a single booking.
Whether to allow recurring meetings.
Set delegates in the GUI
If you want a person to approve every booking, look for the delegate option inside booking settings. Add the user there, and the room switches from auto-accept to manual approval. Every request will sit in a pending state until that delegate says yes.
That covers the everyday work. The GUI is clean and fast for one room at a time. The trouble starts when you need rules that are more specific than "auto-accept or ask a delegate." That is where you open PowerShell.
Managing simple room resources with PowerShell
The GUI gives you the common switches. PowerShell gives you all of them, plus the ability to do the same thing to fifty rooms in one command. For permissions especially, PowerShell exposes controls the web console simply does not show you.
A browser window opens for sign-in, including multifactor auth if you have it on, which you should. When you are done, run Disconnect-ExchangeOnline to close the session cleanly.
Create a room mailbox
New-Mailbox -Name "Conf Room - Building A" -Room
You can set the capacity and other properties right after with Set-Mailbox:
Set-Mailbox -Identity "Conf Room - Building A" -ResourceCapacity 12
Room lists are PowerShell only
Here is a detail that catches new admins off guard. A room list is a special distribution group that powers the Room Finder in Outlook. It lets users browse rooms by building. You cannot create a room list in the GUI. You have to use PowerShell.
New-DistributionGroup -Name "Building A Rooms" -RoomList
Add-DistributionGroupMember -Identity "Building A Rooms" -Member "Conf Room - Building A"
If your simple room resources are not showing up grouped by building in Room Finder, a missing room list is usually why.
Calendar processing is where the real control lives
Every booking decision a room makes comes from its calendar processing settings. You read them with Get-CalendarProcessing and change them with Set-CalendarProcessing. Run the Get command first so you can see the current state before you change anything.
Get-CalendarProcessing -Identity "Conf Room - Building A" | Format-List
A solid baseline for a normal conference room looks like this:
AutomateProcessing has three values. AutoAccept books and declines on its own. AutoUpdate adds tentative holds but does not commit. None turns the automation off entirely.
AllowConflicts does what it says. For a physical room, keep it $false so two teams cannot claim the same space.
BookingWindowInDays stops someone from blocking the room a year out.
Make the meeting details readable
By default, a room strips the subject line off accepted meetings and replaces it with the organizer's name. So the calendar fills up with entries that just say "Booked" or a person's name, and nobody can tell what is happening in the room. These settings fix that:
DeleteSubject $false keeps the real meeting title. DeleteComments $false keeps the body of the invite. Run these on a shared room and the calendar suddenly becomes useful to look at.
Advanced permission control through PowerShell
This is the part that makes PowerShell worth learning. The GUI gives you "auto-accept" or "send to a delegate." PowerShell lets you decide who can book the room, who needs approval, and who can see what on the calendar. There are three layers, and they do different jobs.
Layer one: who can book without approval
These settings answer the question "can this person book the room directly, or does it need a sign-off?"
BookInPolicy is a list of users or groups whose in-policy requests get accepted automatically.
AllBookInPolicy set to $true lets everyone book directly as long as the request follows the rules.
RequestInPolicy sends in-policy requests to a delegate for approval instead of auto-accepting.
RequestOutOfPolicy lets specific people submit requests that break the rules (too long, too far out) and have a delegate decide.
A common real-world setup: the whole company can book the room normally, but only the leadership group can book it for longer than the usual limit or outside the normal window.
Set AutomateProcessing to AutoUpdate here. If you leave it on AutoAccept, the room books everything on its own and the delegate never gets a say. The delegate then receives the pending requests and approves or rejects each one from their own Outlook.
You can list more than one delegate. Keep in mind that delegates approve, they do not own the calendar.
Layer three: who can see and edit the calendar
This is a different kind of permission, and it confuses people because it does not live in calendar processing at all. It lives on the calendar folder itself, and you manage it with the mailbox folder permission commands.
Use this when an executive assistant needs to actually open the room calendar, move meetings around, or see full meeting details instead of just free or busy time.
To change an existing permission, use Set-MailboxFolderPermission. To remove one, use Remove-MailboxFolderPermission. The access levels run from least to most access:
AvailabilityOnly shows free or busy time and nothing else.
LimitedDetails adds the subject and location.
Reviewer lets the person read full meeting details.
Editor lets them read, create, and change items on the calendar.
For most people, Reviewer is enough. Hand out Editor only to the person who genuinely needs to rearrange the room's schedule.
A note on Full Access
You can grant Full Access to a room mailbox with Add-MailboxPermission, but think twice before you do. Full Access means the user can open the entire mailbox, not just the calendar. For room management, a calendar folder permission is almost always the right and safer choice. Give people the least access that solves the problem.
Putting your simple room resources together
A clean setup usually follows the same path. Create the mailbox, set its capacity, drop it into a room list so Room Finder works, set sensible calendar processing so it books well and keeps readable subject lines, then layer on permissions only where a real person needs them.
Start in the GUI while you are learning the objects. Move to PowerShell the moment you need more than one room handled the same way, or any permission setup more specific than auto-accept. The web console is the front door. PowerShell is the whole house.
What we can learn as a person
There is something worth sitting with here, past the cmdlets and the click paths.
A room mailbox works because it has limits. It knows its capacity. It only takes so many bookings, only so far out, only for so long. When a request breaks the rules, it does not feel bad about it. It declines, or it hands the decision to someone else and moves on.
We are worse at this than a conference room.
Most of us run with auto-accept turned on for everything. Every request, every favor, every late "quick thing" gets booked straight into the calendar, conflicts and all. We say yes past our own capacity, then wonder why we feel scraped out by the middle of the week.
You are allowed to set a booking window, have a maximum duration, and decline a request that falls out of policy, and you do not owe anyone a long apology for it.
You are also allowed delegates. The reason we hand approval to someone else is that one person was never meant to carry every decision. Asking for help is not the system failing. It is the system working the way it was built to.
So take some of the load off your shoulders. Figure out what you can actually hold, set the rules that protect it, and let the rest go to someone who has room. The person who guards their capacity is still standing next year. The one who accepts every booking burns out by Thursday.
The room does not run the meeting. It was never supposed to. Neither are you.
FAQ
What is the difference between a room mailbox and a regular shared mailbox?
A room mailbox is built to accept and decline meeting invites through calendar processing rules. A shared mailbox is built for people to read and send mail together. They are different recipient types, and you should not try to use one as the other.
Why does my room calendar only show "Booked" instead of the meeting name?
By default the room deletes the subject and adds the organizer's name instead. Set DeleteSubject $false and AddOrganizerToSubject $false with Set-CalendarProcessing to keep the real titles.
Why can people see the room in Outlook but not book it?
Check the calendar processing. If AutomateProcessing is set to None, the room will not respond to requests. Also confirm AllBookInPolicy or BookInPolicy actually includes the people trying to book.
Can I create a room list in the Exchange admin center?
No. Room lists exist only in PowerShell. Use New-DistributionGroup with the -RoomList switch, then add your rooms with Add-DistributionGroupMember.
Should I give someone Full Access to manage simple room resources?
Usually not. Use Add-MailboxFolderPermission on the calendar folder with Reviewer or Editor rights instead. Full Access opens the whole mailbox, which is more than calendar management needs.
Every AD environment I've inherited has had the same problem. Hundreds of GPOs, half of them doing nothing, and nobody willing to delete any of them because nobody knows which ones are actually in use. So they sit there. They slow down gpresult, or They confuse the next admin. They make troubleshooting a mess because you can't tell at a glance which policies matter.
I've stopped trying to clean these up by hand. PowerShell handles it in about thirty seconds, and the safest first move isn't deletion. It's renaming. I prefix anything suspect with Review - and let the rename sit for a quarter. If nothing screams, then I delete.
Here's how I do it.
What counts as a candidate
Two categories I go after first.
Empty GPOs. No user settings, no computer settings. Someone created them, never configured them, and walked away. These are pure noise.
Unlinked GPOs. They have settings, but they aren't linked to any OU, site, or domain. They don't apply to anything. Sometimes these were intentionally unlinked during an incident and never cleaned up. Sometimes they were duplicates created during a migration. Either way, if nothing is linked to them, they aren't doing work.
I do not lump these together in the rename. I want to know which is which when I review later.
What you need
The GroupPolicy module, which ships with RSAT. Run from a domain-joined machine with rights to read and modify GPOs. I usually do this from a jump box rather than a DC, but either works.
Import-Module GroupPolicy
If that fails, install RSAT first. On Windows 11 it's under Optional Features, RSAT: Group Policy Management Tools.
Finding empty GPOs
The trick here is that Get-GPO doesn't tell you whether a GPO has settings. You have to look at the XML report and check the user and computer extension data. If both are empty, the GPO has no settings.
The ExtensionData node only exists when something is actually configured under that side of the policy. If both come back null, the GPO is empty.
Run it once and review the list before you do anything else. I always find at least one GPO in the list that I created myself months ago and forgot about, which is humbling.
Finding unlinked GPOs
Same approach, different XML node. The LinksTo property tells you where a GPO is linked. If it's null, nothing points at the GPO.
One thing to watch for. A GPO can be linked but disabled at the link level. That's a different state, and I don't treat those as unlinked. They were intentionally turned off, usually for a reason. If you want to catch those too, the XML has an Enabled attribute on each LinksTo entry. But for a first pass, I leave them alone.
Renaming, not deleting
This is the part that matters. Don't delete.
I learned this the hard way years ago. Deleted what I thought was a dead GPO, found out two weeks later it was applying a registry setting to a single workstation that nobody had documented, and spent an afternoon rebuilding it from a backup. Now I rename and wait.
I use Review - with a space, hyphen, space because it sorts cleanly in GPMC. Everything you flag bunches together at the top of the list, which makes it obvious at a glance what's pending review.
I don't add a date or my initials in the rename. The GPO already tracks modification time, and you can see who last touched it in the change history. Adding metadata to the display name just makes it harder to read.
If a GPO is both empty and unlinked, my script renames it twice and you end up with Review - Review - GPO Name. Worth deduplicating before the loop if you care:
$candidates = ($emptyGPOs + $unlinkedGPOs) | Sort-Object Id -Unique
Back up before you rename
This should be obvious but I'll say it anyway. Back up every GPO you're about to rename. The rename itself is reversible, but if you're going to come back later and delete, you want the backups ready.
Each backup gets its own folder under the dated parent, and Restore-GPO can pull any of them back if you need to.
The review window
After the rename, I leave it alone for about 90 days. Long enough to catch monthly and quarterly processes. If something breaks because a renamed GPO was actually doing work, I'll hear about it, and the GPO is still there with its settings intact.
At the 90-day mark, I pull the list of Review - GPOs:
Anything still on that list with no complaints attached gets backed up one more time and deleted. Anything that did get flagged during the window gets renamed back to its original name (or a better one) and properly documented this time.
Why this works
The rename approach gives you a passive audit. You aren't asking anyone to confirm whether a GPO is in use, because nobody will know, and the people who do know are usually gone. You're letting the environment tell you. If nothing breaks for a quarter, the GPO wasn't doing anything that mattered.
It also makes the cleanup defensible. When someone asks why you deleted a GPO six months later, you can point to the rename date, the review window, and the backup. That's a much better conversation than I thought it was dead.
I run this whole workflow about once a year on environments I own. The first run usually catches 20 to 40 dead GPOs in a medium-sized environment. After that it's smaller, but it's never zero. Stuff accumulates.
Tying it back
In my last post I wrote about working inside the structure the company gives you instead of fighting it. This is what that looks like at the keyboard. I'm not pitching a new product to solve GPO sprawl, or asking for budget. I am not building a case for a third-party tool that does the same thing in a prettier UI. I'm using PowerShell, which is already on the box, against AD, which is already running, with a workflow that's reversible at every step.
That's most of the job, honestly. The improvements that actually stick come from understanding what you already own and making it work better. Renaming a dead GPO doesn't make for a great war story, and you won't get a Slack shoutout for it. But the next admin who inherits this environment will be able to read the GPMC console without squinting, and that's worth more than most of the bigger projects I've been asked to pitch.
Work inside the structure. Use the tools you have. Document what you changed. The rest takes care of itself.
I've been doing this work long enough to watch the same pattern play out over and over. An admin gets handed a problem, sees a cleaner way to solve it, and instead of working the problem inside the structure they were hired into, they go around it. Sometimes that means downloading a tool the company hasn't vetted, or it means buying a license on a personal card and expensing it later. Sometimes, in the worst cases I've seen, it means using the helpdesk team as leverage against management or escalating to outside lawyers to force a policy change.
I want to talk about why that approach is wrong most of the time, when it might be right, and what working inside the system actually looks like day to day.
The job, as I understand it
Our role as system admins is to support the company and grow it. That's the whole thing. We aren't here to force the company to our will. We're here to make the tools work, keep the lights on, and give end users a stable place to do their jobs. When we forget that, the work goes sideways fast.
I see new admins get this backward all the time. They come in with strong opinions about how things should be configured, what the right MDM is, which ticketing system is correct, and they start treating disagreement with management as a problem to route around. It isn't. Disagreement is normal. The question is what you do with it.
Making changes inside the structure
Most of the meaningful improvements I've made for end users happened inside Intune, inside Group Policy, inside the existing licensing. Not by bringing in something new.
Example. A few months back the helpdesk was drowning in BitLocker recovery tickets because users were getting prompted after firmware updates and nobody had documented the recovery key location for them. I didn't need a new tool. I needed an Intune configuration profile that pinned the recovery key to a self-service portal the user already had access to, and a one-page doc the helpdesk could send. Ticket volume on that issue dropped by about 80% in two weeks. Management was happy. The helpdesk was happy. I didn't have to fight anyone.
Another one. Printer deployment was a mess. Users were calling in to get drivers installed every time they moved desks. Instead of pitching a third-party print management product (which is what the previous admin had been pushing for, unsuccessfully, for a year), I built out Universal Print through the existing M365 licensing the company already paid for. It wasn't perfect. It had some quirks. But it was inside what we already owned, so the approval conversation was short.
The pattern is the same in both cases. Find the pain point. Look at what you already have. Configure your way out of the problem before you try to buy your way out. When you do have to buy something, you've already shown management you exhaust the existing options first, which makes the next ask credible.
When management gives you a bad instruction
This is the part most admins get wrong, and I've gotten it wrong myself more than once.
Sometimes you get an instruction that's going to cause harm. Maybe it's a policy that's going to flood the helpdesk with tickets they can't resolve, or it's a security setting that's going to lock out a department that needs the access. Maybe it's a rollout timeline that's not survivable.
The wrong move is to weaponize the helpdesk. I've seen admins quietly tell their team to "just follow the policy and let the tickets pile up so management sees the impact." That's using your own people as pawns. They get the angry phone calls, they take the heat, and you get to say I told you so at the next staff meeting. It's cowardly and it damages the team's trust in you, which you can't easily get back.
The right move, in my experience, is to push back through the channels the company gives you.
Bring it to management directly, in writing if you can. Lay out the technical reasoning, the expected impact on the helpdesk, and what you'd recommend instead.
If management chooses to continue, ask whether you can take it up the line. Most companies have an escalation path, even if it's informal. Use it.
If the company doesn't allow further escalation, or the answer comes back the same, then you implement the instruction.
That last step is the one people choke on. But here's the thing. If you've done steps 1 and 2 honestly, and management has made the call with full information, your job is to execute. You don't get to overrule the company because you think you know better. That's not what the role is.
Minimize harm, plan for the recovery
If you do end up implementing something you flagged as harmful, that doesn't mean you implement it dumbly. You minimize the blast radius, phase the rollout and pre-stage your rollback. You write the helpdesk a runbook before the tickets start coming in, not after.
And you have a backup plan ready for when the issue surfaces. Because it will. And when it does, the person who said here's what we tried, here's what happened, here's how we fix it now is in a very different position than the person who said I told you so. The first one gets trusted with bigger problems. The second one gets quietly worked around.
I'm not saying document everything to cover yourself, exactly. I mean, do that too. But the real reason to document the pushback and the plan is so that when the company is ready to course-correct, you're the one ready to drive it.
The line
There's a line, and I want to be clear about where I think it sits.
If you're being asked to do something illegal, something that violates compliance in a way that puts the company or its customers at real risk, something that's clearly unethical, you don't quietly implement it and plan the recovery. You refuse, you document the refusal, and you escalate to legal, compliance, or HR. If those paths don't exist or are compromised, then yes, external options become real. Whistleblowing exists for a reason. So do regulatory bodies.
But that's the extreme case. I've seen admins reach for outside legal action because management wouldn't approve a tool they wanted, or because a coworker got a promotion they thought they deserved. That isn't the line. That's using legal leverage as a weapon to force the company to do what you want, which is the same failure mode as using the helpdesk as pawns, just with bigger stakes.
The line isn't I disagree with this decision. The line is this decision causes harm that the company itself, fully informed, would not sanction. Those are very different bars.
What bad actors look like
I want to flag this because I've watched it happen. There are people in this field who enjoy the leverage the role gives them, and they look for engineers they can use to do harm to a company they're frustrated with. They'll frame sabotage as principled resistance. They'll talk about "making management feel it" or "letting things break so they learn." Finally, they will pitch you on going around the structure because the structure isn't fair.
Some of that frustration is legitimate. Companies do treat IT badly sometimes. Management does make decisions without input that should have been gathered. None of that justifies using your access to cause harm, and none of it justifies pulling your team into a fight they didn't sign up for.
If someone is pushing you in that direction, they aren't an ally. They're a liability, and probably a future legal problem.
The boring conclusion
Most of the time, the job is patient. You configure what you can configure. Ask for what you need to ask for. You document the things you disagreed with so they're available later when the conversation comes back around. You support the company you work for, even on days when you'd rather not.
It isn't dramatic. It doesn't make for good war stories. But over a career, the admins I've watched do this consistently are the ones who end up with the authority to actually change things. The ones who tried to force it usually ended up somewhere else, telling a different story about why their last company didn't appreciate them.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
