Enrolling Apple Silicon Macs in Intune via No-Affinity ADE

Why the Enrolment Model Is the Decision That Outlives Every Other

When you bring Apple silicon Macs into Intune with Automated Device Enrolment, the first choice you make, whether a user is attached to the device or not, is the one you are least able to change afterwards. Everything downstream follows from it: how FileVault behaves, what holds the encryption credential, whether Platform SSO is even possible. Get it right and the build is calm. Get it wrong and the fix is to erase the machine and start again.

This is the end-to-end runbook for the no-affinity model: stage-and-post, where IT enrols and prepares the Mac and then hands the finished machine to a person. It is written from doing it repeatedly on real hardware, including the parts that went wrong, and it is deliberately command-heavy, because the single biggest difference between Intune and Jamf on macOS is that Intune's failures are quiet. Nothing errors. Things simply do not happen, and then happen eight hours later. The commands below are how you tell the difference between broken and pending.

User Affinity, and the One-Way Door

With user affinity, a directory user is bound to the device during Setup Assistant. With no affinity, the device enrols against the enrolment token and no user is bound to it at all. For stage-and-post, no affinity is the correct model.

The part that is not in the wizard: you cannot add affinity to a no-affinity Mac afterwards. Installing the Company Portal later does not create it. The device-staging flow that allows this on iOS and iPadOS has no macOS equivalent. In the device record, the option to change the primary user is greyed out for Macs. The only route is wipe and re-enrol.

Be clear-eyed about what no-affinity actually costs, because it is more than a missing sign-in prompt. Microsoft's position is blunt: the Company Portal app is not used, needed, or supported on enrolments without user affinity. So the device has no user identity at all. No Company Portal, no user-based Conditional Access, no Platform SSO. If that list makes you wince, you want affinity, and that is a different enrolment.

The Local-Account Build: Affinity Is the Lever, Not the Auth Method

This one cost me a wipe, so it is worth stating plainly. If you want the traditional local-account out-of-box experience, a user creating a local account at Setup Assistant with no directory sign-in, the instinct is to reach for the legacy Setup Assistant authentication method. In the current Enrollment policies experience, that option may not exist in the dropdown at all. Microsoft has been trimming the legacy choices, and on my tenant the authentication method offered exactly one item: Setup Assistant with modern authentication.

So the answer is not the auth method. The lever is user affinity. Turn affinity off and the authentication method becomes irrelevant, because there is no user to authenticate. Setup Assistant reverts to a standard local-account setup, the device still enrols and is still managed, and no directory prompt appears. That is the local-account build, reached by the affinity toggle rather than by picking a legacy method that is no longer on the menu.

One knock-on: any account settings that reference directory variables to prefill the primary account have no directory user to draw from when affinity is off. Check that section after you toggle affinity, and set the primary account to be created locally rather than prefilled from variables that will not populate.

Prerequisites, and the Check That Prevents the Worst Failure

Four things must exist before you enrol anything. Three are setup; the fourth is a check you will do every single time.

1. Devices assigned to your Intune MDM server token in Apple Business Manager, and synced.
2. An enrolment policy (built below), set as the token default. Automated Device Enrolment assigns policy by token, not by group. Microsoft is explicit that a device that syncs from Business Manager without an assigned enrolment policy will fail to enrol when someone powers it on. Set a default early.
3. Your groups and filter, because a device that enrols into nothing receives nothing.
4. Confirmation that this specific serial is synced under the token, before you wipe.

That last one is not ceremony. Get the serial first:

# On the Mac: get the serial you are about to look for in the console
system_profiler SPHardwareDataType | awk '/Serial Number/ {print $NF}'

Then find it in Devices → Enrollment → Apple → Enrollment program tokens → [your token] → Devices. It must be listed. If the token shows no synced devices, or this serial is missing, stop and sync before you erase anything.

Building the Enrolment Policy

Note there are two enrolment experiences and they are not the same. The older Profiles experience is being retired and will not receive new features; the current one is Enrollment policies. Build on the latter.

1. Go to Devices → Enrollment → Apple (or Devices → Device onboarding → Enrollment on newer tenants), select the macOS tab, choose Enrollment program tokens, open your token, then Enrollment policies → Create policy → macOS.
2. Basics. Give it a name and description. The name matters more than usual: you will reference it in a device filter later, so make it stable and do not rename it casually.
3. Management settings. Set User affinity = Enroll without User Affinity. Set Await final configuration = Yes: this holds the device at a locked Setup Assistant screen until the first sync installs your critical policies, and it is a hard prerequisite for forcing FileVault during Setup Assistant later. Set Locked enrollment = Yes so the user cannot remove management.
4. Account settings. This screen does more than it looks. Turning on Create a local admin account is what provisions the managed admin and hands its password to Intune's local admin password solution, so this single toggle is your entire break-glass admin story. Set the username and full name, set Hide in Users and Groups = Yes so it stays out of the login window day to day, and set a password rotation period (60 days is a reasonable choice; the default is longer).
   
   Then Create a local primary account = Yes, and set its account type to Administrator. Do not skim that one. The interactively created Setup Assistant account is the one that receives the SecureToken and becomes the FileVault user, and forcing FileVault during Setup Assistant requires an admin SecureToken user or the FileVault pane never appears at all. A standard primary account will quietly cost you encryption later.
   
   Finally, with affinity off there is no directory user to draw from, so any prefill that references directory variables has nothing to populate from. Set the account to be created locally rather than prefilled from variables that will resolve to nothing.
5. Setup Assistant. Set your department name and a contact detail (users see these, so make the contact one somebody can actually reach), then work the panes. The list is long and mostly consumer noise; the ones that matter for a staged build are these.
   
   Hide: Apple ID, Terms and conditions, Diagnostics data, Screen Time, Software Update, Terms of Address, and FileVault.
   
   Show: the rest, broadly, Location services, Restore, Touch ID, Apple Pay, Siri, iCloud diagnostics and storage, Appearance, Privacy, Accessibility, Auto unlock with Apple Watch, Lockdown mode, and the newer panes your macOS version offers. You can only toggle what the console lists, and that list shrinks and grows between releases, so do not be alarmed if it does not match a screenshot you saw elsewhere; the panes that are not listed simply take Apple's defaults.
   
   FileVault hidden is the one to be deliberate about. You are enforcing encryption by policy, so the user must never be offered the manual prompt. That single toggle prevents the entire mess documented in the FileVault guide, where a hand-enabled key is one your management cannot escrow. Hiding Apple ID is worth a note too: it is right for a local-account build, and it is the pane you would revisit if you later move to a directory-backed identity.
6. Save, then set the policy as the token default.

Groups, Filters, and the Two Lag Points

Two kinds of group, two jobs. A broad dynamic device group carries the configuration every corporate Mac should get. Build it under Groups → New group, type Security, membership type Dynamic Device, and write the rule:

// The dynamic membership rule for company-owned Macs
(device.deviceOSType -eq "MacMDM") -and (device.deviceOwnership -eq "Company")

Do not take my word for the token, or anyone else's. The rule builder has a validation feature: give it a device and it tells you which clause passed and which failed. That is the difference between knowing and guessing, and it turns this from an afternoon into thirty seconds. Use it on both clauses, the OS type and the ownership, because a device that is the right platform but has come in with the wrong ownership fails just as silently.

Then check the group actually has members before you debug anything downstream of it. An empty group is the single most common explanation for "my configuration is not applying".

Static per-site groups carry the things that genuinely differ: naming, per-site wireless, anything narrow.

Now the timing, which is the thing nobody warns you about and the reason Intune feels broken when it is merely slow. There are two lag points stacked on top of each other between a device enrolling and your configuration arriving:

1. Dynamic group evaluation. The device enrols, becomes a company-owned Mac, and Entra re-evaluates the membership rule. This is usually minutes, but it can be hours, and Microsoft's guidance allows up to 24 hours in the worst case. Until it lands in the group, nothing targeted at that group can reach it.
2. Agent check-in. Once it is in the group, the management agent still has to check in before scripts run. The default check-in is every 8 hours.

So on a fresh enrolment, do not expect the rename to happen in the first five minutes. It will come. This is the single biggest cultural difference from Jamf, where a policy at enrolment is effectively immediate. Both lags are forceable during staging (see forcing things to happen sooner), but you have to know they exist or you will start "fixing" something that was only ever pending.

The chicken-and-egg, and the filter that solves the other half

You will hit this immediately: you want to scope a script to a group, but the machine has not enrolled yet, so it is not in any group and cannot be added to a static one. The answer is to scope post-enrolment things to the dynamic group. The script does not apply during enrolment anyway; it only needs the device to be in the group by the time the agent checks in, and the dynamic group auto-populates once the device exists. The dynamic group is precisely the tool for "I do not have the device yet but I want configuration waiting for it".

But some policies must be evaluated before the desktop appears, during Setup Assistant, and dynamic groups evaluate far too late for that. This is not an abstract concern, and it is worth following the chain, because it is the cause of the most-reported FileVault failure on this whole build:

1. You assign the FileVault policy to the dynamic group, which is the obvious thing to do.
2. A no-affinity device joins that group only after it enrols, because it does not exist as an object before then.
3. So during Setup Assistant, the FileVault policy is not on the device.
4. So Force Enable In Setup Assistant has nothing to fire from, and encryption silently falls back to the deferred path.
5. And you conclude the Force Enable setting is broken, when the setting was never the problem. The targeting was, and the group-evaluation lag is why.

The fix is to assign such policies to All devices with a filter. Create it under Tenant administration → Filters, platform macOS, with a rule matching on the enrolment profile name:

// Device filter: only Macs that came in through your ADE policy
(device.enrollmentProfileName -eq "<your enrolment policy name>")

Assigned this way the policy is present from the first moment of Setup Assistant, so forcing actually fires. And as a bonus it excludes personal devices automatically, because a personal device never carries your corporate enrolment profile and so never matches the filter. No separate exclusion needed. This is also why I said to pick a stable enrolment policy name and not rename it casually: this filter is a string match against it.

Naming: There Is No Template, and the 15-Character Wall

Start with the finding that saves you an hour of hunting through the console: macOS Automated Device Enrolment has no device name template. Windows has one. iOS and iPadOS have one. macOS does not, in either the old or the new enrolment experience. If you are looking for the field, stop; it is not there and its absence is not a mistake in your tenant.

You script it instead, with scutil. And there is a direction-of-travel detail worth internalising: the local name propagates up to the console. It is not pushed down from it. Set the name locally and let the console reconcile on its own schedule.

The 15-character arithmetic

Device names are capped at 15 characters, and this will force a compromise in your naming convention. Do the maths before you commit, not after you see truncated names. Get a real serial first:

# How long is a serial in your fleet, really?
system_profiler SPHardwareDataType | awk '/Serial Number/ {print $NF}' | tr -d '\n' | wc -c

Say it comes back as 10 characters. Now the options, using a fictional org prefix CORP and a site code NW:

• CORP-NW-<serial> = 8 + 10 = 18 characters. Over the limit.
• CORP-<serial> = 5 + 10 = 15. Fits exactly, but loses the site distinction.
• NW-<serial> = 3 + 10 = 13. Fits, keeps the site code and the full serial.
• CORP-NW-<last 8 of serial> = 8 + 8 = 16. Still over unless you trim harder.

The org prefix earns the least, because every machine in the fleet is the same org. The site code earns the most, because it is the actual differentiator. So NW-<serial> wins: it keeps the site, keeps the full serial as a unique hardware identifier you can look up with Apple, and fits comfortably. That is the compromise the 15-character limit forces on you, and it is tighter than people expect.

The script

One script per site, with the prefix hardcoded, scoped to that site's static group. The alternative, one clever script that geolocates by IP address, is a bad idea for something as sticky as a device name; geolocation is wrong often enough to matter and you will be renaming machines by hand to fix it.

#!/bin/bash
# Set device name to NW-<serial>. Runs as root via the management agent.

appname="DeviceRename"
logdir="/Library/Logs/Microsoft/IntuneScripts/$appname"
log="$logdir/$appname.log"
prefix="NW"

mkdir -p "$logdir"

serial=$(system_profiler SPHardwareDataType | awk '/Serial Number/ {print $NF}')

if [ -z "$serial" ]; then
  echo "$(date) | ERROR: could not read serial, aborting." >> "$log"
  exit 1
fi

newname="${prefix}-${serial}"

scutil --set ComputerName "$newname"
scutil --set HostName "$newname"
scutil --set LocalHostName "$newname"
dscacheutil -flushcache

echo "$(date) | Set device name to $newname" >> "$log"
exit 0

Three details that matter. It sets all three names, because setting only ComputerName leaves the host name stale and things that read it will disagree with the console. It runs as root, so there is no sudo inside it, the agent already runs it as root and sudo inside an agent script causes its own problems. And it logs to a predictable path, which becomes your evidence later.

Deploy under Devices → macOS → Scripts → Add: upload it, set Run script as signed-in user = No, script frequency Not configured (once is right for a build; set a frequency only if you want it to self-heal a renamed machine), retries 3, and assign to the site's group.

Then verify locally rather than trusting the console, which will lag:

# Did the name actually get set?
scutil --get ComputerName
scutil --get HostName
scutil --get LocalHostName

# Did the script run at all? Its log folder is the evidence.
ls -la /Library/Logs/Microsoft/IntuneScripts/DeviceRename/
cat /Library/Logs/Microsoft/IntuneScripts/DeviceRename/DeviceRename.log

Enrolling: What You Should See, in Order

For a genuinely clean build, reinstall macOS via Recovery rather than using the built-in erase. An Erase All Content and Settings is a logical wipe, not bare-metal, which is fine for most purposes but not when you want certainty that no prior state is influencing your validation. Boot to Recovery, erase the volume in Disk Utility, reinstall. It re-enrols automatically.

Have Wi-Fi details to hand; the Remote Management step needs the internet or Automated Device Enrolment cannot kick in and you will get the consumer setup instead.

Then watch for these, in order:

1. Setup Assistant starts. Language, region, Wi-Fi.
2. The Remote Management screen appears, and it names your organisation. This is the tell that Automated Device Enrolment worked. If it names your org, the token and policy are right. If you see a normal consumer setup with no Remote Management screen, or it says the device is owned by an unknown organisation, stop: the serial was not synced under the token and no amount of continuing will fix it.
3. No directory sign-in prompt, because affinity is off. If you get one, your affinity setting did not take.
4. Setup Assistant panes per your configuration, with FileVault hidden.
5. Local account creation, as Administrator.
6. The awaiting-final-configuration hold, from Await final configuration = Yes.
7. Desktop.

Getting to the desktop is the fast part. The machine being fully configured is the slow part, and that is the two lag points doing their thing, not a failure.

Verifying the Build from the Command Line

Verify each link rather than assuming. This is the sequence I run on every fresh build.

Confirm the accounts exist, including the managed admin:

# All local accounts (filters out the system ones)
dscl . list /Users | grep -v '^_'

# Specifically, did the managed admin account get created?
dscl . list /Users | grep <admin-account>

# Is it hidden from the login window, as configured?
dscl . read /Users/<admin-account> IsHidden

Confirm the enrolment and the profiles that landed:

# Is the machine actually enrolled, and is the bootstrap token escrowed?
sudo profiles status -type enrollment
sudo profiles status -type bootstraptoken

# Which configuration profiles actually arrived?
sudo profiles list
sudo profiles show

Confirm the cryptographic state, which is where the no-affinity model gets interesting. The first account to log in interactively becomes the SecureToken holder and the FileVault user. The managed admin account, by Microsoft's own design, does not get a token. Prove it rather than believing me:

# Who holds a SecureToken? Run for each account.
sysadminctl -secureTokenStatus <primary-account>
sysadminctl -secureTokenStatus <admin-account>

# Who can actually unlock FileVault at pre-boot?
sudo fdesetup list

# Is FileVault on, and is the disk recoverable?
fdesetup status
sudo fdesetup haspersonalrecoverykey

That last command deserves a note of its own, because it is the one that will keep you calm on a bad day. haspersonalrecoverykey returning true means a valid personal recovery key exists and the disk is recoverable, regardless of what the console is showing you. When the console dropped the recovery key from view during my build and it looked for all the world like the key had evaporated, this command was the thing that proved the data was safe and stopped a panic turning into a genuinely destructive "fix". Learn it before you need it.

Confirm the console side: the device shows as Corporate, not owned by an unknown account (this matters later, because admins can only view recovery keys for Corporate devices), it has joined the dynamic group, and it is in its site static group.

Forcing Things to Happen Sooner

Intune has no true equivalent of a Jamf policy trigger you can fire on demand. What it has are three levers, each with caveats, and during staging you will use all of them.

# Lever 1: kick the management agent (this is the one that runs scripts)
sudo killall IntuneMdmAgent

# Lever 2: nudge the MDM channel, and prod the console to reconcile
sudo profiles renew -type device
sudo profiles renew -type enrollment

Lever 3 is the admin-centre Sync action on the device, or, on an affinity build, Check status in the Company Portal. On a no-affinity build the Company Portal is not available to you, which removes one of the usual levers and is worth knowing before you go looking for it.

Note what these do and do not touch. Killing the agent makes it restart and check in, which is what pulls scripts down; it does nothing for dynamic group evaluation, so if the device is not yet in the group, the script has nothing to arrive from. Renewing the enrolment profile nudges the console. And local name resolution is a separate thing again:

# Refresh LOCAL name resolution after a rename (does nothing for the console)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

The Post: Handing the Machine Over

This model is called stage-and-post, and almost every write-up of it, including my earlier drafts, covers the staging and then simply stops, as though the machine teleports to the user and works. The post half has its own decisions, and one of them is a genuine trap.

What you are handing over is a Mac with a local administrator account that you created during Setup Assistant, with a password you set. There is no directory user bound to it and no Company Portal, so there is no sign-in ceremony on the far end. The user opens the lid and logs in with the credentials you give them. That is the whole handover, which is precisely why it scales.

Before it leaves your hands, confirm the machine is actually finished rather than merely booting:

# Is it encrypted and is the key real? (the console should also show the key by now)
fdesetup status
sudo fdesetup haspersonalrecoverykey

# Did it get its name, and did the naming script actually run?
scutil --get ComputerName
ls -la /Library/Logs/Microsoft/IntuneScripts/DeviceRename/

# Did the configuration land, or is the device still waiting on a check-in?
sudo profiles list | wc -l

Remember the two lag points here. A machine posted the same hour it was built may still be waiting on group evaluation and an agent check-in, so its apps and scripts land at the user's desk rather than yours. That is not a fault, but it is a support call if nobody warned them. Either force the check-in before it ships, or tell the user the first hour is a settling-in period.

The second thing worth putting in that handover note is that the break-glass admin account exists and will appear at the pre-boot screen after a reboot. Users notice an unfamiliar account name on their new laptop and, quite reasonably, report it as suspicious. Telling them beforehand costs nothing and saves a ticket that is genuinely difficult to close politely.

Rebuilding and Retiring a Device

You will do this constantly during the pilot and occasionally forever after, so it is worth being precise about which button does what, because the words all sound similar and two of them are not reversible in the way you would like.

• Wipe (the device action) erases the Mac and, because the device is still assigned to your token in Business Manager, it comes back through Automated Device Enrolment on the next boot. This is the normal rebuild.
• Reinstall via Recovery is the bare-metal version, and the one to use when you want certainty that nothing residual is influencing a test. It also re-enrols automatically. Slower, and worth it for validation work.
• Delete the object from Intune removes the record. Do this only alongside a wipe, or you get a managed machine with no record, which is its own small nightmare.
• Remove the device from Business Manager is the one to leave alone. It breaks the token assignment, so Automated Device Enrolment stops working for that machine and you are back to manual enrolment. This is almost never what you want, and it is easy to do by accident while tidying.

After every rebuild, the one thing that will bite you: the device returns as a new object with a new device ID, so it loses its static group memberships. Dynamic groups re-add it automatically. Static ones do not, and your naming script is scoped to a static group, which is why naming mysteriously stops working on rebuilt machines. Re-add it. Every time.

Troubleshooting and Gotchas

The Mac enrolled but is owned by an unknown account

The serial was not synced under the token at the moment of enrolment, so the device was never properly associated with your tenant and came up effectively unmanaged. There is no on-device repair, the association had to exist on Apple's side before the machine phoned home. Confirm the serial is listed under the token, then wipe and enrol again. The tell during Setup Assistant is the Remote Management screen: if it does not name your organisation, abandon the run there rather than completing a build you are going to throw away.

A device enrolled cleanly and received none of its configuration

Check the dynamic group has members before anything else. The overwhelmingly likely cause is the case-sensitive OS-type value in the membership rule being the friendly name rather than the managed-Mac token, in which case the group is empty and every policy assigned to it is silently doing nothing. Correct the rule and the group populates within a few minutes. Nothing errors in this failure mode, which is exactly why it is worth checking first rather than last.

The naming script never ran on a rebuilt machine

This is the one that taught me the lesson. After a rebuild, naming simply did not happen, and I went hunting for a bug in the scutil script. The script was fine. A re-enrolled device comes back as a brand-new object and loses all its static group memberships. Dynamic groups re-evaluate and re-add automatically; static groups do not, because membership was assigned and nobody reassigned it. The script was scoped to the static site group, the rebuilt device was no longer in it, so the script was never targeted at the machine at all.

The evidence that pointed at the truth was an absence: the log folder the script writes to had never been created.

# No folder = the script never fired = it is a targeting problem, not a code problem
ls -la /Library/Logs/Microsoft/IntuneScripts/DeviceRename/

If the folder is missing, stop debugging the script and go look at group membership. After any rebuild, re-add the device to its static group.

Nothing has happened and I cannot tell if it is broken or pending

Almost always pending, and this is the single most common false alarm on a first Intune build. Work through it in order rather than guessing: is the device in the dynamic group yet (evaluation can take minutes to hours)? If yes, has the agent checked in since (default every 8 hours)? Force it with killall IntuneMdmAgent and give it a few minutes. Only if the device is in the group, the agent has checked in, and the thing still has not landed do you have an actual fault. Coming from Jamf, where enrolment policies fire effectively immediately, this waiting feels like failure. It is not.

The console shows a stale device name

The console reconciles on its own timeline, so a correctly renamed machine can display its old name for a while. Confirm the truth locally with scutil --get ComputerName; if that is right, the rename worked and the console is simply behind. profiles renew -type device nudges it. Flushing the DNS cache does nothing for this, that only affects local name resolution on the machine itself.

The recovery key and the managed admin password vanished from the console

Before you do anything drastic, run sudo fdesetup haspersonalrecoverykey. If it returns true, your disk is recoverable and you are not locked out, whatever the console is showing. The console view genuinely can drop these transiently, especially right after a device record update such as a rename reconciliation, and it can also refuse to show them if the device is not marked Corporate, because admins can only view recovery keys for Corporate devices.

The important part is what not to do. Do not reach for fdesetup changerecovery to "fix" a display problem. It generates a brand-new personal recovery key and invalidates the old one, including the copy that was escrowed. If it does not complete, nothing changed and you got lucky. If it does complete, you have just turned a cosmetic console glitch into a real unescrowed-key incident. I attempted this during my build and the only reason it did no harm is that it refused to run. Acting on a display glitch is how you create the very problem you were worried about.

Ghost device objects pile up during testing

Every wipe-and-re-enrol can create a new device object with a new device ID, so a machine you have rebuilt several times leaves a trail. This matters more than it sounds: if a duplicate record exists, escrowed items live on the old object and the new one shows none, which looks exactly like data loss. Check whether there is one record for the machine or two before concluding anything has been lost. Delete stale objects only once confirmed orphaned, and note that deleting from Intune is not the same as removing from Business Manager. Leave the Business Manager assignment and the enrolment profile alone or Automated Device Enrolment stops working entirely.

The pilot's management state degraded after a day of experimentation

Worth saying, because you will hit it and it is not a fault in your design. After enough wipes, enrolment-model changes, duelling scripts and policy conflicts on one device, its managed state goes genuinely inconsistent, console commands start failing, and the temptation is to firefight it button by button. Do not. That degraded state is an artefact of experimentation, not evidence your configuration is wrong. The pilot's job is to surface failure modes, and it has done it. A clean rebuild from a settled configuration resolves all of it at once, because the machine starts from a consistent state.

The Command Reference

Everything above, collected. Run on the Mac as an admin.

Group and filter rules (console, not shell)

// Dynamic device group: company-owned Macs
// MacMDM, NOT macOS. Case-sensitive. This is the one that empties your group.
(device.deviceOSType -eq "MacMDM") -and (device.deviceOwnership -eq "Company")

// Device filter: Macs that came in via your ADE enrolment policy
// Use this to target policies that must land DURING Setup Assistant (e.g. FileVault)
(device.enrollmentProfileName -eq "<your enrolment policy name>")

Identity and hardware

# Serial number
system_profiler SPHardwareDataType | awk '/Serial Number/ {print $NF}'

# Serial length (for the 15-character naming maths)
system_profiler SPHardwareDataType | awk '/Serial Number/ {print $NF}' | tr -d '\n' | wc -c

# Hardware overview
system_profiler SPHardwareDataType

Enrolment and profile state

# Is it enrolled, and how?
sudo profiles status -type enrollment

# Bootstrap token escrowed? (this is what grants SecureToken to later accounts)
sudo profiles status -type bootstraptoken

# Which profiles actually landed
sudo profiles list
sudo profiles show

# Full profile export WITH payload values (see the config-audit guide)
sudo profiles -P -o stdout-xml > profiles-full.xml

Accounts

# Local accounts, excluding system accounts
dscl . list /Users | grep -v '^_'

# Does a specific account exist?
dscl . list /Users | grep <account>

# Is it hidden from the login window?
dscl . read /Users/<account> IsHidden

# Hide an account from the ordinary login window
sudo dscl . create /Users/<account> IsHidden 1

# Is an account's password clean and directly usable? (exit 0 = yes)
dscl . -authonly <account> '<password>' ; echo $?

SecureToken and FileVault

# Does this account hold a SecureToken?
sysadminctl -secureTokenStatus <account>

# Who can unlock FileVault at pre-boot?
sudo fdesetup list

# Is FileVault on?
fdesetup status

# THE reassurance command: is the disk recoverable? (true = yes, you are safe)
sudo fdesetup haspersonalrecoverykey

Naming

# Read the current names
scutil --get ComputerName
scutil --get HostName
scutil --get LocalHostName

# Set all three
sudo scutil --set ComputerName "NW-<serial>"
sudo scutil --set HostName "NW-<serial>"
sudo scutil --set LocalHostName "NW-<serial>"

# Refresh local name resolution (local only, not the console)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Forcing a check-in

# Kick the agent (this is what pulls scripts down)
sudo killall IntuneMdmAgent

# Nudge the MDM channel / console reconciliation
sudo profiles renew -type device
sudo profiles renew -type enrollment

Script evidence

# Did a script run? Its log folder existing is the evidence.
ls -la /Library/Logs/Microsoft/IntuneScripts/
cat /Library/Logs/Microsoft/IntuneScripts/DeviceRename/DeviceRename.log

# Is the agent even installed?
ls -la "/Library/Intune/Microsoft Intune Agent.app"

Quick-Action Checklist

1. Assign devices to your Intune token in Business Manager and sync.
2. Confirm the serial appears under the token before every wipe.
3. Create the enrolment policy in the current Enrollment policies experience, not the retiring Profiles one.
4. Set Enroll without User Affinity (this, not the auth method, is the local-account lever), Await final configuration = Yes, Locked enrollment = Yes, FileVault pane hidden, and the primary account = Administrator (required for the SecureToken, and therefore for FileVault).
5. Set the policy as the token default. No assigned policy means enrolment fails.
6. Build the dynamic group with deviceOSType -eq "MacMDM" (not macOS, case-sensitive) and deviceOwnership -eq "Company". Use the rule validation feature to confirm both clauses pass, then check the group actually has members.
7. Build the site static group for naming.
8. Create a filter on the enrolment profile name for boot-critical policies. Remember scripts cannot use filters.
9. Work out your naming against the 15-character limit using a real serial, then deploy the scutil script as root, once, scoped to the site group.
10. Reinstall via Recovery for a clean test; watch for Remote Management naming your org; do not enable FileVault manually.
11. Re-add the device to its static group after every rebuild.
12. Before posting: confirm encryption, name and profiles landed, and force a check-in so the machine settles on your desk rather than the user's.
13. In the handover note, tell the user to change their password only in System Settings, and that the admin account at the pre-boot screen is expected.
14. Verify from the command line: accounts, profiles status, sysadminctl -secureTokenStatus, fdesetup list, fdesetup status, name, log folder.
15. Before calling anything broken: is it in the group, has the agent checked in, have you forced it? Then judge.

Closing Thoughts

No-affinity Automated Device Enrolment is a clean, scalable way to build Macs for a stage-and-post workflow, provided you go in clear-eyed about two things. The affinity choice is permanent without a wipe, and it costs you more than a sign-in prompt, so decide it deliberately before you enrol rather than discovering the constraint later. And the failures here are quiet: an empty dynamic group, a lost static membership, a script that never ran all present as "nothing happened" rather than as an error, which is precisely why this guide is so command-heavy. The console will not tell you. The machine will.

Get the group token exactly right, learn the two lag points so you stop mistaking pending for broken, treat a missing log folder as the alarm it is, and keep fdesetup haspersonalrecoverykey in your back pocket for the day the console frightens you. Do that and the build becomes genuinely repeatable, which, after enough rebuilds, is a very satisfying thing to watch.

---

← All guides