macOS ABM to Intune Enterprise Runbook

Project 5 — Simulated macOS ABM to Intune Runbook

Status: COMPLETE
Project type: FREE WITH SIMULATION
Microsoft-side implementation: REAL CONFIGURATION where validated
Apple Business Manager / ADE: SIMULATED / DOCUMENTED

Objective

Demonstrate an enterprise macOS management design spanning Apple Business Manager (ABM), Microsoft Intune, Automated Device Enrollment (ADE), Microsoft Entra authentication, Platform SSO, enterprise Wi-Fi, certificates, FileVault, compliance, application deployment, inventory, and lifecycle administration.

The project deliberately separates what was actually configured in the Microsoft Intune tenant from Apple- and endpoint-dependent workflows that could not be executed legitimately in the lab.

What was actually configured

The following work was performed in the real Microsoft Intune tenant:

• Apple MDM Push (APNs) certificate created through Apple's Push Certificates Portal and uploaded to Intune.
• APNs certificate validated as active in Intune; renewal due 2027-09-26.
• macOS compliance policy created:
• System Integrity Protection required.
• Password required to unlock.
• Storage encryption required.
• Firewall enabled.
• Stealth Mode enabled.
• Gatekeeper limited to the Mac App Store and identified developers.
• Noncompliance marked immediately.
• macOS FileVault Settings Catalog profile created:
• FileVault enabled.
• Users prevented from disabling FileVault.
• Recovery-key escrow location guidance configured.
• Intune macOS enrollment restrictions reviewed and validated.
• Platform SSO configuration capability reviewed in the Settings Catalog.
• Enterprise Wi-Fi capability reviewed, including WPA/WPA2-Enterprise and EAP methods.
• SCEP certificate profile capability reviewed.
• macOS app deployment types reviewed.
• macOS inventory and bulk lifecycle actions reviewed.

What remains simulated/documented

The following workflows are documented but were not represented as implemented:

• Apple Business Manager organization enrollment and verification.
• Reseller/device assignment into ABM.
• Intune Enrollment Program Token exchange with ABM.
• Automated Device Enrollment synchronization.
• ADE enrollment profile deployment.
• macOS Setup Assistant ADE experience.
• Platform SSO registration on a managed Mac.
• Certificate issuance through a live enterprise PKI/SCEP path.
• Enterprise RADIUS authentication.
• FileVault recovery-key escrow from an enrolled Mac.
• Compliance evaluation on an enrolled Mac.
• App installation on a managed Mac.
• Device reassignment, retire, wipe, and lost/stolen execution against a real Mac.

Architecture

Apple procurement / reseller
        ↓
Apple Business Manager
        ↓
Intune Enrollment Program Token
        ↓
Automated Device Enrollment profile
        ↓
macOS Setup Assistant
        ↓
Microsoft Entra authentication
        ↓
Microsoft Intune enrollment
        ↓
Configuration + applications + compliance
        ↓
FileVault + recovery-key escrow
        ↓
Inventory + lifecycle administration

See architecture.md for the full real-versus-simulated boundary.

Evidence

The evidence gallery is available at:

• Project 5 evidence index
• Live case study

Screenshots are direct captures from the real Intune tenant or Apple Push Certificates Portal. No simulated screenshot is presented as real administration.

Documentation

• Architecture
• Implementation
• Validation
• Troubleshooting
• Lessons learned
• Renewal calendar
• Device lifecycle
• Simulated deployment scenario
• Portfolio summary

Security and evidence handling

The repository does not publish Apple credentials, private keys, enrollment tokens, bearer tokens, FileVault recovery keys, passwords, MFA secrets, or session cookies. Screenshots selected for publication avoid personal Apple-account identifiers and sensitive certificate material.

Technologies demonstrated

Apple Business Manager architecture, Apple Push Notification service, Microsoft Intune, Microsoft Entra ID, Automated Device Enrollment concepts, Platform SSO, Settings Catalog, FileVault, macOS compliance, enterprise Wi-Fi, EAP-TLS, SCEP/PKCS concepts, macOS application deployment, inventory, device lifecycle, renewal operations, and evidence-based administration.

Architecture — macOS ABM to Intune

Status boundary

This project uses three explicit implementation states:

• REAL CONFIGURATION — actually configured or directly validated in the real Microsoft Intune tenant.
• SIMULATED / DOCUMENTED — accurately designed and documented, but not executed because the required Apple infrastructure or managed macOS endpoint is unavailable.
• NOT VALIDATED — a Microsoft-side policy may exist, but endpoint behavior was not tested on an enrolled Mac.

Intended enterprise flow

Authorized reseller / Apple procurement
        │
        ▼
Apple Business Manager
        │
        │ device assignment to MDM server
        ▼
Microsoft Intune MDM server
        │
        │ Enrollment Program Token
        ▼
Automated Device Enrollment
        │
        ▼
macOS Setup Assistant
        │
        ▼
Microsoft Entra authentication
        │
        ▼
Microsoft Intune enrollment
        │
        ├───────────────┬────────────────┬────────────────┐
        ▼               ▼                ▼                ▼
Configuration       Applications      Compliance       Security
profiles                                                controls
        │               │                │                │
        ├─ Platform SSO │                │                ├─ FileVault
        ├─ Wi-Fi / PKI  │                │                └─ Firewall
        └─ restrictions │                │
        └───────────────┴────────────────┴────────────────┘
                                │
                                ▼
                    Inventory + lifecycle
                                │
                  ┌─────────────┼─────────────┐
                  ▼             ▼             ▼
                Retire         Wipe       Reassignment

Apple service boundary

Apple Push Notification service — REAL CONFIGURATION

A real Apple MDM Push certificate was created in Apple's Push Certificates Portal using the Intune-generated CSR and uploaded back to the Intune tenant.

Validated state:

• Vendor: Microsoft Corporation.
• APNs certificate created successfully.
• Intune upload completed successfully.
• Certificate expiration: 2027-09-26.

The Apple account used to own the certificate is intentionally excluded from public evidence.

Apple Business Manager — SIMULATED / DOCUMENTED

No Apple Business Manager organization is available in the lab. Therefore, the following are not represented as implemented:

• organization verification;
• reseller/device assignment;
• MDM server creation in ABM;
• ABM server token issuance;
• Enrollment Program Token import;
• ADE device sync;
• ADE profile assignment;
• Setup Assistant ADE behavior.

Microsoft service boundary

Microsoft Intune — REAL CONFIGURATION

The real tenant was used to create or inspect:

• Apple enrollment administration;
• macOS compliance policy;
• macOS FileVault Settings Catalog profile;
• macOS enrollment restrictions;
• Platform SSO settings;
• enterprise Wi-Fi settings;
• SCEP certificate settings;
• macOS application types;
• macOS inventory;
• macOS bulk device lifecycle actions.

Microsoft Entra ID

Microsoft Entra is the intended identity provider for Company Portal enrollment and Platform SSO. Endpoint Platform SSO registration is NOT VALIDATED because there is no enrolled macOS endpoint.

Real vs. simulated matrix

Enterprise Wi-Fi design

The intended secure WLAN model is:

macOS device
   │
   ├─ trusted root certificate
   ├─ SCEP/PKCS device certificate
   │
   ▼
WPA2-Enterprise / EAP-TLS
   │
   ▼
RADIUS / network policy service
   │
   ▼
Enterprise wireless network

The Intune tenant exposed WPA-Enterprise, WPA2-Enterprise, EAP-FAST, EAP-SIM, EAP-TLS, EAP-TTLS, LEAP, and PEAP. EAP-TLS is the documented design because it supports certificate-based device authentication without depending on user passwords for Wi-Fi access.

Security design principles

• Require FileVault encryption.
• Prevent users from disabling FileVault after policy enforcement.
• Escrow the personal recovery key to the management service when a managed Mac exists.
• Require System Integrity Protection.
• Require password-protected unlock.
• Enable firewall and Stealth Mode.
• Preserve Gatekeeper restrictions.
• Prefer certificate-based enterprise Wi-Fi.
• Keep APNs renewal ownership documented.
• Separate destructive lifecycle operations from routine sync/restart actions.
• Never publish recovery keys, token contents, credentials, or certificate private material.

macOS Device Lifecycle Runbook

1. Procurement and assignment

SIMULATED / DOCUMENTED

Preferred enterprise path:

1. Purchase through Apple or an authorized reseller linked to the ABM organization.
2. Verify the device appears in Apple Business Manager.
3. Assign the device to the Microsoft Intune MDM server.
4. Synchronize the Enrollment Program Token in Intune.
5. Assign the correct ADE profile.

2. Enrollment

SIMULATED / DOCUMENTED

1. User powers on or resets the Mac.
2. Apple activation identifies the device as organization-owned.
3. ADE directs the device to Intune.
4. Setup Assistant applies the configured enrollment experience.
5. User authenticates where required.
6. Intune enrollment completes.
7. Company Portal / Platform SSO registration follows the organization design.

3. Configuration and security

Microsoft-side configuration demonstrated in the real tenant includes:

• compliance baseline;
• FileVault baseline;
• Platform SSO capability;
• enterprise Wi-Fi capability;
• certificate profile capability;
• app deployment capability.

Endpoint enforcement remains unvalidated without an enrolled Mac.

4. Inventory and ownership

The Intune macOS inventory surface exposes:

• device name;
• management authority;
• ownership;
• compliance;
• OS and version;
• primary user;
• last check-in.

Current lab inventory: 0 macOS devices.

5. Routine operations

Available real Intune actions include:

• Sync — request management check-in.
• Restart — restart the managed device.
• Rename — change device display/name where supported.

6. Retirement

SIMULATED / DOCUMENTED

Use when management should be removed without treating the device as stolen or requiring a factory reset. Confirm ownership and data-handling requirements before choosing Retire.

7. Wipe

SIMULATED / DOCUMENTED

Use only after validating:

• device identity;
• ownership;
• authorization;
• data-retention requirements;
• reassignment or disposal plan.

A wipe is destructive and should be treated as a controlled administrative action.

8. Delete

Deleting the Intune object is not equivalent to securely wiping the device. Confirm the device has already been retired/wiped or otherwise handled appropriately before deleting the management record.

9. Reassignment

SIMULATED / DOCUMENTED

For corporate devices:

1. Capture required asset state.
2. Retire/wipe according to policy.
3. Reassign in ABM if the MDM destination changes.
4. Ensure the correct ADE profile is assigned.
5. Reset the Mac.
6. Enroll the next user through Setup Assistant.
7. Validate inventory, compliance, FileVault, apps, and authentication.

10. Lost or stolen device

SIMULATED / DOCUMENTED

1. Verify the asset and user.
2. Escalate to security/management.
3. Revoke or block identity sessions as policy requires.
4. Evaluate remote wipe.
5. Revoke device certificates where appropriate.
6. Preserve incident records.
7. Update asset ownership/status.
8. Do not expose recovery keys or credentials during evidence capture.

Project 5 Evidence Index

The public evidence in this folder is deliberately sanitized and narrowly captioned. It proves Microsoft-side configuration and capability without implying that Apple Business Manager, Automated Device Enrollment, or a managed macOS endpoint exists in this lab.

Published screenshot evidence

Security and management proof board

Open the screenshot proof board

The board is a derived composite built from four screenshots captured during this Project 5 session:

1. Apple Push Certificates Portal confirmation — proves Apple issued a new Mobile Device Management push certificate for Microsoft Corporation with expiration September 26, 2027.
2. macOS compliance policy review — proves the real Intune policy was configured with System Integrity Protection, password, storage encryption, firewall, Stealth Mode, and Gatekeeper requirements before creation.
3. macOS FileVault Settings Catalog configuration — proves FileVault was set to On, users were prevented from disabling it, and recovery-key escrow location guidance was configured.
4. Platform SSO settings discovery — proves the real Intune Settings Catalog exposes the Platform SSO configuration surface.

The board proves only the states described above. It does not prove macOS endpoint enforcement, recovery-key escrow, Platform SSO registration, or ADE enrollment.

Additional validated observations

The following real Intune capability observations are documented in the project runbook and were captured during the same session:

• macOS app deployment types included Microsoft Edge, Microsoft 365 Apps, Microsoft Defender for Endpoint, web clips, web links, line-of-business apps, DMG, and PKG.
• macOS inventory was available and showed 0 devices.
• macOS bulk device actions exposed Delete, Retire, Wipe, Restart, Rename, and Sync.
• Enterprise Wi-Fi exposed WPA-Enterprise and WPA2-Enterprise.
• EAP methods included EAP-FAST, EAP-SIM, EAP-TLS, EAP-TTLS, LEAP, and PEAP.
• macOS SCEP configuration exposed certificate type, subject/SAN, validity, key usage, key size, root certificate, and EKU controls.

These observations are classified as REAL CAPABILITY VALIDATION, not endpoint implementation.

Why only a sanitized derivative is published

Source screenshots from the working session are retained in the conversation/evidence workflow, but only the sanitized composite is published here. This prevents unnecessary exposure of Apple account identifiers, certificate identifiers, or other tenant-specific details while preserving direct visual proof of the configuration work.

Evidence handling rules

• No Apple account identifier is intentionally published.
• No APNs PEM file, certificate private key, recovery key, enrollment token, ABM token, password, bearer token, session cookie, or MFA secret is stored here.
• No simulated ABM/ADE screenshot is used.
• Documentation, not fabricated portal evidence, is used for simulated Apple Business Manager and Automated Device Enrollment workflows.

Implementation

1. Apple MDM Push certificate — REAL CONFIGURATION

The Intune Apple enrollment page initially showed the Apple MDM Push Certificate as Not set up.

Implementation sequence:

1. Accepted Microsoft's Apple data-sharing permission prompt in Intune.
2. Downloaded the Intune certificate signing request (CSR).
3. Opened Apple's Push Certificates Portal.
4. Accepted Apple's MDM certificate terms.
5. Uploaded the Intune-generated CSR.
6. Apple issued a new Mobile Device Management push certificate for Microsoft Corporation.
7. Downloaded the resulting PEM certificate.
8. Returned to Intune.
9. Entered the Apple account used to create the certificate.
10. Uploaded the PEM certificate.
11. Intune reported successful MDM push certificate creation.
12. Final Intune state showed the certificate as active.

Validated expiration: 2027-09-26.

No Apple credentials, PEM file, private key material, certificate serial number, or Apple account identifier are published.

2. Enrollment Program Token / ADE — SIMULATED / DOCUMENTED

The real Intune tenant was used to inspect the Enrollment Program Token workflow.

Intune exposes the expected sequence:

1. Grant Microsoft permission to exchange device/user information with Apple.
2. Download the Intune public-key certificate.
3. Open Apple Business Manager.
4. Create the ABM MDM server relationship.
5. Upload the Intune public key in ABM.
6. Download the ABM server token.
7. Enter the Apple ID used for token ownership.
8. Upload the token to Intune.
9. Sync assigned devices.
10. Create and assign ADE profiles.

The lab has no Apple Business Manager organization, so no token was created and no device was synchronized.

3. macOS compliance baseline — REAL CONFIGURATION

Policy:

Project 5 - macOS Enterprise Compliance

Configured settings:

• Require System Integrity Protection.
• Require a password to unlock devices.
• Require encryption of data storage.
• Enable Firewall.
• Enable Stealth Mode.
• Gatekeeper: allow apps from the Mac App Store and identified developers.
• Mark device noncompliant immediately.

Assignment:

• intentionally unassigned because there is no managed macOS test endpoint.

Result:

• policy object created successfully in the real Intune tenant;
• monitoring showed 0 devices, which matches the known lab inventory.

4. FileVault baseline — REAL CONFIGURATION

Policy:

Project 5 - macOS FileVault Baseline

Profile type:

• macOS Settings Catalog.

Configured controls:

• FileVault > Enable = On
• FileVault Options > Prevent FileVault From Being Disabled = True
• recovery-key escrow Location guidance configured.

The profile was intentionally left unassigned because there is no managed macOS endpoint.

What is proven:

• the policy exists;
• the configured settings are visible in the real Intune tenant.

What is not proven:

• FileVault was enabled on a Mac;
• a recovery key was successfully escrowed;
• the recovery key was rotated or recovered.

5. Platform SSO — REAL CAPABILITY, DOCUMENTED DEPLOYMENT

A macOS Settings Catalog review confirmed:

Authentication > Extensible Single Sign On (SSO) > Platform SSO

The review profile was canceled after capability inspection to avoid leaving a nonfunctional placeholder policy.

A production deployment would also require a managed macOS endpoint, Company Portal / Microsoft Enterprise SSO plug-in prerequisites, supported macOS version, and actual registration validation.

6. Enterprise Wi-Fi — REAL CAPABILITY, DOCUMENTED DEPLOYMENT

The macOS Wi-Fi template exposes:

• Device Channel deployment;
• Basic and Enterprise profile types;
• WPA-Enterprise;
• WPA2-Enterprise;
• EAP-FAST;
• EAP-SIM;
• EAP-TLS;
• EAP-TTLS;
• LEAP;
• PEAP;
• proxy options;
• MAC address randomization controls.

The portfolio design uses WPA2-Enterprise + EAP-TLS with trusted-root and client-certificate deployment.

No fake SSID, RADIUS server, or certificate authority was created.

7. Certificate deployment — REAL CAPABILITY, DOCUMENTED ISSUANCE

The macOS SCEP certificate template exposes:

• deployment channel;
• certificate type;
• subject name format;
• subject alternative names;
• validity period;
• key usage;
• key size;
• trusted root certificate;
• extended key usage.

No certificate was issued because the lab does not have a configured enterprise SCEP/PKI path for macOS.

8. Application deployment — REAL CAPABILITY

The real Intune macOS app surface exposes:

• Microsoft Edge for macOS;
• Microsoft 365 Apps for macOS;
• Microsoft Defender for Endpoint (macOS);
• macOS web clip;
• web link;
• line-of-business app;
• macOS app (DMG);
• macOS app (PKG).

No placeholder application was created because there is no managed Mac on which to validate installation.

9. Enrollment restrictions — REAL VALIDATION

Default macOS enrollment restrictions were reviewed.

Observed state:

• macOS enrollment: Allow.
• personally owned macOS devices: Allow.
• minimum OS: not configured.
• maximum OS: not configured.

The default tenant-wide restriction was not modified merely for portfolio appearance.

10. Inventory and lifecycle — REAL CAPABILITY

The macOS inventory page showed 0 devices.

The bulk action workflow exposed these macOS actions:

• Delete
• Retire
• Wipe
• Restart
• Rename
• Sync

No destructive action was executed.

Lessons Learned

1. Apple management has two control planes

Intune can expose Apple enrollment, configuration, compliance, application, and lifecycle administration even when Apple Business Manager is not available. ABM is a separate Apple control plane for organization ownership, device assignment, and ADE.

Treating these as one system would overstate what was actually implemented.

2. APNs is foundational and operationally sensitive

The Apple MDM Push certificate is not a one-time setup artifact. It is an annual operational dependency. The same Apple account must remain available for renewal, and the existing certificate relationship should be renewed rather than casually replaced.

3. Policy creation is not endpoint validation

Creating a macOS compliance policy or FileVault profile in Intune proves administrative configuration capability. It does not prove that a Mac received, enforced, or reported the setting.

This project intentionally keeps those claims separate.

4. Portfolio accuracy is stronger than fabricated completeness

ABM, ADE, Platform SSO registration, EAP-TLS authentication, FileVault escrow, and lifecycle execution are valuable concepts, but inventing screenshots or pretending a managed Mac exists would weaken the portfolio.

A clearly bounded simulation demonstrates sound administration judgment.

5. Current Intune design should avoid deprecated templates

The deprecated macOS Endpoint Protection template was visible, but FileVault was configured through the current Settings Catalog instead.

6. Enterprise Wi-Fi is a dependency chain

A Wi-Fi profile alone is not enterprise authentication. EAP-TLS depends on:

• trusted root certificate;
• device/user certificate issuance;
• certificate identity/EKU design;
• RADIUS trust;
• network policy;
• managed endpoint delivery.

Documenting that dependency chain is more meaningful than creating a fake SSID.

7. Lifecycle administration requires ownership context

Retire, wipe, delete, restart, rename, and sync are exposed in Intune, but the correct action depends on ownership, incident type, reassignment plan, and data-retention requirements.

8. Evidence should prove exactly what the caption claims

The evidence gallery pairs each screenshot with a narrow claim. A capability screenshot proves capability. A policy review proves settings. A policy-monitor screenshot proves the policy exists. None are used to imply an enrolled Mac where none exists.

Portfolio Summary

Recruiter-facing description

Designed and documented an enterprise macOS management runbook spanning Apple Business Manager, Microsoft Intune, Automated Device Enrollment, Microsoft Entra authentication, Platform SSO, FileVault, compliance, enterprise Wi-Fi, certificates, application deployment, inventory, and device lifecycle administration. Implemented the Microsoft-side controls that were legitimately available in a real Intune tenant—including APNs, macOS compliance, and a FileVault Settings Catalog profile—while clearly separating ABM/ADE and endpoint-only validation as simulated/documented.

Resume bullet

• Built a portfolio-grade macOS enterprise management runbook integrating Apple Business Manager architecture with Microsoft Intune; configured real APNs, macOS compliance, and FileVault policies, and documented ADE, Platform SSO, EAP-TLS certificate Wi-Fi, application deployment, renewal, and lifecycle operations with explicit validation boundaries.

LinkedIn project description

Created an enterprise macOS management project focused on accurate operational design rather than fabricated completeness. In a real Microsoft Intune tenant, I configured an Apple MDM Push certificate, created a macOS compliance baseline, built a FileVault Settings Catalog profile, and validated available Platform SSO, enterprise Wi-Fi, certificate, app-deployment, inventory, and lifecycle controls. Because I do not have an Apple Business Manager organization or managed Mac in this lab, ADE, ABM token exchange, endpoint Platform SSO, FileVault escrow, and destructive lifecycle operations are clearly documented as simulated procedures instead of being presented as completed production work.

Interview explanation

I wanted the project to show both technical knowledge and administrative judgment. I used the real Intune tenant for everything I could legitimately configure, including APNs, compliance, and FileVault. I also inspected the real Platform SSO, Wi-Fi, SCEP, app, inventory, and lifecycle surfaces. The Apple Business Manager and ADE portions are documented as simulations because I do not have an ABM organization or enrolled Mac. That boundary matters because creating an Intune policy is not the same as proving endpoint enforcement.

Renewal Calendar and Operational Ownership

Renewal schedule

APNs renewal procedure

1. Start renewal well before expiration.
2. Identify the Apple account that owns the existing certificate.
3. In Intune, confirm the existing APNs certificate identity.
4. Open Apple's Push Certificates Portal using the same owning Apple account.
5. Renew the existing certificate.
6. Download the renewed certificate.
7. Upload it into the existing Intune APNs configuration.
8. Confirm status and new expiration.
9. Record the renewal date and next renewal deadline.
10. Do not publish certificate material or Apple-account identifiers.

ABM token renewal procedure

SIMULATED / DOCUMENTED

1. Confirm the existing Intune Enrollment Program Token and corresponding ABM MDM server.
2. Sign in to ABM with an authorized account.
3. Download a renewed server token for the same MDM server.
4. Upload it to the existing Intune token object.
5. Synchronize devices.
6. Confirm device count and token expiration.
7. Record renewal ownership.

Operational rule

Renew existing trust relationships whenever continuity is required. Replacing APNs certificates or recreating ABM MDM server relationships without a change reason can break management continuity.

Simulated Enterprise Deployment Scenario

Scenario

A company purchases a batch of corporate Macs from an Apple-authorized reseller. The devices are automatically assigned to the organization's Apple Business Manager tenant and then to Microsoft Intune.

This scenario is SIMULATED / DOCUMENTED. It is used to demonstrate the intended operational sequence without claiming that an ABM tenant or physical managed Mac exists in this lab.

Workflow

1. Procurement

2. Reseller associates devices with the ABM organization.

3. Apple Business Manager

4. Devices appear in ABM.

5. Administrator assigns them to the Microsoft Intune MDM server.

6. Enrollment Program Token

7. Intune synchronizes assigned devices from ABM.

8. ADE profile

9. Corporate enrollment profile is assigned.

10. Required Setup Assistant panes are shown or skipped according to policy.

11. Setup Assistant

12. Device connects to the network.
13. Apple activation identifies the device as organization-managed.

14. Remote management begins.

15. Microsoft Entra authentication

16. User authenticates with organizational identity.

17. Intune enrollment

18. Device becomes managed and appears in inventory.

19. Security baseline

20. Compliance evaluates System Integrity Protection, password state, encryption, firewall, Stealth Mode, and Gatekeeper.

21. FileVault policy enables encryption and recovery-key escrow.

22. Identity

23. Platform SSO registration links the local macOS sign-in experience with Microsoft Entra according to the chosen authentication method.

24. Enterprise Wi-Fi

    • Trusted root certificate and client certificate are delivered.
    • WPA2-Enterprise / EAP-TLS profile connects the device to corporate wireless.

25. Applications

    • Required productivity/security applications install from Intune.

26. Operations

    • Help desk/admin teams use inventory, sync, restart, rename, retire, wipe, and reassignment workflows according to policy.

Validation checkpoints

A real deployment would not be marked complete until the following were observed on an enrolled Mac:

• ADE profile applied during Setup Assistant;
• Entra authentication succeeds;
• device appears in Intune;
• configuration profiles report success;
• FileVault is enabled;
• recovery key is escrowed;
• compliance reports compliant;
• required apps install;
• Platform SSO registration succeeds;
• enterprise Wi-Fi authenticates;
• lifecycle actions behave as expected.

Troubleshooting Runbook

Every troubleshooting scenario below distinguishes between actions that can be performed in Intune now and actions that require Apple Business Manager or an enrolled Mac.

Device not appearing in Apple Business Manager

Classification: SIMULATED / DOCUMENTED

Check:

1. Purchase source is an Apple-authorized reseller or Apple direct channel that supports ABM assignment.
2. Organization ID and reseller/customer identifiers are correct.
3. Device serial is eligible for automated assignment.
4. Reseller has assigned the device to the correct ABM organization.
5. ABM sync/import has completed.

Do not troubleshoot Intune until the device exists in ABM.

Device not synchronizing from ABM to Intune

Classification: SIMULATED / DOCUMENTED

Check:

1. Enrollment Program Token has not expired.
2. Token was created for the correct ABM MDM server.
3. Device is assigned to that MDM server in ABM.
4. Intune token sync completes without error.
5. Device serial appears under the correct token.

If the token has expired, renew the existing relationship rather than creating an unrelated replacement unless the relationship is intentionally being rebuilt.

ADE profile not assigned

Check:

• device exists under the Enrollment Program Token;
• device was synchronized after assignment;
• profile assignment scope includes the device;
• no competing assignment exists;
• profile is active.

Setup Assistant does not show expected panes

Check:

• device is actually using ADE;
• device has been erased/reset after the ADE assignment;
• latest ADE profile has synchronized;
• skipped Setup Assistant panes match the assigned profile;
• network access to Apple activation services is available.

APNs communication problems

REAL operational dependency

Check:

• Intune Apple MDM Push Certificate status;
• certificate expiration date;
• same Apple account ownership used for renewal;
• certificate was renewed rather than replaced;
• device can reach Apple Push Notification service.

Replacing instead of renewing the APNs certificate can sever management continuity and should be treated as a high-risk administrative change.

Company Portal / Entra authentication failure

Check:

• user can authenticate to Microsoft Entra;
• user is licensed for required Intune services;
• device time is correct;
• Conditional Access does not unintentionally block enrollment;
• Company Portal is supported on the installed macOS version;
• browser/web authentication completes successfully.

Platform SSO registration failure

Classification: SIMULATED / DOCUMENTED endpoint procedure

Check:

• supported macOS version;
• Company Portal / Enterprise SSO plug-in prerequisites;
• Platform SSO profile is assigned;
• extension identifier and team identifier are correct;
• user completed required registration;
• Entra sign-in logs for authentication failures;
• profile conflicts or duplicate SSO payloads.

FileVault not enabling

Check:

• FileVault policy assignment;
• device is supervised/managed as required by the chosen workflow;
• user has secure token capability where required;
• no conflicting FileVault payload exists;
• device has checked in after policy assignment;
• Intune per-setting status for policy errors.

FileVault recovery key not escrowed

Check:

• FileVault is actually enabled;
• recovery-key escrow policy is assigned;
• device has checked in after FileVault activation;
• personal recovery key exists;
• recovery key is visible in the authorized Intune recovery workflow;
• no policy conflict is present.

Never collect or publish the actual recovery key in portfolio evidence.

Compliance failure

Check each configured requirement individually:

• System Integrity Protection;
• password requirement;
• storage encryption;
• firewall;
• Stealth Mode;
• Gatekeeper state.

Use per-setting compliance status rather than guessing from the overall state.

Enterprise Wi-Fi failure

Check:

• SSID spelling;
• security type;
• EAP type;
• trusted root certificate;
• client certificate availability;
• certificate subject/SAN requirements;
• certificate EKU;
• RADIUS trust chain;
• device time;
• wireless controller/NPS/RADIUS logs.

For EAP-TLS, troubleshoot certificate trust and identity before user credentials because the design is certificate-based.

Application deployment failure

Check:

• app type matches packaging format;
• package is signed and compatible with the target macOS version;
• assignment is correct;
• detection logic/version metadata is valid;
• required privacy/system extension settings are deployed;
• device has checked in;
• Intune app install status and local logs.

Expired Enrollment Program Token

Renew through the existing Apple Business Manager server relationship and upload the renewed token to Intune. Confirm the device count and sync after renewal.

Device retirement

For user offboarding or BYOD-style management removal, prefer the least destructive action that satisfies the requirement. Preserve corporate data handling policy and confirm whether retire removes managed configuration without factory reset.

Lost or stolen device

Escalate according to organization policy. Evaluate wipe, lock-related capabilities, identity-session revocation, certificate revocation, and asset reporting. Do not execute destructive actions without identity and ownership verification.

Validation

Final validation matrix

Evidence interpretation

A screenshot proving that an Intune configuration surface exists is classified as capability validation, not endpoint implementation.

A policy object created in Intune is classified as REAL CONFIGURATION.

A result that requires an enrolled Mac is not marked validated unless an actual device reports the state.

Evidence index

See evidence/README.md and the live evidence gallery.