Had someone ask me, half joking half not, "can my company see what I'm doing on my phone since IT installed that app on it." And I get why they asked like that, half joking. Because the honest answer is "kind of, but way less than you think, and also maybe way more than you think, depends what else they've bought." Not a great one liner, so lets actually break it down.
What Intune actually sees
Intune by itself is a device management tool, not a surveillance tool, and Microsoft is actually pretty explicit about this in their own privacy documentation. What it collects as standard, required data:
Device details, name, model, manufacturer, OS version
Compliance and enrollment status
App inventory, meaning the name and version of apps installed, not what you did inside them
Admin audit logs, meaning what your IT admin did in the console, not what you did on your device
Theres also optional stuff an admin can turn on if they want, and it has to be turned on, its not default:
Enhanced device inventory, non sensitive hardware details like CPU, disk, and memory info
Device query, for corporate owned Windows devices only, lets an admin query specific file names and file paths on demand
Location, and this one only applies to corporate owned devices, never personal ones, and even then its not constant tracking, its an on demand "locate this device" action, usually used for lost or stolen device scenarios
What Intune flat out never sees
This part is directly from Microsoft's own data collection documentation, not marketing spin. Regardless of what an admin turns on, Intune does not collect or allow an admin to see:
Calling or web browsing history
Personal email
Text messages
Contacts
Passwords to personal accounts
Calendar events
Photos, including your camera roll
On a personal device enrolled with just app protection policies, its even narrower than that, Intune is really only aware of the managed apps and their data, the personal side of the phone stays out of view entirely. Thats the whole point of app protection policies over full device enrollment for BYOD, it draws a line around the work container instead of the whole device.
Where it changes: when Purview or Defender is in the picture
Heres the part people miss. Intune manages the device. It doesnt inspect the content flowing through it. Thats a completely different product, Microsoft Purview, and it only sees anything once a device is separately onboarded into it.
Onboarding happens through Microsoft Purview's device management center, deployed via a script, Group Policy, Configuration Manager, or yes, through Intune as the deployment mechanism. But being Intune managed doesnt automatically mean Purview onboarded, they're separate steps. If a device is already onboarded to Microsoft Defender for Endpoint, it shows up in Purview's managed device list automatically, you just have to turn on device monitoring to activate it for Endpoint DLP.
Onboarding a device into Microsoft Purview is a separate step from Intune enrollment. Source: Microsoft Learn.
Once a device is onboarded and device monitoring is turned on, this is where the visibility actually jumps. Endpoint data loss prevention can see and act on things like:
Copying sensitive content to USB drives
Printing sensitive documents
Uploading sensitive files to cloud apps through the browser
Pasting sensitive content into third party AI sites like ChatGPT through Edge for Business
And critically, once a device is onboarded, information about these audited activities starts flowing into Activity explorer even before an admin configures a single DLP policy. So enrollment into that layer alone increases visibility, before any rule is even written.
Activity explorer showing endpoint DLP events once a device is onboarded. Source: Microsoft Learn.
Stack Insider Risk Management on top of that and it goes further still, correlating signals across a 90 to 120 day window to flag anomalous behavior, like a departing employee suddenly copying a bunch of files somewhere they normally dont touch. Microsoft does pseudonymize users by default in that system and gates it behind role based access and audit logs, so its not a free for all, but its a genuinely different level of visibility than plain Intune.
Turning on device management is what brings telemetry into Purview solutions like Endpoint DLP and Insider Risk Management. Source: Microsoft Learn.
Putting it together
If someone asks "does Intune monitor my activity," the honest answer is Intune alone is closer to a management tool watching device health and app inventory, not a content watcher, and there's a documented list of things it flat out never touches regardless of settings. The real answer changes the moment you ask "what else has my org bought and turned on." Purview's Endpoint DLP and Insider Risk Management are the tools that actually look at content and behavior, and they require their own separate onboarding step, they dont just switch on because a device is Intune enrolled. If you want to know what's actually being watched at your org, the real question isnt "is this device managed," its "what security stack sits on top of Intune, and has anyone turned device monitoring on."
What can we learn as a person
I think the uncertainty is actually the honest part of this. I cant tell someone with total confidence "nobody is watching you" or "everybody is watching you," because it genuinely depends on layers I cant see from where I'm standing, what their org bought, what got turned on, what policy got written last month. And I think thats true of a lot of things in life too, not just IT. We want a clean yes or no answer about whether we're safe, whether we're being judged, whether something's being tracked or held against us, and a lot of the time the honest answer is "it depends on layers you cant fully see either." That uncertainty is uncomfortable, but pretending we have full visibility when we dont is worse, it just delays the discomfort instead of sitting with it.
So where in your life are you assuming a clean answer, safe or not safe, watched or not watched, when the honest truth is you genuinely dont have full visibility into it? What would it look like to just sit in that uncertainty instead of forcing a verdict?
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?
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?
The other day, I was showing a friend how to set up Intune deployments. Then it hit me: I have unique scripts for script detections and things like that here on therandomadmin.com. However, I haven't really gone through the detection rules for built-in items. I was like, well now I have to fix that. So here we are going to fix that with the Intune Detection Rules. Let's get started.
Types of Intune Detection Rules
There are three built-in detection types that we will go over today. They are the MSI, File, and Registry.
MSI is like the easy button, (no not the staples one from the commercials... did I just age myself?)
File is my least favorite one, but it works for legacy apps
Registry is my favorite one and it's the one that I will spend some time on for you all.
Other than the built-in items, there are scripted items which is unique in it's own rights. You can take a look at how these scripts work here. Andrew has a good tutorial on his blog as well. Today will be all about the built-in items.
The Built-In MSI Rule
The MSI rule is the easy button of the detection scripts. If you are using an MSI, it will pull the information directly from the MSI. Once you get to the detection rule part you can follow these steps:
Click Add
Select MSI
And click save
Magic, right? The other thing you can do is select "MSI Product Version Check." Here you can select an operator like "greater than or equal to" and then give it the value. Which is the product version. This helps with auto-updated items. Which I always suggest using. Below is a screenshot.
File Detection Rule
Our next built-in detection rule is for files. This is good if you have an app that doesn't install like normal apps. Older apps or more niche apps are like this. For example. We installed a special Creo app. It installed in the C:\PTC location, and it didn't add itself to the registry uninstall strings. It didn't come in an MSI; it was an EXE with custom everything. This app was a pain in the backstracher. So we used the File location rule. Here is how you can set it up.
Inside your detection rule, click Add.
Rule type: File
Path: The folder that you want to check. In this case it was C:\PTC
File or Folder: Here we wanted to see if the creo.exe existed. So, that's what I put here.
Detection Method: We used file or folder existed.
Greater than or equal to string
As you will learn, I am all about the version numbers. If you select the string (version), you will need to get that version number from the file you are pulling from. You can do this with PowerShell pretty quickly.
Once you have this information, you will then proceed to input it into the value section once you select the string (version) and greater than or equal to options.
Built-In Intune Detection Rule for Registry
The registry key is the most common and the most useful as well. Most apps install themselves in this method. The script below is going to be your best friend. What it does is give you the information you need. Lets break down what each item is so we can look at the script and make this happen. I'm giving this the most focus because it's the most common.
Registry Type: The type we are using.
Key Path: The path of the uninstall string that we will be using
Value Name: What we are looking for, this case we will be looking for displayversion
Detection Method: Version Comparison
Operator: Greater than or equal to
Value: What value we are looking for
Assocated: Is it a 32 or 64.
Script
So you will have to go digging into the registry for this information. However, this registry area is just confussing and really hard to manually dig through. So powershell is once again, our friend.
All you have to do is replace the app name. It will provide you with everything you need inside the built-in detection rule. This is the output that it provides:
RuleType : Registry
KeyPath : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{6EB73F60-E858-3AF3-913A-0C1783656B42}
ValueName : DisplayVersion
DetectionMethod : Version comparison
Operator : Greater than or equal to
Value : 143.0.7499.170
AssociatedWith32 : False
This script really makes finding apps easier. If the app installs in another place, good hunting, my friends.
What we can learn as a person
I am still missing my keys. I have the backup fob for my car, but I have no idea where my normal keys are. So no house key right now. Sometimes, I need to backtrace what I have done to find where I am going. Which is ok. This is why I document so much because I don't have the brain space to remember everything I have done. This is also why this blog post exists. I realized I never once really did explain how to use the built-in tools. Now I have a place to come and get the script I need and anyone else needs. So that will be nice later down the road, and I will thank myself later. Giving myself the little micro successes in the future is what I am going for here. The keys, on the other hand, I didn't set up a space for them to go with the new desk I have. Thus, they are in the ether somewhere, and when I find them, they will go into my little cubby on my new desk. So, set yourself up for micro successes, whether you know it or not, in the future. This will reduce a lot of stress and anxiety in the future. Remember, 80% of life is the systems that you have put into place. So, let's make good systems. Then you can set up your own Intune detection rules for your life to detect when you gave yourself successes. Like, when I see the wallet inside the new cubby. I can give myself a little thanks.
Ever feel like you’re just guessing which Intune policy to use?
You go into Microsoft Intune thinking, “I just want to block copy/paste from Teams to a student’s phone,” and suddenly you're knee-deep in device configs, app restrictions, compliance policies, and something called MAM-WE (which sounds like a failed robot uprising).
If you've ever been stumped by the difference between Intune device vs app policies, you're not alone. And you’re not doing it wrong — the naming is genuinely confusing.
So, let’s break it down the way it actually clicks — using real-world scenarios instead of theory and tech jargon. If you know what you want to do, you'll know what to use. Lets dive into intune devices vs app policies.
The Three Intune Policy Buckets
Device Configuration Policies – You Own It, You Control It
Think of this like setting the house rules — but only for houses you own.
Device configuration policies give you OS-level control. You can push BitLocker, set PIN rules, enforce Delivery Optimization, apply VPN profiles, and more. But they only work if the device is enrolled in Intune — like, actually enrolled. Not “kinda managed.” Full enrollment.
Lets take a look at a real world senerio. Imagine you have 200 windows 11 laptops and want to enable delivery optimization for windows updates. This would be a Device Configuration Profile. Another example would be if you have 1000 windows 11 laptops that you want to encrypt their fixed drive with bit-locker. Once again, this is another device configuration profile.
If the deivce is apersonal and not enrolled, this policy type is off-limits. No Bitlocker, no VPN, nothing. You don't own it, you don't get a say.
App Protection Policies – Protecting the Data, Not the Device
This one is magic for BYOD situations. Think of it like zipping up your company's data in a fireproff pouch, even if it'son someone else's device. App protection polcies don't care who owns the device. They care about your data. These policies apply to managed apps. Things like outlook, teams, onedrive, and lets you do things like bloc copy and paste. Require PINs to open apps, wipe work data and more.
Lets take a look at a few real world senerios. Students are copying teams messagers and pasting them into discord on their phones. You can block this using App Protection Policy. Lets say you have truck drivers with ipads with outlook on them. You can force the user to enter a pin each time they check their email. That's a App Protection Policy.
App Configuration Policies – Pre-setting the Knobs
Here we are putting the settings into place for different apps. We are not locking down the device. So, if you need a pin for the device, you do this with a device configuration policy. If you need chrome to open on a set website, that's the App Configuration Policy. App configuratin policies let you predefine how apps behave. It's not about control, but it's about consistency. You can push bookmarks, force outlook to use only work accounts, set default browsers for teams, and more.
Lets look at a real world. You have 500 Android Zebra scanners, you need to make sure they all open chrome to a local site. This can be done through the App Configuration Policy. One thing we did for was setup auto updates with zebra on our scanners. We did this with a App configuration profile.
The problem with it is the BYOD. App Configuration policies only work with managed apps. This means, if a user installs outlook through the company portal via intune, then you can manage it. However, if you install outlook through the store app, it just doesn't work.
Why it gets confussing
Let's be real, the names don't help. "App Protection" and "App Configuration" sound way to similar. So here's a simple mental hack to seperating devices vs app policies.
Device Configuration = Control the device itself.
App Configuration = Setup how the app works.
App Protection = Lock down the data inside the app.
Lets test this thinking out with a few senerios.
Possible Answers
Device Configuration Policy
App Configuration Policy
App Protection Policy
You want to prevent employees from copying data from teams to another non-company app.
Your factory has 300 kiosk devices. You want to make sure that the devices can't be logged into by non-it users.
Doctors are using outlook on their personal phones. You need to prevent attachments from being saved locally.
Your compamy users Android enterprise, and you want to push bookmarks to chrome.
You want to rotate the local admin password on all of your windows 11 devices using windows LAPS
Force outlook to only use work accounts
Encrypt phones and force a pin lock on bring your own devices.
Here is a nice little chart to help with these.
Do I manage the entire device?
↳ Yes ➡ Device Configuration
↳ No ➡ Do I want to protect corporate data?
↳ Yes ➡ App Protection
↳ No ➡ Do I want to change how the app behaves?
↳ Yes ➡ App Configuration
Here are the answers.
App Protection
Device Configuration
App Protection
App Configuration
Device Configuration
App Configuration
None of the above, Yep, I tricked you, maybe. If it wasn't a bring your own device, then you would be correct if you say device configruation profiles. Other than that, it's nothing really.
Final Thoughts – “You Know More Than You Think”
This stuff is confusing, and Microsoft doesn’t always make it easy. But now, you’ve got the mental framework:
Device Config = You own the device
App Protection = You own the data
App Config = You shape the experience
Don’t worry about getting it perfect on the first try. Intune is meant to be layered. Pilot first, then scale.
If you ever get stuck again, just ask: “What exactly am I trying to control here?” The answer will almost always tell you the policy you need.
You’ve got this, lets get those devices vs app policies.
What can we learn as a person
In IT, we have access to a lot. More than most people will ever know.
We can shut down Windows Hello, enforce biometric logins, or require ID badges scanned by a camera just to unlock a screen. As system administrators, we often hold keys to every digital door. I could, right now, grant myself full access to every mailbox in the company — all in the name of “making admin easier.” I could quietly assign myself as an owner on every user’s OneDrive and SharePoint site using policies that no one would even notice.
That level of control? It’s terrifying, if you’re honest about it.
Because with great power doesn’t just come great responsibility. It comes with weight. A psychological and emotional load that most people never talk about.
Knowing that you can access someone’s private data — and choosing not to — becomes a moral and mental burden. It sits on your nervous system like a background process you can’t kill. Over time, that mental load becomes stress. That stress becomes anxiety. That anxiety becomes burnout, or worse — panic attacks that don’t go away.
Let’s go back to those access examples:
If you make yourself owner of every mailbox, and something illegal ends up in one — say, child pornography in OneDrive — you’re now not just an admin. You’re a co-owner of that content. You’re legally implicated. That’s not just a technical decision. That’s jail time.
When you hold that kind of access, your body knows, even if your conscious mind tries to ignore it. It keeps a tally. And that tally eventually tips the scale — panic attacks, heart strain, and real, physical damage.
The Illusion of Total Control
I’ve seen brilliant people collapse under the pressure of trying to control everything — juggling complex networks, hybrid systems, countless endpoints, compliance rules, and impossible expectations.
They thought the job was about mastery. But really, it’s about boundaries.
Technology is growing faster than any one human can keep up with. We’re now expected to specialize and generalize. To know cloud, on-prem, security, devices, data — and also keep every system running 24/7 with no mistakes.
That pressure? It breaks people.
So What Can We Learn?
Here’s what I’ve learned — sometimes the hard way:
Control less. Not because you’re lazy — but because your health matters more than a perfect config.
Set boundaries. Just because you can access something doesn’t mean you should.
Say no to full access. Delegate. Distribute. Limit yourself.
Audit yourself. Regularly review what you have access to, and ask: Do I really need this?
Let go. Systems don’t have to be perfect. People don’t have to be flawless. Neither do you.
You’re not here to own everything. You’re here to protect what matters — and that includes you.
So the next time you feel the urge to control every setting, script every failover, and be the hero of the whole system… Pause. Breathe. And remember: the best admins don’t control everything. They know what not to control — and they sleep better because of it.
For the past few months, I have been working with zebra scanners. MC9300 and MC9400 to be more excat. These scanners are unique in the fact that they do not have any cameras. These scanners are Android OS devices. That means they can go into intune without to many issues. Normally, you scan a QR code with your camera and then it takes you to Google Play. However, there is no camera and no app store on these scanners by default. The idea with these units is you use a program called stagenow and have stagenow enroll them into Intune. So, how do you do that? The Zebra documentation is nice, but it has some issues. Enrolling Zebra Scanners into Intune is not for the faint of heart.
So, why? Why not use other MDMs. Good question. I like punishment, maybe? In this case, this is the option management wanted. Thus, I followed orders and made it happen. There are some things you will need before we get started.
Admin access to your Intune with the proper licensing. If you have E5 licenses and a P2 plan, you should be golden.
A wireless network that has access to the stage now computer and to the interent. At this stagenow computer will be running an FTP service.
Creating the Enrollment
Before we start our first steps, we want to create a Kisok scanner device. This will have one or two apps on it. Thats' important to think about. We can create a large number of deployment types, and not all of them fit with our goals. These devices will be used to scan boxes and nothing else. So we will be using corporate-owned dedicated devices. The first step is to create the enrollment in Intune.
Description: This policy is to enroll zebra devices into corporate-owned dedicated devices
Token Type: Corporate-Owned Dedicated devices
Token expiration data: Input a reasonable date
Click Next
Click Create
We will be taken to the policy screen. From here, we need to go into our new policy. Here we will see all the information you just put in. Now we need to get that token.
Click on the policy
Manage > Token > Show Token
Using your cell phone and a QR app, scan the QR to gather its information.
I have a Samsung phone. I just use the scan QR code feature. Then select the show text.
Inside this text, you will see a variety of links and something called "Extra_Enrollment_Token" You will need the string of numbers that follows this. You will also see a CHECKSUM, you will need this hash. Finally, you will see something called Provisioning_Device_Admin_Package_Download_Location followed by a link. Click this link. It will download an APK. This APK is very import and cannot be renamed. You will want to transfer this app to your stage now machine.
Stage Now Setup
Now that we have created the enrollment, downloaded our app and gotten our token, it's time to make the stage now profile. The stage now profile is going to consist of the following configurations.
Stager now Network
Wifi
FileMgr
AppMgr
Intent
Start your stage now application and log into the admin portal. You will need the average MX version of your zebra scanners. On average, I have seen a range from 8.4 all the way to 13.1 in my environment. Thus, we must select our lowest version. In my case, it will be 8.4. I will post a blog post in the future on how to standardize our MX versions with Intune.
Click Create New Profile
Click Xpert Mode
Name the policy. I like to have the mx version in the name and what it's doing. So for our example, I used "Enroll_Intune_8.4" Notice, no spaces.
Now we are sent to the add/edit window. Click Wizard.
Scroll down until you see the "StageNow Network" and click the plus sign. You will notice that it is added to the right-hand menu.
Click the settings tab
Add Wifi, Filemgr, AppMgr and Intent
Click ok
Now we will start creating the profile itself. We are thrilled with the first item in our list, "stageNow Network.". Here we will have drop-downs and other options. So follow along.
Connect a network
Drop Down: The devices I wish to provision are currently not connected to a network. I will define a network with this profile that can be used for staging.
Click Continue
Network Type > Drop Down: WiFi
Certificate Management: No
Please note that if your network uses a cert, you will need to set it up here.
Disconnect Networks: No
We select No because the next section disconnects the networks for us.
Disalbe Network: Yes
This will disconnect from all of the other networks
Click Continue
Add Network: Yes
SSID: Your SSID
Security Mode: Personal
In this example, we are going to use a basic wifi setup with a password.
WPA Mode: WPA/WPA2
Encryption Type: Do not change
We don't change because by default it is aes-ccmp/tkip
Key Type: Passphrase
Protected Key: Checked
Passphrase: <Enter your passphrase>
Use DHCP: Check
Keep everything else as default.
Click continue.
Connect Network: Confirm everything here and click continue
Wifi
After you click the continue button, you are brought to review. Let's click the StageNow Config button at the top. To get back into the configuration window. This is the network we will use for Enrolling Zebra Scanners into Intune. We are doing this here to change some basic settings. Like, is the wifi enabled? Is there a sleep policy? Stuff like that. We want to make sure we can get as much possible out of the way now before we deal with it later.
Target OS: Android
Wi-Fi Enable: Enabled
Sleep Policy: Never Sleep
Network Notification: Use Network Notifications
Enable Wi-Fi Verbose Logging: Do not change
If you want this feature, you can set it; however, it eats resources on the scanner.
Configure Country: Check
Country: USA
Notes: By leaving it unchecked, it will perform an auto setup. This can be a problem if you have scanners around the world.
RF Band: Unchanged
This is something you will need to communicate with your network team. Some places use 2.4, some use 5. You can tell it which channels to work with as well. This is a very advanced system for the most part.
Leave all the other settings the way they are.
The network action is do nothing because you are already connected to your staging network from the previous set.
FileMGR
The file manager area is import for us our Enrolling Zebra Scanners into Intune as it allows us to get the intune onto the device itself. After we click continue on the wifi, we will come into the new settings.
File Actions: Transfer/Copy File
Target Access Method: File in the device file system
Target Path and File Name: /sdcard/AndroidDevicePolicy.apk
Source Access Method: File on a remote server
Source File URL:
Click the three dots
Search for the file and add it.
Continue
AppMGR
Now the app is on the scanner from the stage now profile, it's time to install the app. We are going to select upgrade as upgrade is install and upgrade at the same time.
Action: Upgrade
APK Path and Name: /sdcard/AndroidDSevicePolicy.apk
Protected list action: Do nothing
Here you can add this app to the protected list, thus making it unchangeable. This could cause Intune to fail. You can also remove it from said list.
Access to app information action: Do nothing
Click Continue
Intent
This final stage joins it to intune. We will be creating a json file before we continue. Remember that code we got from the qr code. This is where we are going to be using it. This json is our butter for Enrolling Zebra Scanners into Intune. Here is the json.
{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "<Oh a has code from ealier.> ",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":"https://play.google.com/managed/downloadManagingApp?identifier=setup",
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": true,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"<YourTokenYall>"}
}
Remember we grabbed the check sum and the token from before? Well, this is where we are going to use it. Replace where I have the <> and you should be good to go with the file. Make sure to save this in the same folder on the stagenow computer as the app from before and save the file as a.json file.
Class Name: com.google.android.apps.work.clouddpc.receivers.CloudDeviceAdminReceiver
Json Value: Json File
Json File:
Click the three dots and navigate to your newly created json file.
Click continue
Final steps of stage now
Once you click the stage now button, you will be set to the review screen. Here you can make sure all of your settings are correct by clicking the expand button. By default, the bar codes are encrypted. If you don't want that, this is where you can change it. I always suggest encryption. Once you have everything the way you want, all you have to do is click complete profile.
Now here is the next important aspect of the whole setup. Creating the barcodes to scan. After you click the Complete Profile, you will be taken to the bar code window. There will be options for linear and PDF417 barcodes. The linear is going to give you a lot of bar codes. So pick the PDF417.
CATCH! Android 11 and down use PDF417, for Android 13 and above, use JS PDF417.
So we want to click the StageNow client check for what we want to use. Then I like to test. You can click the test to generate the barcodes. Finally, you can click publish to publish the profile.
Using the barcodes
Once you have the bar codes, Enrolling Zebra Scanners into Intune is so much easier. From a recently wiped scanner, open stage now and scan the bar codes. The scanner will connect to your wifi of choice. Then, if the stage is now up and running, it will download the file. Then it will install the app. Finally, if the network is running correctly, it will join intune. From there, intune takes over and stage now is no longer needed.
Import gotchas at this stage is stagenow has to be active with this setup. The reason is because each time the application is active, it spins up an FTP. The FTP username and password are embedded into the QR code from where you encrypted it. So, if your network can't reach this server, this means it will not work as well. So make sure the network team is good to go.
What can we learn as a person?
Things don’t always go as planned, no matter how much we prepare. I spent six months perfecting an MDM transition while managing my regular duties. My Intune setup was nearly flawless: scanners were configured in under 30 minutes, upgraded to the optimal OS for our company (not Android 13), and everything seemed ready. I created detailed instructions and videos for end users, tested the process with multiple people, and received praise for how well it worked.
The rollout began smoothly at our northern office, where everything connected as expected. Then things unraveled. At other locations, wireless networks failed due to improperly configured DHCP, incomplete AP broadcasting, poisoned ARP tables on switches, and more. It felt like every fix led to another failure. Users blamed me since I handled the transition, but the root issue was network-related—something I had no access to or control over.
Despite my setup being perfect, it failed because of factors outside my control. And that’s okay. Failure doesn’t define us, even when others assign blame. IT is a team effort, and sometimes you must navigate challenges with colleagues who may not be as invested or responsive.
In this case, waiting for the network admin to confirm readiness and documenting everything (CYA!) saved me. It’s a reminder that our worth isn’t tied to mistakes—ours or others'. Sometimes, patience and accountability are the real wins.
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.
