Foundations of Modern Device Management
Before we touch the Intune portal and start clicking buttons, you need to understand why device management exists, how it evolved, and what the important terms mean. Once this foundation is strong, everything in the practical classes will make complete sense.
Why Every Company Needs Device Management
Whatever we are trying to do in this whole course, we are trying to do only one thing: manage devices. That mainly means Windows devices in this course, but the same idea applies to laptops, desktops, Android, iOS, Mac, and to some extent Linux.
From an employee’s point of view, a device is what lets them perform their day-to-day tasks and contribute to the business. Work has moved almost entirely from paperwork to device work, everything is digital, everything is modernized.
But using a device for organizational work needs security. If someone hacks the device, or malware executes on it, anyone can steal the data, or encrypt it and demand payment to decrypt it, as in a ransomware attack, sometimes shutting a company down even after the ransom is paid.
From a company’s point of view, hardware like a laptop is just money, and money is replaceable. But data is important. The laptop is not important, the device is not important, the data on it is important. This one idea is the reason device management exists at all.
So the question becomes: how do we manage a device and protect the data on it? There are two types of management, covered next.
- Device management exists to protect company data, not just the device hardware.
On-Premises vs Cloud Management
On-premises infrastructure
On-premises means your own server, your own infrastructure, your own land, your entire setup purchased and owned by you, hosted in your own data center. To manage on-premises devices, you use an on-premises management server.
Think of buying a house. Option one: search for land, purchase it, build the house, implement security, a process that takes 6 to 10 months, plus recurring maintenance cost forever after. That’s on-premises management.
Option two: purchase or rent a flat in an already-built apartment. No infrastructure to develop, it’s pre-configured, you just pay and move in. That’s cloud-based management.
A short history: SMS to SCCM to the cloud
Microsoft’s on-premises device management tool went through versions: SMS (Systems Management Server) 1.0, 1.2, then 2.0, the old version of what we now call SCCM (System Center Configuration Manager). Through SCCM, everything had to be established in your on-premises environment, and you could only manage a device that was joined to and part of your own environment.
You cannot manage a device which is not joined to your own on-premises domain. This is where domain join becomes important, covered next.
As the market moved toward cloud, MDM (Mobile Device Management) tools started appearing, and Microsoft eventually introduced its own cloud-based tool, originally called Windows Intune.
Windows Intune was the first name Microsoft officially used for cloud device management. With it, you could deploy applications, patches, configuration profiles, and antivirus policies. It slowly expanded beyond Windows to mobile devices too, especially important during COVID, when deploying VPN and managing devices remotely via on-premises setups was slow and error-prone, while cloud-based management was faster and easier.
| Aspect | On-Premises Management | Cloud-Based Management |
|---|---|---|
| Setup time | Long (like building a house, 6-10 months) | Fast (like moving into a ready flat) |
| Infrastructure | You build and own it | Already built, you just consume it |
| Device reach | Only devices joined to your own domain | Devices anywhere, as long as they reach the internet |
| Example tool | SMS, SCCM | Windows Intune, Microsoft Intune |
- Device management exists to protect company data, not just the device hardware.
- On-premises management is like building your own house; cloud management is like moving into a ready apartment.
- Microsoft’s journey went from SMS, to SCCM, to Windows Intune, and eventually to Microsoft Intune.
Domain Join, Local Admin, and LAPS
What is domain join?
When a machine is domain joined, it is enrolled into your company’s domain (e.g. xyz.com). A domain-joined machine has a special characteristic: you cannot log in with just any ID, you need a domain user ID from your on-premises Active Directory.
Standard user vs local administrator
- Standard user: limited privileges; cannot freely modify system settings, only what’s explicitly allowed.
- Local administrator: complete control of the system; can modify anything, install/uninstall applications, change any setting.
You can create a local admin account two ways: through Control Panel > Users and Accounts, or through the Local Users and Groups console.
This opens the Local Users and Groups console, where you can view users and add a computer or group. On a domain-joined machine you can also add a domain group, any member of that group effectively becomes a local administrator on the device.
Intune also has an option to configure which user or group is automatically added as a local administrator on a device by default, covered in the practical classes.
LAPS: Local Administrator Password Solution
Imagine a company with 1 lakh (100,000) devices, traditionally using one shared local admin password across a big batch, say 2,500 machines at a time. If even one person knows that password, they can log in to all 2,500 machines sharing it.
If a local admin password is shared across many devices and becomes known even once, an attacker, or a careless employee, could potentially log in to thousands of machines with that same password.
The password needs to be rotatable, changing automatically on a defined schedule. That’s what LAPS gives you, available in Intune (and Entra ID). You create a policy defining how many days (X) before the local admin password rotates automatically. Even if X = 30 and the password is consumed early, it rotates again on the next restart, since the system knows it’s already been used once.
Where do I find the LAPS password?
The current password is stored securely in the Intune portal, and is also visible from the Entra portal. You view it, use it to log in, and the machine automatically rotates the password again afterward, or you can manually trigger a rotation.
Even with LAPS, you still need a local administrator account for certain activities (e.g. an internal reformat process), the process is the same, just the password is now safely managed and rotated. Some organizations instead add a dedicated IT admin account to the local admin group for day-to-day troubleshooting, avoiding the need for the LAPS password every time. Both approaches exist in the real world.
Why is a single shared local admin password across thousands of machines risky?
- Domain join means a machine is enrolled into your on-premises Active Directory domain.
- Standard users have limited rights; local administrators have full control of the device.
- LAPS automatically rotates local admin passwords on a schedule, so no single shared password stays valid across thousands of machines.
- The current LAPS password can be viewed from the Intune portal or the Entra portal.
Authentication vs Authorization
Whenever you log in to a managed machine and see a Microsoft login popup for an admin activity or company email, two terms come into play: authentication and authorization. They sound similar but mean very different things, and it’s a very common interview question.
Authentication is the process of proving who you are, using a password, a PIN, or biometrics. Correct credentials, you’re authenticated; wrong credentials, you’re denied.
Authorization is checking whether you have sufficient rights or privileges to perform a particular action, after you’ve already been authenticated.
For example, once authenticated, the system still checks whether you have enough rights to configure a particular setting. A local admin group member with the required rights can configure it; someone without full rights cannot, even though they’re already logged in.
- Authentication = proving who you are (password, PIN, biometrics).
- Authorization = checking what you are allowed to do, once already logged in.
From Windows Intune to Microsoft Intune: A Short History
- SMS (1.0, 1.2, 2.0): the earliest on-premises tool from Microsoft.
- SCCM (System Center Configuration Manager): the mature on-premises tool after SMS, used for application deployment, update management (Windows, Office, Defender), and OS management, all within your own environment.
- Windows Intune: Microsoft’s first cloud-based device management offering, giving similar capabilities from the cloud.
- Later integrated with Azure AD, today called Entra ID.
- Eventually unified under the name Microsoft Intune, alongside a broader umbrella called Unified Endpoint Management, combining Intune and Configuration Manager together.
Intune by itself cannot manage servers. Its strength is Windows client management, security policies, and role-based access control for client devices, not on-premises servers.
- SMS came before SCCM, and SCCM was the mature on-premises tool.
- Windows Intune was Microsoft’s first cloud device management tool, which evolved into today’s Microsoft Intune.
- Intune manages client devices, not servers.
Entra ID and the Importance of Groups
What is Entra ID?
Earlier called Azure AD (Azure being Microsoft’s cloud platform), this is now referred to as Entra ID everywhere in the Microsoft cloud world, identity, groups, devices, or conditional access.
Entra ID is a directory service, similar in spirit to on-premises Active Directory but in the cloud, used to manage users, computers, groups, and more, acting as a single source of truth for identity in your organization.
Why do we always need a group?
Can we deploy an application in Intune without creating a group? No. You cannot deploy anything, application, policy, or patching, without targeting a group, even for a single device or user.
Think of a WhatsApp group. To reach everyone, you first create the group, then post the message into it. Intune deployments work the same way: create the group, then target your app or policy to it.
Static groups vs dynamic groups
- Static group: members added manually, one by one.
- Dynamic group: a condition (rule) is defined, and any user or device matching it is automatically added, e.g. “anyone in the India region.”
Without an Entra ID P1 or P2 license, you can only create static groups. A dynamic group’s membership rule simply will not activate without the right license.
- Entra ID is Microsoft’s cloud directory service, earlier known as Azure AD.
- You cannot deploy anything in Intune without a group, even for a single device or user.
- Static groups are manually managed; dynamic groups auto-populate based on a rule, but need Entra P1 or P2 licensing.
MDM vs MAM: Managing Devices vs Managing Apps
MDM (Mobile Device Management) means controlling the whole device, everything installed on it, its patching, compliance, and configuration.
MAM (Mobile Application Management) means configuring and maintaining specific applications only, not the whole device, no responsibility for device-level compliance or patching.
This distinction matters most for devices not fully owned by the company, e.g. an employee’s personal mobile or laptop used for corporate mail, Outlook, or Teams. Rather than manage the entire personal device, a separate secure container (a work profile) is created, and only what’s inside it is managed.
If an employee leaves, or the device needs de-provisioning, the work profile container is simply wiped, removing only company data and managed apps, not the personal side of the device.
App Protection Policy
Suppose a company computer also opens WhatsApp Web or a personal browsing site. If confidential company data is copied and pasted into it, the company doesn’t want that. App Protection Policy prevents cut, copy, paste, print, or save to an unauthorized location, and can even disable screenshots within a managed application.
Device ownership models
- Personal device with a work profile (BYOD style): device belongs to the employee; a separate managed container holds work apps and data.
- COBO / COPE (company owned, business use / company owned, personally enabled): fully company-owned, with some personal use sometimes allowed.
- Dedicated device / kiosk mode (single app mode): locked into running one specific application, e.g. a device given to a delivery employee.
| Under MDM | Under MAM |
|---|---|
| Device compliance and configuration | Application access restrictions only |
| Windows Update, Office Update, Defender Update | Cut, copy, paste, print, save restrictions inside the app |
| Wallpaper, power management, battery management | Screenshot restriction within managed apps |
| Wi-Fi, Bluetooth, USB enable or disable | – |
| BitLocker enablement, DLP enforcement | – |
| Factory reset lock, system settings | – |
A policy deployed under MAM scope cannot do device-level activities such as BitLocker enablement or Wi-Fi restriction, that’s outside application management. Device-level control needs MDM scope.
WIP: Windows Information Protection
WIP is Microsoft’s way of doing MAM-style protection specifically for Windows devices and applications, similar in spirit to App Protection Policy for mobile.
MDM today already contains most of what WIP used to provide separately. Intune still lets you decide whether to configure it as MDM, WIP, or both, enabling both generally has no negative impact, since MDM’s capabilities already cover WIP’s.
An employee’s personal phone accesses company email. Which approach is normally used?
- MDM manages the whole device; MAM manages only specific applications.
- App Protection Policy prevents cut, copy, paste, print, save, and screenshot actions in managed apps.
- A “work profile” is the secure container created on a personal (BYOD) device for company apps and data.
- WIP is the Windows-specific version of application-level data protection.
Setting Up Automatic Enrollment in the Intune Portal
You can reach the Intune portal directly at intune.microsoft.com, or via the short link aka.ms/intune, both launch the same portal.
Under device enrollment, the first option is Automatic Enrollment, where you define whether a device is under MDM scope, WIP scope, or both.
Understanding MDM user scope
- 1
None
No one is allowed to enroll their device automatically in Intune.
- 2
All
Every user in the tenant is allowed to enroll their device automatically.
- 3
Some
Only users belonging to a specific group you define can enroll. Useful when, say, you have 10,000 users but only 5,000 Intune licenses, you scope enrollment to a group containing only the licensed users.
“I’m trying to set the user scope, but I don’t get the option at all.” Usually a missing license, setting scope to “Some” with a group requires an Entra ID P1 license. Without it, and logged in only as an Intune admin (not Global Administrator), the option appears greyed out / read-only.
Configuring this properly needs proper admin rights, such as Global Administrator or an equivalent role, a plain Intune admin role alone is not always enough, especially with the Entra P1/P2 licensing gate involved.
The same setting is also available in the Entra portal
- 1
Open the Entra portal
From the nine-dot app launcher (top left of any Microsoft 365 portal), navigate to the Entra portal, the Office 365 portal, or the Defender portal if managing Defender.
- 2
Search for Mobility
In the Entra portal search box, type “mobility” (or just “MOB”) to find “Mobility (MDM and WIP).”
- 3
Confirm it’s the same setting
You’ll see the exact same look and feel as Intune’s Automatic Enrollment page, since Intune is essentially an MDM solution registered under Entra ID.
From the Entra portal, you can also register other, third-party MDM solutions (e.g. ManageEngine) alongside Microsoft Intune, which shows up as an MDM solution by default.
How to check which license you have
- 1
Go to a user in Entra ID
Select any licensed user in your tenant, e.g. your own account.
- 2
Open Licenses
On that user’s profile, find and click the “Licenses” option.
- 3
Look for Entra P1 or P2
See the individual services bundled inside the license. An E5 license bundles both P1 and P2; an E3 license typically bundles only P1.
- Automatic Enrollment has an MDM user scope and a MAM user scope, each with None, Some, or All options.
- Setting scope to “Some” needs a target group, and Entra P1 or P2 licensing.
- The same MDM/WIP settings can be viewed and configured from the Entra portal under Mobility (MDM and WIP).
- Check your license and included services from a user’s Licenses page in Entra ID.
How a Device Actually Gets Enrolled
The process always starts in Entra, not directly in Intune.
- 1
Device joins or registers in Entra ID
Similar in spirit to how a machine used to join an on-premises Active Directory domain, just now it happens in the cloud, using the same username-and-password concept.
- 2
Automatic enrollment kicks in
If Automatic Enrollment is properly configured, the user doesn’t need to manually enroll or re-enter credentials. Without it, the user enters credentials twice, once for join/register and once for Intune enrollment, which is a poor experience.
- 3
Device becomes managed by Intune
Once Entra joined/registered and the automatic enrollment conditions are met, the device becomes enrolled and managed in Intune with no extra manual steps.
1. The user must have a valid Intune license assigned.
2. The user must be part of the group targeted under the “Some” MDM user scope setting, or the scope must be set to “All.”
This one flow, Entra join/register plus automatic enrollment enabled, is the backbone of roughly 90-95% of Intune enrollment scenarios in real environments.
Both are ways a device establishes an identity in Entra ID. The exact technical difference between device register and device join is covered in the practical sessions, with a hands-on demonstration.
- A device first joins or registers in Entra ID, then automatic enrollment brings it into Intune management.
- Automatic enrollment saves the user from entering credentials twice.
- Two conditions are required: a valid Intune license, and coverage under the MDM user scope (Some or All).
Co-Management: Bridging SCCM and Intune
Many companies already have a mature SCCM (on-premises) setup and can’t switch it off overnight to move fully to Intune. For such companies, Microsoft introduced co-management.
Imagine a house with two owners, both allowed to manage it, dividing the work between them. Co-management works the same way: the same machine is managed by two management servers at once, SCCM and Intune, with responsibilities (“workloads”) divided between them.
A workload is a category of management responsibility, applications, compliance policies, configuration items, Windows Update policies, and so on. In co-management, you decide, workload by workload, whether SCCM or Intune is the “authority” for that responsibility.
How the migration typically happens
- 1
Start fully on SCCM
Before co-management, all machines are managed only by SCCM, the earlier established on-premises tool.
- 2
Enable co-management
Both SCCM and Intune now co-manage the same machines. Initially, SCCM remains primary for most workloads.
- 3
Pilot a few workloads on Intune
Move a small number of workloads for a small pilot group (say 7-10 machines) to Intune, purely for testing.
- 4
Validate
Check Intune delivers these services correctly without depending on SCCM, building confidence.
- 5
Shift workloads gradually
Shift each workload from SCCM to Intune stage by stage, with testing and client approval at every stage.
- 6
Complete the migration
Once everything works from Intune, either disable co-management or remove the SCCM agent from all machines.
Real production migrations of this kind typically take around 3 to 6 months, depending on company size, device count, and complexity.
Co-management is when the same machine is managed by two Microsoft products together, SCCM and Intune, dividing workloads between them.
Co-existence is when the same machine is managed by an MDM solution together with a third-party (non-Microsoft) MDM solution.
- Co-management lets SCCM and Intune manage the same machine together, dividing responsibilities called workloads.
- Migration usually happens gradually: pilot a few workloads, validate, then shift more over time.
- Co-management is specifically SCCM plus Intune (both Microsoft); a third-party MDM tool instead makes it co-existence.
Windows Autopilot: Zero-Touch Deployment
The traditional way of deploying a new laptop
Traditionally, a new blank laptop from a vendor like Dell needed the OS installed step by step, with everything configured manually, Windows activation, application installation, and so on. This traditional method is called Operating System Deployment (OSD), done using SCCM combined with MDT (Microsoft Deployment Toolkit) or WDS (Windows Deployment Service).
Companies typically built a customized “reference image” with the latest drivers, required applications, company settings, and security hardening, rolled out via a “task sequence.” Building this kind of image typically took one to two months, and deploying it still needed a good amount of manual IT effort.
What is Windows Autopilot?
Windows Autopilot is the modern way of deploying corporate Windows devices, building the Windows configuration automatically, without IT manually imaging the device, and without the user needing deep technical steps.
| Traditional way | Autopilot way |
|---|---|
| Laptop goes to IT first; everything installed and configured manually before handover | Vendor ships directly to the user; unbox, connect to Wi-Fi, sign in, the device configures itself within a couple of hours |
The Autopilot flow is often called the “out-of-the-box experience.”
Why Autopilot became so important: the COVID example
Before COVID, some companies had considered Autopilot but hadn’t invested seriously in it, since the traditional method still worked for office-based employees. When COVID happened, movement was suddenly restricted, and employers needed a way for employees to receive a fully ready, fully configured laptop directly at home. Companies that had already implemented Autopilot handled this smoothly: vendors shipped laptops with a basic OS directly to employees’ homes, and Autopilot took care of the rest.
Companies that had sidelined this technology earlier suddenly pushed hard to adopt Autopilot once COVID hit, because it solved a very real, urgent business problem: getting employees productive without any physical handling of the device by IT.
- Traditional OSD (SCCM + MDT/WDS) needs a custom reference image, which can take one to two months to build.
- Windows Autopilot removes the need for IT to manually image a device, the device configures itself once the user logs in.
- Autopilot became extremely important during COVID, enabling fully remote, zero-touch device deployment.
Endpoint Analytics: Measuring User Experience
Imagine a new user joins the company; everyone in the same department gets the same laptop model, configured the same way. A year later, the user restarts and logs in, some time passes from restart to a usable desktop.
If login-to-desktop time is 3 extra minutes longer than it should be, it might feel small. But multiply 3 minutes by how many times a user restarts per month, by 12 months, by the total number of devices (say 10,000-30,000), and convert that lost time into money using an average IT/employee cost per hour. Small, individual inefficiencies add up to a large loss at scale.
This is exactly what Endpoint Analytics is built to catch. It automatically monitors:
- Startup and boot performance, highlighting which step is taking unusually long or failing
- Application crashes (e.g. Teams crashing repeatedly)
- Battery health and related issues, since abnormal battery drain can sometimes affect hardware over time
- Overall resource usage and device health trends across the organization
DEX stands for Digital Employee Experience. Many organizations run a dedicated DEX team using tools that monitor CPU utilization, memory usage, reboot requirements, and running processes, alerting the help desk proactively, often before the user complains. Endpoint Analytics inside Intune serves a similar purpose.
- Small, repeated inefficiencies like slow startup times add up to large productivity and monetary losses at scale.
- Endpoint Analytics helps spot startup performance issues, app crashes, and battery health problems proactively.
- DEX (Digital Employee Experience) is the broader industry term for this kind of user experience monitoring.
Microsoft Intune Suite, Licensing, and Copilot
Unified Endpoint Management
This term describes the combination of Intune plus Configuration Manager (SCCM) capabilities together. Intune on its own manages client Windows devices, mobile devices, security settings, and role-based access control, not on-premises servers.
Microsoft Intune Suite: E3 vs E5
Microsoft bundles Intune capabilities differently depending on whether your organization has E3 or E5. Generally, E5 unlocks a richer set of built-in Intune features than E3. Some advanced capabilities exist as separate paid add-ons under the Microsoft Intune Suite, for organizations wanting more than what’s bundled in E3 or E5.
Approximate price figures were mentioned in class for context, but exact licensing prices change frequently and vary by region and agreement type. Always check Microsoft’s official licensing page rather than numbers mentioned verbally in a class.
Remote Help
Microsoft’s own inbuilt tool for remotely connecting to and troubleshooting a user’s device, similar in purpose to third-party tools like TeamViewer or LogMeIn. Since it’s already built into Intune, many organizations with the right license tier move away from external remote tools in favor of it.
Endpoint Privilege Management (EPM)
Lets you give a standard user temporary elevated (admin-like) rights for a specific action, without permanently making them a local administrator, a much safer way of handling occasional admin-level tasks.
Copilot in Intune
An AI-driven assistant inside Intune. You type your question in natural language, and Copilot reads it and returns the relevant data or insight from your Intune environment, instead of manually digging through multiple reports.
Copilot in Intune is not a simple flat monthly fee per user, it works on a consumption-based model using “compute units.” You’re charged based on actual usage, not a fixed monthly amount. Without understanding this, a company can be surprised by costs after a month of heavy usage, since more queries and processing simply consume more compute units.
- Intune plus Configuration Manager together are referred to as Unified Endpoint Management.
- E5 licensing generally unlocks more built-in Intune capability than E3, and the Intune Suite offers further paid add-ons.
- Remote Help and Endpoint Privilege Management (EPM) are notable advanced capabilities.
- Copilot in Intune uses natural language queries but is billed on a consumption (compute unit) basis, not a flat fee.
Zero Trust and Windows Hello for Business
What is Zero Trust?
“I have zero trust on you” means not simply believing you at your word, verifying, again and again, whether trust is warranted. That’s the spirit of Zero Trust in security.
Zero Trust means “never trust automatically, always verify.” Every access request is verified, it isn’t approved simply because it came from inside the company network or a previously trusted device. This is achieved using a combination of technologies together, such as multi-factor authentication (MFA) and conditional access.
Practical example: if none of your company’s infrastructure or employees are physically present in a particular country, but a login attempt for a company account suddenly comes from that country, conditional access under Zero Trust detects this as suspicious and blocks it automatically.
Windows Hello for Business
Many companies are moving away from plain passwords toward PIN, fingerprint, or face recognition login, this is Windows Hello for Business.
With a traditional password, the encrypted password travels over the internet to be verified. With Windows Hello for Business, the authentication factor (PIN, fingerprint, face) is tied to that specific machine’s TPM chip (Trusted Platform Module), stored securely on-device, and it never travels over the internet the way a password does. Even Microsoft cannot pull that credential data out of the chip remotely; it’s protected at the hardware level.
Yes, you can use the same PIN on two machines, but each machine stores and manages its own Windows Hello for Business setup locally and independently, tied to that machine’s own TPM chip. It’s not one shared credential across devices, each has its own local, TPM-bound registration, even with the same PIN value.
What makes Windows Hello for Business more secure than a traditional password?
- Zero Trust means nothing is trusted automatically, every access attempt is verified using a combination of technologies like MFA and conditional access.
- Windows Hello for Business replaces passwords with PIN, fingerprint, or face recognition, tied to the device’s TPM chip.
- Windows Hello for Business credentials are stored locally on the device’s TPM chip and are not transmitted over the internet the way a traditional password is.
Day 2 moves into hands-on practicals.
Today was fully about building your conceptual foundation. From the next class onward, we move into hands-on practicals inside the Intune portal itself: creating groups, configuring automatic enrollment live, enrolling a real device, setting up Autopilot, and working through real deployment scenarios step by step. Come prepared with your questions.