From First Workshop to Production: A Real Customer Implementation
In the first part of this series, I explained what Apple Automated Device Enrollment (ADE) is, why it exists, and when it makes sense to use it.
In this second part, I walk through a real customer project—from the very first workshop to a production-ready deployment. Along the way, I explain the key decisions, architectural choices, and real-world constraints that shaped the final solution.
This article does not describe a lab scenario. Instead, it reflects how ADE projects actually unfold in production: with trade-offs, limitations, and compromises that must be addressed early.
Why This Article Exists
Apple ADE with Microsoft Intune is often presented as a simple, linear process:
- Register Apple Business Manager
- Connect Intune
- Create an enrollment profile
However, in real projects, most of the critical work happens before any configuration begins.
Therefore, this article focuses on:
- how we selected the correct deployment model
- which questions must be answered upfront
- where Apple and Intune impose non-negotiable limits
- challenges encountered during the project
- what worked as expected—and what required alternative approaches
Project Kick-Off: The First Workshop
We started the project with a discovery workshop that included IT, security, and operational stakeholders.
Rather than configuring Intune immediately, we focused on understanding the customer’s environment, constraints, and long-term expectations.
Importantly, these early conversations defined the entire solution. Technical settings followed later.
Workshop Goals
During the workshop, we aimed to:
- understand the current device landscape
- explain Intune and ADE capabilities and limitations
- align expectations with Apple and Microsoft constraints
- agree on the target deployment model and next steps
Key Questions We Asked
Before any technical work began, we ran a structured discovery session.
The goal was straightforward: understand real requirements before selecting a deployment model.
Instead of diving into Intune settings, we first answered a set of fundamental questions. These answers ultimately shaped every technical decision that followed.
A full list of questions, answers, and decision points is available in the linked PDF.
Questions, Answers and decision points
Key takeaway:
A successful Intune ADE implementation is decided during discovery — not during configuration.
Why ADE Was the Only Correct Choice
For this customer, ADE was not a “nice to have.” It was a requirement.
Because the organization owns the devices and operates in a regulated, security-sensitive environment, we immediately ruled out manual enrollment and BYOD-style approaches. The customer required:
- mandatory supervision
- zero-touch enrollment
- strong policy enforcement
- full device lifecycle control
Only Apple Automated Device Enrollment with supervised devices met these requirements. Other enrollment models simply could not provide the same level of control or reliability.
High-Level Architecture (Before Configuration)
Before touching any configuration, we defined the architecture at a high level.
The solution consists of three main components:
-
Apple Business Manager (ABM)
Device ownership, enrollment assignment, and app licensing -
Microsoft Intune
MDM policies, compliance, configuration, and application deployment -
Apple Automated Device Enrollment (ADE)
The mechanism that automatically enrolls devices into Intune after factory reset
This architecture ensures that a device is managed from the first boot and cannot be removed from management by the end user.
Starting From Zero: No ABM, No VPP, No Tokens
A critical detail of this project is that the customer started with no Apple infrastructure in place.
Specifically, there was:
- no Apple Business Manager tenant
- no VPP token
- no Apple MDM Push Certificate
- no enrollment documentation
What This Means in Practice
Registering Apple Business Manager takes time. Apple must:
- verify the legal entity
- validate the D-U-N-S number
- confirm signing authority
As a result, approval can take days—or longer.
Lesson learned:
Start Apple Business Manager registration as early as possible, even before finalizing the Intune design.
Apple Business Manager & Intune Integration
Once ABM became available, we integrated it with Intune.
This integration included:
- Apple MDM Push Certificate
- ADE enrollment token
- VPP (Apps and Books) token
- default device assignment to Intune
Operational Note
If the Apple MDM Push Certificate expires, all iOS devices stop communicating with Intune and must be re-enrolled.
For that reason, certificate monitoring and renewal are critical operational tasks.
Device Lifecycle: What Actually Happens
From the end-user perspective, the device lifecycle looks like this:
- device is factory reset
- ADE enrollment starts automatically
- device enrolls into Intune
- Just-in-Time (JIT) registration runs
- user signs in
- policies and applications deploy
During enrollment:
- Microsoft Authenticator sign-in is required
- passkeys are not supported (Apple limitation)
- standard MFA works as expected
iOS Update Strategy in Production
OS updates represented a major concern for the customer.
To address this, we implemented a two-policy approach:
Policy Design
- General OS Update Policy – fallback
- Force OS Update Policy – primary control
This design allows us to:
- force a specific iOS version
- hide older and newer versions
- prevent untested upgrades
- target different device groups if needed
Important Limitation
Apple does not support iOS downgrades.
As a result, this approach balances strong control with Apple’s enforced update model.
Application Deployment Strategy (VPP)
Applications are deployed using Apple’s VPP integration.
Key design decisions:
- Device-based licensing
- No Apple ID dependency for app installation
- Separate test and production device groups
- Automatic updates disabled for the production device group
- Automatic updates enabled only for test devices
After testing, updates are promoted to production devices.
Application Version Control – Reality Check
Many customers assume that Intune can fully control app versions.
In practice, this is not true.
Reality:
- App Store apps cannot be version-pinned
- Full control requires LOB (in-house) applications
- The app vendor must provide the correct package
For this reason, we clearly communicated these limitations early in the project.
Security Baseline: What Works and What Doesn’t
Successfully Enforced
- Bluetooth disabled
- iCloud Drive and Photos blocked
- Automatic downloads disabled
- Device naming enforced
- Pre-installed apps hidden
Apple-Imposed Limitations
Some settings cannot be enforced by any MDM:
- App refresh behavior
- Auto-brightness
- Auto-lock (outside kiosk mode)
- Gesture behavior
These are Apple design decisions, not Intune limitations.
Compliance, Monitoring, and Cleanup
We implemented compliance policies to:
- detect jailbroken devices
- enforce a minimum iOS version
- notify users about non-compliance
- optionally alert IT teams
Additionally, an automated cleanup rule removes inactive devices after 270 days to keep the tenant clean.
Apple ID Strategy: A Difficult but Important Topic
The customer currently uses personal Apple IDs with the company domain.
Our recommendation was clear: move to Managed Apple IDs.
Benefits
- clear ownership
- improved governance
- predictable app licensing behavior
This transition requires organizational planning and user communication.
Project Challenge
As part of the initial workshops, we agreed to use Apple Device Enrollment (ADE) as the primary enrollment model. This meant that all devices needed to be registered in Apple Business Manager (ABM) and factory reset before enrollment.
The main challenge quickly became clear: a portion of the existing devices had not been purchased through an official Apple Authorized Reseller. In addition, there were no purchase receipts or reseller records available. As a result, these devices could not be automatically assigned to Apple Business Manager.
The alternative option was to manually add devices to ABM using Apple Configurator, which requires a Mac and a physical connection to each device. However, this approach was not practical in this case, as the devices were distributed across multiple locations worldwide. Centralizing the devices for manual onboarding was not feasible.
Solution (Workaround)
To address this, we decided to enroll those specific devices using Device Enrollment (device-driven enrollment) instead of ADE. The customer was clearly informed about the limitations of this approach. Most notably, devices enrolled this way cannot be fully supervised, and software update management is not available.
While this was not the ideal scenario, it allowed the organization to achieve the primary goal: gaining a basic level of management and security over the devices. This approach provided visibility and protection until the devices could be replaced.
The long-term plan is that, as devices reach end of life and are replaced, all new hardware will be purchased through authorized channels, registered in Apple Business Manager, and enrolled using Apple Device Enrollment.
This serves as a good reminder that, no matter how well a project is planned, exceptions and unexpected constraints will always arise. In many cases, this is due to incomplete historical information rather than poor design. What matters most is the ability to adapt while still delivering the best possible outcome for the customer. It is equally important to clearly explain to the customer what these limitations mean in practice and what risks they introduce. The customer must explicitly understand and accept those risks. If they had not accepted them, the alternatives would have been to purchase new iPads and redistribute them, or to physically collect the existing devices in a central location for manual onboarding.
In this case, the customer accepted the limitations and defined a future plan to gradually replace these devices, ensuring that all new hardware will follow the preferred ADE-based enrollment model.
Known Limitations
Some limitations cannot be avoided:
- Passkeys not supported during enrollment
- Limited app version control
- Apple-controlled MDM boundaries
- Kiosk mode not suitable for per-user devices
Transparency about these limitations is critical for project success.
Customer Responsibilities
Successful operation requires ongoing customer involvement:
- Renew Apple MDM Push Certificate
- Maintain enrollment documentation
- Finalize naming conventions and groups
- Adjust Conditional Access policies
- Finalize application list
- Apply company branding
Final Thoughts
Apple ADE with Intune is powerful—but it is not “set and forget.”
Success depends on:
- making the right decisions early
- understanding platform limitations
- communicating clearly with users
- maintaining strong operational discipline