Apple MDM
With the exception of macOS, all Apple devices are managed purely through MDM. macOS devices on the other hand, relies upon the FileWave Client, however, when MDM enrolled, benefit from the additional features
Apple MDM Lost Mode
What
Apple Managed Lost Mode is an MDM command for supervised iPhone and iPad devices. When FileWave places a supported device in the Missing Client State, FileWave sends Apple’s Lost Mode MDM command. The device is locked from use until Lost Mode is disabled by MDM.
Managed Lost Mode applies to supervised iOS and iPadOS devices. Apple does not provide the same Managed Lost Mode workflow for macOS.
Why
Use Lost Mode when a supervised iPhone or iPad is misplaced, lost, or suspected stolen. It helps protect the device by locking the current user out while still allowing an administrator to display a recovery message, request location, and play a sound after the device receives the command.
Information
Lost Mode is enabled by setting a supported device into the Missing Client State from the right-click contextual menu:
To disable Lost Mode, select another Client State, such as Tracked or Untracked. A Model Update is required after changing the Client State before the MDM command is sent to the device.
Devices require a network connection to receive the command to enable or disable Lost Mode.
If a device is locked and cannot connect because nearby Wi-Fi networks are not configured, consider connecting the device to Ethernet. An adapter may be required.
Locating Devices
While a supported device is in Lost Mode, FileWave can help locate it in addition to keeping the device locked.
Location
After a supported device is set as Missing, location data is sent back to the FileWave Server when the device has a network connection. Location may be viewed on a map from the Client Info view, and related location data is available from Inventory Queries.
Apple’s Managed Lost Mode can request location from a supervised iPhone or iPad even if Location Services are off, and it does not require Find My to be enabled on the device.
Sound
Location is useful, but sometimes the device is in a bag, cupboard, or similar place. To further assist retrieval, when a supported device is in the Lost Mode Missing state, an additional right-click menu option is available: Play Lost Mode Sound. The previous volume setting is not considered; the device plays an audible set of tones.
macOS and other Apple devices
macOS does not support Apple MDM Managed Lost Mode. For Mac, Apple provides different MDM security commands instead:
- Lock Device: Locks a Mac with a six-digit PIN and message. After receiving the command, the Mac restarts and cannot boot back into macOS until the PIN is entered and validated. Locking a Mac with Apple silicon requires macOS 11.5 or later.
- Erase Device: Remotely erases a Mac when data protection is more important than recovery.
- Activation Lock management: Available for supported supervised Macs with Apple silicon or the Apple T2 Security Chip.
These Mac commands are separate from Managed Lost Mode and do not provide the same iOS/iPadOS Lost Mode location and sound workflow.
Apple reference: Lock and locate Apple devices.
Apple MDM Command History
What
Any Apple devices that are MDM enrolled should receive MDM Requests. Each Client Info lists the requests for that device.
Why
MDM Command History exists to display all requests queued and sent to devices, along with the result of those requests; additionally showing if the request was designed for the User of the device or the System
When referring to Users and MDM, Apple allow for any amount of directory users to be managed, but only one local user is considered to be managed. This is the first local user to log into the device after enrolment. System requests impact all users.
The Request Types include:
- Inventory
- Profile instals and uninstalls
- VPP App instals and uninstalls
- Commands, e.g. erasing a device, renaming the device, etc.
Information
Opening the Client Info for an Apple MDM enrolled device and selecting the Command History tab should show something similar to the below image:
Request Types are defined by Apple and details may be viewed on the Apple Development Pages
Status and Error messages are those reported by Apple, with the exception of 'not sent'. The possible values are:
| Status | Details | Apple Request Response |
| not sent | The command is queued and awaiting for the device to reply to the APNs request | - |
| acknowledged | Device has processed the request | Acknowledged |
| not now | Device has received the request, but is unable to process the request at this time | NotNow |
| command error | An error has occurred | Error or CommandFormatError |
As of FileWave 15.5, the status of Command Queue requests are now accessible from within standard Inventory Queries
'not sent'
Before any requests may be sent to a device, the FileWave Server sends an Apple Push Notification (APN) request to Apple. Apple queue these APNs requests and only after the device checks in with Apple and pulls the APNs request, will the device then check-in with the defined server.
APNs request is nothing more that a notification for the device to check-in with the defined server.
Whilst waiting for the device to receive the APNs request and check-in, the Command History will display 'not sent'
Where requests are 'not sent' or 'not now', new requests will not be added to the queue for the same Request Types, since there is already a queued request waiting. The 'Creation Date' displays the time and day the request was added to the queue.
Response Commands
Once the APNs request has been received by the device, on check-in, queued requests may then be sent to the device.
'acknowledged'
The request has been received by the device, processed and reported back to the FileWave Server as completed.
'not now'
Some requests will not be accepted, until the device is in a certain state. For example, a user may need to be logged into the device to process the provided request.
Hence, the request has been received and the device has responded, but the request is awaiting the desired state before it will finish processing the request and report back as much.
'command error'
In some instances, the request may not be able to complete, due to an error. Apple have two defined error status values:
- 'Error' - An error occurred (the device will report error details in the response to the request)
- 'CommandFormatError' - The request protocol was incorrect, e.g. a malformed request
The 'Error Msg' column shown in the Command History view reports information provided by the device back to FileWave Server and contains information as set out by Apple.
Apple's developer page demonstrates greater depth on MDM requests:
Sending MDM Commands to a Device
User vs System
The user column contains the channel used for the request. Where the user column is blank, this implies the request is a System Channel request. Otherwise the name of any managed users existing on the device will be displayed for those requests.
Some Request Types are required for both User and System, e.g.
DeviceInformation may report inventory regarding the System and the User. As such there are multiple requests, one per Managed User and one for System.
Profile Installation
Profile Settings defines whether a Profile should be Installed for the System or User:
As with other Request Types, if the Profile is configured for System Installation, the User channel column should be blank, whilst those set as User should show a Request Type of 'InstallProfile' per managed user.
The below image shows installation of two differing Profiles, one set as System and the other set as User:
There was a period of time where all Profiles could be set as either User or System regardless. Apple enforced 'correct' Installation channels several major versions back. As such, if Profiles were delivered before such change, it may be possible that the User column may show a User despite the Profile being set as System. This should no longer be the case for newly delivered requests
Although altered values in a Profile Payload will just cause the Profile to be updated on a device, changing the Installation channel from User to System or vice versa, will cause the Profile to be uninstalled and then re-installed using the newly defined Installation channel.
Only some Profile Payloads may be defined as either User or System. If one option is greyed out, the Profile Setting cannot be changed.
Commands
Some requests are commands designed to action an event, e.g. rename a device, erase a device, etc. If the request is altering a setting, the Request Type reported is 'Settings' and the 'Settings Items' column will display details regarding the setting to be altered.
The below image shows a request to alter the name of the device:
An Update Model will be required before the Setting request is added to the device's request queue.
Further details regarding 'Command Policy' Fileset Payloads can be viewed in the following KB:
Troubleshooting
Some typical items to consider when reviewing Command History:
- The Command History tab will not be present if the device is not MDM enrolled (i.e. a macOS device with only the FileWave Client installed)
- A profile does not show on the device, yet command is acknowledged. This is typically seen where a Profile is set as User, but the currently logged in user is a local user, but not the local managed user. Compare the Command History User column with the currently logged in user.
- Where possible, it only might be prudent to set Profiles as System rather than user, if all local users require management (Note: this may also impact Administrators logging into systems, when attempting to fix a user's issue)
- Where an error has occurred, review the 'Error Msg' column. If the error message does not appear clear, consider raising a ticket with the FileWave Support team.
- As noted above, when a Profile Setting is changed, the existing Profile is removed before being re-delivered through the newly specified Installation channel (User or System). If the Profile is essential for network connectivity, the device will lose its network connection, making it impossible to receive the updated Profile.
Managing Apple Vision Pro and visionOS
What
FileWave 16.4 manages Apple Vision Pro as an Apple mobile device through Apple’s MDM framework. Vision Pro uses the same FileWave enrollment and management workflows as iPhone and iPad; it does not use the macOS FileWave Client package.
FileWave can send the same mobile-device commands and configurations to Vision Pro when Apple supports that capability on the installed visionOS version. A command, profile payload, app, or restriction that Apple does not support on visionOS cannot be added by FileWave.
Enroll Apple Vision Pro
Automated Device Enrollment
Organization-owned Vision Pro devices can follow the same Automated Device Enrollment (ADE) workflow used for iPhone and iPad:
- Make the device available in Apple School Manager or Apple Business Manager and assign it to the FileWave MDM server.
- Synchronize ADE in FileWave Central.
- Assign the appropriate ADE profile.
- Start or reset the Vision Pro and complete Apple’s Remote Management flow.
- In FileWave Central, add the device from New Client > Enrolled Mobile Devices when it is not already in the model, then update the Model.
Manual or URL enrollment
When ADE is not being used, follow the same FileWave mobile-device URL enrollment workflow used for iPhone and iPad. The user opens the FileWave enrollment address from Vision Pro, downloads and approves the MDM enrollment profile, and completes any configured authentication steps.
Manual enrollment can allow the user to remove the MDM profile. Use ADE for organization-owned devices when the enrollment must remain enforced after setup or reset.
Manage Vision Pro in FileWave
After enrollment, Vision Pro appears with other mobile devices in FileWave Central. Administrators can use the same mobile-device workflows for inventory, groups, associations or Deployments, profiles, applications, and management commands.
- Commands: Use the same FileWave mobile-device command workflow used for iPhone and iPad. The command is available and executes only when Apple supports it on the device’s visionOS version and enrollment state.
- Profiles and restrictions: Before deployment, verify that the selected Apple payload explicitly supports visionOS. Similar-looking iOS or iPadOS settings are not automatically available on visionOS.
- Apps and content: Deploy Apps and Books applications or other supported content through the normal FileWave mobile Fileset and Deployment workflow. Confirm that the application supports Apple Vision Pro.
- Inventory and reporting: Include Vision Pro devices in mobile-device Inventory Reports, Smart Groups, and compliance reviews rather than treating them as macOS computers.
Evaluation workflow
During a FileWave evaluation, treat Vision Pro as another Apple mobile platform alongside iPhone and iPad:
- Configure APNs and Apple School Manager or Apple Business Manager integration.
- Enroll through ADE or the mobile URL-enrollment workflow.
- Add the device to the FileWave model and place it in the intended mobile-device group.
- Test one supported profile, application, inventory query, and management command before expanding the scope.
- Verify each intended feature against the target visionOS version.