top of page
Search

Zero-Touch Onboarding: What AI Should Draft in Your Enrollment Profiles, and What It Shouldn't

Writer: MacSmithAI
MacSmithAI
Oct 20
6 min read

The enrollment profile is not a file you can hand to a model

Ask an AI assistant to "write me a zero-touch enrollment profile for macOS" and you will get something plausible back. It will also be the wrong artifact, because an Automated Device Enrollment profile is not a .mobileconfig file sitting in a repo — it is a record on Apple's Device Assignment Services, created through your MDM's console or Apple's API, and Apple's own documentation describes it as nothing more than "a profile's properties and their values."


In Intune the path is clicks, not syntax: Devices > Enrollment > Apple tab > Bulk Enrollment Methods > Enrollment program tokens > Add, download the Intune public key as a PEM file, upload it to Apple Business Manager under account profile > Preferences > MDM server assignments, download the resulting .p7m server token, and upload that back. Only then does Profiles > Create profile > macOS exist. Microsoft's prerequisite is blunt: "To create the profile, you must have an enrollment program token setup in Intune."


So the useful question is which of the surrounding decisions and artifacts AI can genuinely draft, and which ones will cost you a wipe if you let it guess.


The three settings you should never delegate

User affinity is a fork you choose once per profile. "Enroll without User Affinity" is for shared hardware, and Microsoft notes the consequence plainly: "The Company Portal app doesn't work on these types of devices." With affinity you pick an authentication method; Setup Assistant with modern authentication needs macOS 10.15 or later, with older devices falling back to legacy.


Await final configuration is the setting that makes zero-touch actually feel finished. Set to Yes — the default on new profiles — "just before the home screen loads, Setup Assistant pauses and lets Intune check in with the device." Apple's side of it "holds the device in the Setup Assistant to allow the device management service to apply any critical configurations." Neither Intune nor Setup Assistant enforces a minimum or maximum wait; Microsoft says most devices in its testing reached the home screen "within 15 minutes."


Locked enrollment is the one to be frightened of. Setting it to Yes will "disable the Mac settings in System Preferences and Terminal that allow users to remove the management profile" — Apple confirms that on a Mac this "prevents unenrollment from System Settings as well as from the profiles command-line tool," and that "a supervised device can't be unenrolled by the user." And Microsoft's own warning should keep it out of any generated draft: "you can't change this setting without wiping the device."


A model has no stake in that. You do.


Setup Assistant panes: where AI does real work

Intune exposes nineteen Setup Assistant panes you can Hide or Show on a macOS ADE profile, most carrying their own OS floor — Location Services (macOS 10.11+), Restore, Apple ID, Terms and Conditions, Touch ID and Face ID, Apple Pay, Siri, Diagnostics Data, Display Tone, FileVault, iCloud diagnostics, Registration, iCloud Storage, Appearance, Screen Time, Privacy, Accessibility, Auto unlock with Apple Watch and Terms of Address (13.0+). Apple's side of this is the skip-keys object — "the list of skip keys for setup panes," available since macOS 10.9.


This is a genuinely good AI task, because the hard part is not the list but the consequence next to each row. Hiding Accessibility, for instance, means "the user can't use the Voice Over feature," which is a policy decision, not a tidying-up one. And Show is weaker than it sounds: Microsoft notes the user "can still skip screens that don't require immediate action."


Apple's Auto Advance removes the user entirely: a supervised Mac on macOS 11 or later is "automatically configured without any user intervention, provided no other Setup Assistant panes are enabled," and the service must "create a managed administrator account and skip the account creation pane in Setup Assistant." That only works if the pane matrix is complete.


Have the model build that matrix with a consequence column — then check every version floor against Microsoft's page yourself, because an invented OS floor is exactly the kind of error that survives review.


The profiles that land after enrollment

This is where the payload-authoring work actually lives, and it is the same split that makes AI useful for generating Munki pkginfo: generate the facts from a tool, draft the judgement with a model.


Apple's own key definitions are short and precise. PayloadType is "the payload type, specified on each payload domain's reference page." PayloadIdentifier is "the reverse-DNS-style identifier for the payload," usually the profile's own identifier with an additional component appended. PayloadUUID is "the globally unique identifier for the payload," and "in macOS, use uuidgen to generate UUIDs." PayloadDisplayName, PayloadDescription and PayloadOrganization are human-readable and carry no behaviour at all.


The division of labour draws itself: the keys that change what the Mac does get copied or generated; the ones that merely describe the profile to a human are drafting work.


What goes into the profile

Where the value has to come from

Draft it with AI?

Payload type string

Apple's reference page for that payload

No - copy it

Key names inside a payload

The same page, or a manifest's pfm_name

No - copy it

PayloadUUID

uuidgen on a Mac

No - generate it

PayloadIdentifier

Your own reverse-DNS convention

Yes, from a stated convention

PayloadDisplayName, PayloadDescription

Your naming standard and what it does

Yes

Which payloads go in which profile

Policy, plus Apple's availability matrix

Yes, then check the matrix

Setup Assistant panes to hide

Intune's pane list and your policy

Yes, with a consequence column

Locked enrollment, deployment channel

A human decision, written down

No - not ever


# One UUID per payload, plus one for the profile. Never a model-invented string.
uuidgen

# Syntax gate, before the file goes anywhere near Intune.
plutil -lint CorpWiFi.mobileconfig

# Harsher second pass on a copy: the conversion fails on invalid syntax.
cp CorpWiFi.mobileconfig /tmp/check.mobileconfig
plutil -convert xml1 /tmp/check.mobileconfig

plutil -lint will "check the named property list files for syntax errors," and it is the default command option if none is specified. plutil -convert is the harsher second pass, because "if the file can't be loaded due to invalid syntax, the operation fails."


Syntax valid is not the same as deployable

Neither of those commands knows anything about MDM. A profile full of invented keys lints perfectly.


Apple publishes a per-payload availability matrix for exactly this reason, and it is the constraint models ignore most reliably. The Declarations payload, for example, is available on the device channel for iOS, macOS, tvOS, visionOS and watchOS but on the user channel only for macOS — and carries the flat statement that "a device management server can't install a configuration profile containing this payload type." No amount of valid XML gets around that. The community-maintained ProfileCreator manifests encode the same kind of rules in a checkable form: pfm_name for the key name, pfm_targets scoping it to user, user-managed, system or system-managed, and pfm_range_list as "an array of legal values for this key."


Intune will not save you here either. For macOS "the settings must be in an .xml or .mobileconfig file," the ceiling is 1000000 bytes, and device tokens such as {{serialnumber}} are accepted without checking: "the UI doesn't validate variables, and they're case sensitive." The Deployment channel is the other irreversible click — "after you select a channel and save the profile, you can't change the channel" — and "user-targeted payloads don't apply to devices enrolled without user affinity."


What this looks like across ten thousand Macs

Onboarding is the least forgiving thing a Mac admin automates, because the feedback loop is weeks rather than minutes. Intune runs a full sync with Apple "no more than once every seven days," an automatic sync every 24 hours, and will accept a manual sync "no more than once every 15 minutes." Devices released from Apple Business Manager can take "up to 45 days" to disappear from Intune.


At that scale you are not iterating. You review a pane matrix and a set of profiles once, ship them, and live with them until next September — which is precisely why the generated parts have to be the parts that don't change behaviour. The same discipline that works for shell scripts headed to ten thousand Macs applies: tool first, model second, human last.


The practical takeaway

Don't ask AI for an enrollment profile — that artifact lives in a console and a token, not in a file. Do use it for three specific jobs.


Have it draft the Setup Assistant pane matrix with a consequence column, built from Intune's own pane list, and verify every OS floor yourself. Have it draft the configuration profiles that land after enrollment — payload types and key names copied from Apple's reference or a ProfileCreator manifest, every PayloadUUID from uuidgen, plutil -lint as a non-negotiable gate before upload. And keep it away from locked enrollment and the deployment channel, the two settings that cost a wipe or a new profile to undo.


The rule that makes this work is the boring one: a model may write anything in the profile that a human would have typed from convention, and nothing that a device will actually obey.



Comments

bottom of page