This guide covers Microsoft Intune endpoint management that every IT professional should know.
Two hundred and forty endpoints. No central patch visibility. Four months until our ISO 27001 surveillance audit. When our CISO asked how many devices were running an unsupported Windows version in that Monday morning ops review, nobody in the room had an answer. This relates directly to Microsoft Intune endpoint management.
That conversation kicked off a three-month Microsoft Intune deployment. This is the honest account of how it went – including the enrollment mistake that set us back two weeks, and the compliance architecture that our auditors ended up praising.
The Estate We Inherited: Microsoft Intune Endpoint Management
Before planning anything, we needed to understand what we were dealing with. An inventory pull from our existing tooling revealed a sprawl of Windows 10 devices across four different feature update versions – some still on 21H2, which reached end of service in December 2023. A scattered collection of Windows 11 22H2 machines deployed ad hoc by different staff over the previous year. And a growing BYOD problem: personal iOS and Android devices accessing corporate email with nothing but a basic ActiveSync policy standing between them and our Exchange environment.
Group Policy was our only configuration management mechanism, and it worked only when devices were connected to the corporate network or VPN. Laptops that had been off-site for months – remote workers, field staff – were effectively unmanaged. We had no way to confirm BitLocker was active across all of them. We had no capability to remotely wipe a device if a leaver handed in their notice on a Friday afternoon. This relates directly to Microsoft Intune endpoint management.
That last scenario had already happened twice before this project started.
Planning the Rollout Before We Touched Anything
The first thing we established: Intune is not software you install on a server. It is a cloud service you configure – and tenant-level settings misconfigured at the start can be genuinely difficult to undo. The planning phase deserved real time. This relates directly to Microsoft Intune endpoint management.
We spent two full weeks on architecture decisions before enrolling a single test device. Our Microsoft 365 licensing was E3, which includes Intune Plan 1 – sufficient for our requirements. We ruled out co-management with Microsoft Configuration Manager fairly quickly. SCCM was in our environment but under-resourced, and the team managing it was mid-restructure. An Intune-only approach simplified our governance model and removed a dependency we could not afford to maintain.
Setting Up the Tenant Correctly
The MDM authority setting gets configured once. Changing it later requires significant remediation work. We set it to Intune in the Microsoft Intune admin center at endpoint.microsoft.com and logged this as a formal change through our CAB. Some organisations treat these configuration decisions as click-through admin work. We do not – and this is one of those areas where a misconfigured setting creates downstream consequences for every device you subsequently manage. This relates directly to Microsoft Intune endpoint management.
We also configured enrollment restrictions on day one: device type restrictions limiting enrollment to corporate Windows and approved iOS and Android devices, and device limit restrictions preventing a single user from enrolling more devices than their role requires. These restrictions became important later. This relates directly to Microsoft Intune endpoint management.
For teams running hybrid environments where on-premises Active Directory still plays a role alongside Entra ID, the SSE article on managing Active Directory objects covers the integration points that affect your Intune Connector for Active Directory setup.
RBAC Before Anyone Gets Admin Access
We configured role-based access control before granting any team member Intune access. The default Intune Administrator role is broad. We created three custom roles: a Help Desk role with read access and remote actions only, a Policy Manager role for our desktop engineers who own profiles and deployments, and retained full administrative access for two senior staff. This is standard practice that teams skip constantly. And then they wonder why a junior technician accidentally initiated a device wipe on a production endpoint. This relates directly to Microsoft Intune endpoint management.
If you are approaching an Intune deployment from scratch and want to avoid architectural decisions that are painful to undo, working with an experienced consulting team early in the planning phase can save weeks of rework down the line.
The Enrollment Mistake That Cost Us Two Weeks
Management wanted to see progress. We wanted to show progress. We opened broad enrollment before we had finished configuring enrollment restrictions – and, critically, before we had built our compliance policies. This relates directly to Microsoft Intune endpoint management.
Within 48 hours, personal devices were enrolling. Staff had seen the Company Portal application appear via a Microsoft 365 app push, assumed it was for personal device access to corporate apps, and enrolled without understanding what they were opting into. Personal iPhones and Android phones were registering in our tenant with no app protection policies applied, no compliance baseline defined, and no conditional access blocking them from corporate data. That was not an acceptable risk posture. This relates directly to Microsoft Intune endpoint management.
We had to unenroll approximately sixty devices – technical work that was straightforward. But the damage to user confidence in the rollout took considerably longer to repair. This relates directly to Microsoft Intune endpoint management.
The correct sequence – which we followed from that point forward – is: configure enrollment restrictions, build compliance policies, configure conditional access in report-only mode, pilot with a controlled group, then open enrollment in departmental waves. Every step in that order. The change window is not just about technical readiness. It is about organisational readiness.
Windows Autopilot for New Hardware Provisioning
Once we had stabilised our enrollment configuration, we turned to the new hardware stream. Our primary hardware vendor could upload device hardware hashes directly to our tenant during the procurement process – no additional effort on our side for devices arriving pre-registered and ready to provision. This relates directly to Microsoft Intune endpoint management.
We created two Autopilot deployment profiles: one for standard users and one for IT team devices. The standard profile enforced a device naming convention (CORP-[Firstname][Lastinitial]), joined devices to Entra ID, and applied our Enrollment Status Page configuration. The ESP was configured to block device use until all required applications and policies had fully applied. Without this setting, users land on the desktop before Defender for Endpoint has onboarded, before the VPN client is installed, and before configuration profiles have applied. That is a window of unmanaged operation we were not willing to accept.
The ESP Timeout Problem Nobody Warns You About
Our standard application deployment included Microsoft 365 Apps for Enterprise. On a slow connection, that installation can exceed 60 minutes. We had set our ESP timeout to 60 minutes. Devices in our satellite offices were hitting that limit and presenting users with a confusing error state – the device was still installing applications in the background, but the screen implied a failure. This relates directly to Microsoft Intune endpoint management.
We increased the timeout to 120 minutes and added a clearer status message visible during provisioning. Not elegant engineering. But it closed fifteen help desk tickets and stopped a recurring complaint from our regional office managers. Sometimes the fix is just adjusting a number in a config screen.
Compliance Policies – The Foundation, Not the Feature
Compliance policies in Intune are not a reporting exercise. They are the technical foundation of your conditional access posture. A device that is not compliant should not be accessing corporate resources – full stop. That is a position I will defend against any argument from convenience or operational cost.
Defining What Compliant Means for Our Environment
We built compliance policies for three platforms: Windows 11, iOS 16+, and Android Enterprise. The Windows baseline required BitLocker enabled, Windows Defender real-time protection active, a minimum OS build of 22621 (Windows 11 22H2), no disabled firewall states, and Secure Boot active. This relates directly to Microsoft Intune endpoint management.
Our finance team pushed back on the minimum OS version requirement. Three machines could not be upgraded to Windows 11 due to hardware compatibility constraints. The governance answer – the only defensible answer – is to document those exceptions formally and either replace the hardware or accept the risk in writing. We replaced two machines. The third received a formal risk acceptance, logged and scheduled for quarterly review.
Noncompliance Actions and the Grace Period
We configured a 24-hour grace period before a device is formally marked noncompliant, and a 72-hour window before a notification email goes to the device user. This gave us time to catch false positives – devices returning from a rebuild that were still in the initial policy application cycle, for example. This relates directly to Microsoft Intune endpoint management.
The notification emails went directly to users, not just to IT. Users do not appreciate being told their device is out of compliance. That is deliberate. It creates accountability. One manager contacted us to say the notifications were alarming. We explained that the alternative was allowing unverified devices to access corporate data without any checks. The conversation ended there.
Conditional Access as the Enforcement Layer
Our conditional access policy required device compliance for all cloud application access – no location exceptions, no IP-based bypass. We ran it in report-only mode for two weeks before enabling enforcement, reviewing sign-in logs daily to identify legitimate users who would have been blocked. Moving directly to enforcement mode without this step means you discover your compliance policy gaps through real access failures, not through controlled log analysis. This relates directly to Microsoft Intune endpoint management.
Conditional access is what transforms Intune from a management console into a security control. Without it, you are collecting compliance data and doing nothing with it.
Configuration Profiles and Security Baselines
We used the Microsoft Security Baseline for Windows 11 as our starting point – specifically the 2023 release, updated from the November 2021 baseline that was our initial deployment target. The baseline applies several hundred settings across the OS. Not all of them will be correct for your environment without adjustment.
When the Baseline Breaks Something
Our Defender SmartScreen configuration – applied through the baseline – flagged a critical line-of-business web application used by our operations team. The application ran on an internal domain with a private certificate that SmartScreen did not recognise. We had two options: create a URL exception in the SmartScreen policy, or extract that specific setting from the baseline into a custom configuration profile where it could be managed with its own scope and documented justification. This relates directly to Microsoft Intune endpoint management.
We chose the second approach. The baseline remains intact and auditable. The exception exists in its own profile with a change record attached. That is a better change management story and a cleaner audit trail than burying exceptions inside a baseline assignment. This relates directly to Microsoft Intune endpoint management.
For context on how endpoint configuration controls fit into a layered security programme, the SSE article on endpoint security fundamentals covers the complementary controls that work alongside Intune policy management.
Delivery Optimization – The Unglamorous Setting That Matters
In a multi-site environment, delivery optimization prevents every device at every branch from independently downloading Windows update content from Microsoft. We configured HTTP blended with peer-to-peer sharing behind the same NAT for our branch office sites. Our network team reported a measurable drop in internet bandwidth consumption during patch Tuesday cycles – not a dramatic number, but consistent and noticeable. This relates directly to Microsoft Intune endpoint management.
Nobody writes conference talks about delivery optimization configuration. But it eliminates the WAN saturation complaints that otherwise arrive in your inbox every second Wednesday of the month. Boring reliability over clever solutions – every time.
Application Deployment and MAM for BYOD
We deployed Microsoft 365 Apps via the built-in Intune app type, configured to the Semi-Annual Enterprise Channel for stability. Our change management policy requires tested, stable releases for productivity applications across the broad user base. Monthly Enterprise Channel was reserved for the IT team and a fifty-user pilot group who could absorb the earlier update cycle.
Line-of-Business App Packaging Realities
Custom applications required Win32 packaging using the Intune Win32 App Prep Tool. We defined detection rules based on registry keys rather than file presence – registry checks are more reliable for versioned applications and do not generate false positives from leftover temporary files. This relates directly to Microsoft Intune endpoint management.
Three of our applications came from vendors whose install packages were poorly constructed – they installed to user profile directories rather than Program Files, which complicated detection logic significantly. My position: if a software vendor is not providing properly structured installer packages in 2024, that is a procurement and vendor management conversation. It is not a problem for IT to work around indefinitely. We documented the issue and raised it formally with the relevant vendor contacts.
App Protection Policies for the BYOD Population
For staff using personal iOS and Android devices, we implemented Mobile Application Management without device enrollment – MAM-WE. The device itself remains unmanaged by Intune. Corporate applications – Outlook, Teams, OneDrive – are wrapped in app protection policies requiring a PIN to access corporate content, blocking copy-paste between managed and unmanaged applications, and enabling selective wipe of corporate app data on offboarding. Personal data on the device is untouched. This relates directly to Microsoft Intune endpoint management.
This approach resolved the friction that had driven our original enrollment problems and gave us a defensible position on employee privacy. (This works well for the standard Microsoft 365 app suite – it does not extend cleanly to custom line-of-business applications that are not built against the Intune MAM SDK.) This relates directly to Microsoft Intune endpoint management.
For organisations being audited on their mobile device management posture, the SSE article on IT auditing in the age of AI and Zero Trust covers how auditors evaluate mobile controls within a broader endpoint governance framework.
Device Lifecycle and the Retirement Runbook
Before initiating any device retirement or wipe, we had to address data protection. Users store files locally. Some are synced to OneDrive. Some are not. Our pre-retirement runbook required a check on OneDrive Known Folder Move status for each device. For devices with confirmed local-only files, a data transfer step was mandatory before the retirement action was initiated. For devices with uncertain data status, our process included replicating data to a secondary site as a precaution before any wipe proceeded.
The retire action removes corporate data and unenrolls the device without touching personal files – appropriate for leavers on BYOD or corporate devices being repurposed for a new employee. The wipe action returns the device to factory state. We built a decision tree into our offboarding runbook covering every combination of device ownership type and disposal destination. Each individual retirement is now a pre-approved standard change. The runbook itself went through our CAB as a normal change – full risk assessment, rollback procedure, documented approval.
What the End State Looks Like
Twelve weeks after we started – ninety days from the question that kicked this off – we had 238 of 240 devices enrolled and showing compliant or compliant-pending. The two outstanding devices were the hardware-ineligible finance machines managed under formal risk exceptions with quarterly review dates.
The Intune admin center compliance dashboard shows BitLocker status, patch level, antivirus state, and last check-in time for every managed device. Remote wipe and remote lock are available for any enrolled device within seconds of receiving a request. Conditional access enforces compliance as the gate for every Microsoft 365 and Entra ID application in our environment.
The ISO 27001 auditors reviewed our Intune configuration and compliance trend reporting. They asked for evidence of policy assignment coverage, our noncompliance notification process, and historical compliance rates. We provided all three from the admin center within an hour of the request. That is what a functioning endpoint management platform looks like in practice.
What We Would Do Differently
Three lessons stand out from this deployment.
Pilot before you open enrollment. Twenty representative devices, run for two weeks. You will find the ESP timeout issues, the SmartScreen conflicts with existing applications, and the app packaging edge cases before they reach your production user base. There is no substitute for this step.
Build compliance policies and conditional access before enrollment opens – not alongside, not shortly after. Before. The two weeks we lost to the personal device enrollment incident came directly from skipping this sequence, and no amount of retrospective justification changes that.
Invest properly in user communication. We sent one email before the rollout started. One. Users had no context for why Company Portal appeared on their devices, what a compliance assessment meant, or why they were receiving noncompliance notifications. Three communications – a pre-launch brief, a day-one guide, and a help desk FAQ – would have prevented most of the confusion and most of the difficult conversations with department heads.
The Intune platform performed exactly as documented. Every significant problem we encountered was a people or process failure, not a technology failure. That is a lesson that applies to every infrastructure project we have ever run, and it is worth saying plainly each time.
If your organisation is planning an Intune rollout and you want structured guidance on enrollment architecture, compliance framework design, or application management strategy, the team at SSE works with organisations at every stage of the Intune journey. Get in touch at clients.sse.to/contact.php to discuss your specific environment and requirements. This relates directly to Microsoft Intune endpoint management.
