Capacities
The capacities listed below are the ones that are currently actively supported by MacOnboardingMate.
The specific capacities that require the purchase of a MOM Switch license are marked Switch.
Any idea to enrich MOM capacities or being able to adopt MOM ? Feel free to send a feature request via the form available on the Introduction page.
| Terminology | |
| Execution modes | • MOM is delivered as a unique package named « MOM-Core » that offers two execution modes differentiated by the way MOM is launched and the workflows supported • In Launcher mode, MOM is executed manually from an opened user’s session • In AutoLauncher mode, MOM is executed from a management solution, either automatically or from a Self Service |
| Workflows supported | • Launcher mode is used to onboard or to migrate from one MDM to another MDM a Mac that is already in production ; the workflow is triggered locally • AutoLauncher mode is used to onboard a new or resetted Mac enrolled during the Setup Assistant (1), or to migrate a Mac that is already in production from one MDM to another MDM ; the workflow is triggered remotely |
| Locations | • A MOM Location refers to the destination point of the device once enrolled in the management solution • Depending on the management solution, a MOM Location can be seen as a site or a device group • Device Enrollment : the targeted Location is defined automatically (one Location available) or manually with a selector (two or more Locations available) • Automated Device Enrollment : the targeted Location is defined automatically |
| Enrollment methods | • Both Launcher and AutoLauncher modes offer to use Device Enrollment (no-ADE capable Mac) or Automated Device Enrollment (ADE capable Mac) (2) to enroll a Mac in an MDM • In the specific workflow of an onboarding during the Setup Assistant, MOM does not orchestrate the enrollment which is already managed by the Automated Device Enrollment • Aside this last workflow, MOM orchestrates the enrollment in the context of a first onboarding, or the unenrollment from the previous MDM followed by the enrollment in the new MDM in the context of a migration |
| Onboarding | |
| Provisioning (AutoLauncher mode only) |
• In the context of an onboarding from the Setup Assistant (Automated Device Enrollment), « User-driven » and « White glove » provisioning are offered • User-driven provisioning : non-interactive tasks are started behind the scenes during the Setup Assistant, then interactive tasks are executed in an opened user’s session • White glove provisioning : all tasks are executed during the Setup Assistant, then the computer is expected to shut down • MOM White glove provisioning combined with macOS Automated Device Enrollment offers a similar experience as Windows Autopilot for pre-provisioned deployment |
| MDM enabled user (Launcher mode only) |
• The MDM enabled user is basically the logged in user during the enrollment or the user created in the Computer account pane of the Setup Assistant (Automated Device Enrollment only) • The MDM enabled user is the only user on the device to be able to receive User-level Configuration profiles (User Channel) • In the context of a 1:1 deployment with an enrollment orchestrated outside of the Setup Assistant, the technician can be asked to validate that MOM is correctly executed from the session of the targeted MDM enabled user |
| Computer Use Agreement | The organization can ask the user to accept certain agreement conditions to use the device |
| Administrative privileges grant | • MOM can automatically grant the logged in standard user the administrative privileges required by macOS for the enrollment in the new MDM or the SecureToken grant to the management account created • Once the targeted action is done, the granted privileges are revoked • For an enrollment using Device Enrollment, the grant occurs after the display of the enrollment Web page or the opening of the enrollment application, until the enrollment is done • For an enrollment using Automated Device Enrollment with macOS 11 and later, the grant occurs just before the display of the enrollment notification, until the enrollment is done • For an enrollment using Automated Device Enrollment with macOS 10.15 and earlier, the grant occurs for a few seconds only at the time the enrollment notification is displayed • The elevation of privileges is always actively monitored by an autonomous daemon which revokes the grant if the workflow is detected as interrupted |
| Power management | • The workflow execution can require that the device be connected to AC Power • The workflow can be allowed to be executed while the device is on Battery Power and optionally only if the battery charge exceeds a required minimum |
| Find My Mac management | • The workflow on a Mac with Apple silicon or equipped with a T2 Security Chip can require that the Find My Mac feature be disabled before enrollment in the MDM so that it can manage User-based activation lock • The workflow may require or suggest that the Find My Mac feature be enabled after enrollment in the MDM |
| Migration | |
| MDM switching Switch |
• The MDM migration implies the assisted unenrollment from the previous MDM before the enrollment in the new MDM • The MDM migration is configured in the targeted MOM Location property list file • In the context of AutoLauncher mode, the MDM migration is all set up in the MDM that the device leaves |
| Copy of inventory values Switch |
• The copy of inventory values during the exodus is based on the declaration of mappings that associate carefully the name of a source attribute in the previous MDM with the name of a destination attribute in the new MDM • All migrated values are eventually treated as strings |
| Triggering Switch |
• The user can be offered to postpone the migration workflow so that it is triggered at an appropriate time with an optional deadline • The migration process is actively monitored by an autonomous daemon that is responsible for reactivating the migration workflow if it is unexpectedly interrupted • The migration process can be automatically postponed when a process defined in a list is detected so that it is not executed or offered unexpectedly during a meeting • The migration process can be restricted to a list of accounts to prevent a management account from running the migration workflow and thus inadvertently becoming the MDM enabled user |
| Scheduling Switch |
• The migration process can be restricted to allowed time slots, aimed to reflect the availability of the IT Support • A migration slot is defined for each day by one or several ranges of time • Each migration slot is intended to be associated with a specific time zone, except the fallback migration slot that applies to all devices which time zone is not supported |
| Transparent Device Unenrollment Switch |
• MOM can remove an Automated Device Enrollment Remote Management profile protected by the « prevent unenrollment » option by making an API call to the MDM the device leaves • This capacity is currently only offered by FileWave, Hexnode UEM, Jamf Pro, Jamf School, JumpCloud, Microsoft Intune, SimpleMDM and VMware Workspace ONE UEM • In this situation, with the other supported MDM, the workflow is paused until the unenrollment is manually triggered by the IT Support |
| Wi-Fi configuration at unenrollment Switch |
• The configuration offers to join a fallback network secured with WPA, WPA2 and WP3 Personal modes. • The configuration is triggered when the Internet connectivity cannot be verified after unenrollment. • The configuration the creation of the Wi-Fi service if it is missing, the enablement of the Wi-Fi service if it is disabled, the powering of the Wi-Fi interface if it is off. |
| FileVault PRK reissuance Switch |
• The FileVault PRK can be reissued automatically once the device is enrolled in the new MDM • The reissuance requires the new MDM to provide the device with an FDERecoveryKeyEscrow configuration upon enrollment |
| Basic configurations | |
| Boot volume name | The Boot volume can be renamed silently to a defined arbitrary name |
| Desktop picture | • The Desktop picture can be customized with a wallpaper provided by your organization (PNG file) • The setting is executed at login via the Login script |
| Dock | • The Dock can be customized to add the Self Service app icon and to remove unwanted macOS apps icons • The setting is executed at login via the Login script |
| Firmware password | The Firmware password of an Intel Mac can be set silently to a defined arbitrary string |
| Python | A version of Python 3 can be dynamically downloaded from GitHub and installed during the workflow |
| Rosetta 2 | Rosetta 2 that enables a Mac with Apple silicon to run Intel apps can be installed |
| Time Zone | The Time Zone can be set silently to a defined one when Location Services are disabled |
| Log out, restart and shutdown | • A log out, restart, restart followed by a deletion of local accounts other than the management account command, or shutdown can be executed at the end of the workflow • When this command is not specified, automatic opening of an application and/or a Web page is possible |
| Automatic opening of an application | An app that will likely be the Self Service app of the management solution can be opened once the workflow is done |
| Automatic opening of a Web page | A Web page can be opened by the default Web browser of the logged in user once the workflow is done |
| Device renaming | |
| Renaming methods | • Prompt : the user is prompted to enter the device name • Template : the device name is composed with arbitrary text and Product Name and/or Serial Number informations • CSV : the device name is retrieved from a Serial Number / Device name CSV table stored inside the Content package |
| Device name case | A lowercase or uppercase conversion can be enforced whatever renaming method is used |
| Device name length | • A maximal length can be enforced whatever renaming method is used • This policy will typically prevent a distortion between the local computer name and the Active Directory computer record name limited to 15 characters |
| Management account | |
| Account creation (Launcher mode) |
• The defined management account is created at enrollment if missing • The management account parameters include Account name, Full name, UID, Shell, Home folder, Password and Hidden flag |
| Account creation (AutoLauncher mode) |
• The defined management account is created if missing after the Automated Device Enrollment sequence • The management account parameters include Account name, Full name, UID, Shell, Home folder, Password and Hidden flag |
| SecureToken grant | • The management account can receive a SecureToken from an administrator account that has one • This administrator account can be the logged in user if it has a SecureToken and is an administrator (after an elevation of privileges if allowed) • Otherwise this administrator account is to be selected from the other administrator accounts that have a SecureToken and whose password is known |
| FileVault enablement | The management account can be added to the list of users allowed to unlock the device or inversely, can be removed from this list |
| Account picture | The management account can be customized with a picture provided by your organization (PNG file) |
| Delete other local accounts | • If the management account exists at the end of the workflow, all the other local accounts can be deleted • One use case is the preparation of a no-ADE capable Mac by a technician who sets up a temporary Computer account manually in the Setup Assistant while the Management account creation is automated for its credentials reliability |
| Directory integration | |
| Integration with an Identity Provider | MOM has been designed to work effectively with Jamf Connect, Mosyle Auth 2 and XCreds. These tools replace the macOS login window by a customized login window that authorizes the sign in with an account managed by an Identity Provider for a just-in-time local account creation. |
| Modern On-Prem AD integration | MOM has been designed to work effectively with NoMAD Login. This tool replaces the macOS login window by a customized login window that authorizes the sign in with a Microsoft AD account for a just-in-time local account creation. |
| Traditional On-Prem AD integration | • The device can be bound traditionally to an Active Directory server to implement mobile accounts • As part of a support action, Agnosys can provide you with a traditional integration script and assist you in its customization • The use case is the workflow that plans that the binding is not done via the Directory payload of a Configuration profile provided by the MDM, but by a script executed once the device has been renamed |
| Other products integration | |
| Slack / Microsoft Teams | • MOM can report to a dedicated channel the successive status of a device’s onboarding or migration • Messages are sent when the workflow is started and exited, when the EULA is agreed, when the device is enrolled and unenrolled, when the device must be unenrolled from the console of the MDM solution it leaves and when administrative privileges are granted and withdrawn • Messages can be customized with strings, expected variables and emojis • This integration requires the implementation of Slack Incoming Webhooks and Microsoft Teams Incoming Webhooks |
| Homebrew | • Homebrew allows installing of packages at the time of onboarding • Installations happen during the workflow with a graphical user interface to display a progression • Homebrew is dynamically downloaded from the editor’s website |
| Installomator | • Installomator allows installing of the latest available versions of software at the time of onboarding • Installations happen during the workflow with a graphical user interface to display a progression • Installomator is dynamically downloaded from GitHub |
| Munki | • Munki is a set of tools, used together with a webserver-based package repository, that are implemented in organizations all over the world to manage software installs on macOS devices (3) • In the specific workflow of an onboarding during the Setup Assistant, an initial Munki Check-in is executed as desired to install as soon as possible the most critical apps once the first end user logs in (with a graphical user interface to display a progression) or silently in background • Aside this last workflow, an initial Munki Check-in is executed as desired once the workflow is completed or once the end user logs out • Munki is seen as an auxiliary tool and the configuration of the Munki agent is supposed to be performed by a MDM Configuration profile • Munki is dynamically downloaded from GitHub |
| NoMAD | • NoMAD is a tool that let local accounts sign in with their AD account essentially to get Kerberos tickets at login and keep their local password synchronized with their AD password, without binding their device traditionally to AD nor implementing mobile accounts that are source of known concerns • NoMAD is dynamically downloaded from the editor’s website and configured with a MDM Configuration profile |
| NoMAD Login | • NoMAD Login is a tool that let users to sign in with their AD account from a customized login window so their local account is created just-in-time, without binding their device traditionally to AD nor implementing mobile accounts • The awesome caribou picture can be replaced by a picture provided by your organization (PNG file) • NoMAD Login is dynamically downloaded from the editor’s website and configured with a MDM Configuration profile |
| Advanced configurations | |
| Login Script | • Login script provided by your organization or wrote by (or with the help of) Agnosys as part of a support action can be embedded in MOM • Login script is executed when the user logs in, as the logged-in user |
| Preflight, Post Settings and Postflight script | • Preflight, Post Settings and Postflight scripts, executed as the root user, are Hooks that enrich the default code • They can be provided by your organization or wrote by (or with the help of) Agnosys as part of a support action • Preflight script is run at the beginning of the workflow in the context of an onboarding executed during the Setup Assistant or just before the enrollment in the other contexts • Post Settings script is run after the device customization pane is closed • Postflight script is run at the end of the workflow • These scripts can embed expected swiftDialog or DEPNotify commands to visually inform of their execution with text displays, progress bar advancements and status changes |
| Scripts embedded in profiles | The device can be configured to execute the loginhook and/or logouthook scripts embedded in the Login Window payload of a Configuration profile provided by the MDM |
| Customized uninstallation script Switch |
• MOM can execute a customized script after the Remote Management profile is removed to uninstall the resources of the management solution left by the device • This script is supposed to be provided in a fair manner by the vendor of this management solution • This script overrides the built-in scripts |
| FileWave specific capacities | |
| Built-in fields and custom fields | • The user can be prompted to enter an arbitrary text for the « Building » field or the « Comment » field or the « Department » field or the « Enrollment Username » field or the « Location » field or a pre-defined custom field • The user can be prompted to select values from menus mapped to built-in fields or custom fields • These values are stored in the device’s inventory |
| Hexnode UEM specific capacities | |
| Built-in attributes | • The user can be prompted to enter an arbitrary text for the « Asset Tag » field or the « Department » field or the « Description » field or the « Notes » field • The user can be prompted to select values from menus mapped to built-in attributes • These values are stored in the device’s inventory |
| Jamf Pro specific capacities | |
| Built-in attributes and Extension attributes | • The user can be prompted to enter an arbitrary text for the « Asset Tag » field or the « Building » field or the « Department » field or the « Room » field or the « Site » field or the « Username » field or a pre-defined extension attribute field • The user can be prompted to select values from menus mapped to built-in attributes or extension attributes • These values stored in the device’s inventory may be used as criteria for Smart groups (Jamf Pro API and Classic API) |
| Automated menu filling | The menus used to select a site, a building or a department can be dynamically filled by the items available for these objects (Classic API) |
| Policies | • Policies can be executed during the workflow before the execution of the Postflight script • Policies can be triggered by their Custom event or by their Identifier |
| Remote Management | • The Remote Management service can be configured to accept incoming connections only as the Management account with all privileges • An Enable Remote Desktop MDM command is automatically sent to the enrolled device before the Remote Management service is configured (Classic API) |
| Jamf School specific capacities | |
| Asset Tag and Notes | The user can be prompted to enter the Asset Tag and Notes that are stored in the device’s inventory and may be used as criteria for Smart groups |
| JumpCloud specific capacities | |
| Description | The user can be prompted to enter the Description that is stored in the device’s inventory (API v1) |
| Meraki Systems Manager specific capacities | |
| Tags and Notes | The user can be prompted to enter the Tags and Notes that are stored in the device’s inventory (API v1) |
| Microsoft Intune specific capacities | |
| Notes | The user can be prompted to enter the Notes that are stored in the device’s inventory (API Graph Beta) |
| Miradore specific capacities | |
| Built-in attributes and Custom attributes | • The user can be prompted to enter an arbitrary text for the « Category » field or the « Location » field or the « Organization » field or the « Tags » field or the « Email » field or the « User’s full name » field or a pre-defined custom attribute field • The user can be prompted to select values from menus mapped to built-in attributes or custom attributes |
| Automated menu filling | The menus used to select a category, a location, an organization or an email can be dynamically filled by the items available for these objects |
| Mosyle Business specific capacities | |
| Asset Tag and Tags | The user can be prompted to enter the Asset Tag and Tags that are stored in the device’s inventory and may be used as criteria for Smart groups (API v1) |
| Mosyle Manager specific capacities | |
| Asset Tag and Tags | The user can be prompted to enter the Asset Tag and Tags that are stored in the device’s inventory and may be used as criteria for Smart groups (API v2) |
| SimpleMDM specific capacities | |
| Custom attributes | • The user can be prompted to enter an arbitrary text for a pre-defined custom attribute • The user can be prompted to select values from menus mapped to custom attributes • These values are stored in the device’s inventory and may be used as key values inside Configuration profiles (API v1) |
| Remote Management | • The Remote Management service can be configured to accept incoming connections only as the Management account with all privileges • An Enable Remote Desktop MDM command is automatically sent to the enrolled device before the Remote Management service is configured (API v1) |
| VMware Workspace ONE UEM specific capacities | |
| Built-in attributes and Custom attributes | • The user can be prompted to enter an arbitrary text for the « Asset Number » field or a new note within the « Notes » array or a pre-defined custom attribute field • The user can be prompted to select values from menus mapped to custom attributes • These values are stored in the device’s inventory (REST API) |
| Software dependencies | |
| Graphical user interface | • MOM relies on swiftDialog or DEPNotify to provide a graphical user interface • swiftDialog or DEPNotify is dynamically downloaded from the editor’s website but can be encapsulated in the Content package if Internet connectivity is not available at the time of integration • MOM can revert to a lightweight AppleScript-only interface if swiftDialog and DEPNotify integrations are disabled |
| Desktop picture configuration | macos-wallpaper binary (used with macOS 10.14.4 and later) and set_desktops.py script (used with macOS 10.14.3 and earlier) are dynamically downloaded from GitHub |
| Dock configuration | • Dockutil binary can be dynamically downloaded from GitHub • Docklib script can be installed via the installation of Python 3 Recommended • The two tools are supported in the Login script provided by Agnosys |
| Munki launching | MunkiPostInstall script, used to launch Munki LaunchDaemons without restart after install, is dynamically downloaded from GitHub |
| Implementation | |
| Localization | • MOM is fully localizable to match the preferred language of the logged in user • The localization is mostly based on building a custom PO file from a template POT file • A PO file for French language is provided |
| Configuration | • Launcher mode is configured with one property list file for its execution and one property list file per MOM Location ; these files are read locally • AutoLauncher mode is configured with one property list file per MOM Location ; this file is received from the MDM as a Configuration profile and MOM waits for its reception before proceeding |
| Content | • Content is pictures, files and scripts used during the onboarding process, wrapped in an signed package • Launcher mode : the Content package is installed locally when MOM is executed • AutoLauncher mode : the Content package is installed from the MDM and MOM waits for its installation before proceeding |
| Resources (Launcher mode only) |
• MOM « Essential » provides that the property list files and the content are encapsulated in an encrypted disk image positioned in the same folder as MOM-Core when it is executed • MOM « Premium » provides that those resources are encapsulated at no extra cost in a custom application named MOM.app |
| Execution prevention (Launcher mode only) |
• MOM « Essential » : the correct entry of a security code is required to authorize MOM-Core to access the encrypted disk image encapsulating the resources required for its operation • MOM « Premium » : the correct entry of a security code can be required to authorize the execution of MOM.app in the context where user accounts have administrative privileges and the software has been left unattended on the device |
| Logs | • By default, MOM is executed silently and does not produce Logs • The production of Logs, used for debugging purposes and stored only locally on the device, must be explicitly requested |
| Trust | • Both MOM-Core and MOM.app are signed and notarized so you are confident that the software have been checked for any malicious code • Agnosys can sign your MOM-Content package if necessary as part of a support action |
| macOS compatibility | MOM is currently compatible with macOS 14 (Sonoma), macOS 13 (Ventura), macOS 12 (Monterey), macOS 11 (Big Sur), macOS 10.15 (Catalina), macOS 10.14 (Mojave) and macOS 10.13.4 or later (High Sierra) |
| Processor compatibility | MOM is compatible with Apple silicon and Intel processors |
(1) Some MDM offer the capacity to install a developer signed package (PKG) specifically during the Automated Device Enrollment sequence. MOM-Core should ideally be installed with this mechanism (see MDM documentation). If the MDM does not offer this capacity, MOM-Core should be installed like any other PKG, at enrollment, with the highest priority, with some reasonable compromises due to velocity concerns.
(2) An ADE (Automated Device Enrollment) capable Mac is part of an Apple Business Manager or Apple School Manager and therefore is eligible to an initial configuration including a MDM enrollment from the Setup Assistant. Please note that the only way to prevent a device to be unenrolled even by users who have administrative privileges is to enroll the device in MDM using Automated Device Enrollment with the « prevent unenrollment » option enabled in the enrollment profile.
(3) Munki is supposed to deploy the apps that are not available on the Mac App Store. Mac App Store apps must be distributed by a MDM linked to Apple Business Manager or Apple School Manager with en masse purchased licences.
