Profile Editor Command Policy
What
The Command Policy in the Profile Editor is unique; the contents of a Command Policy is not a profile payload, but instead MDM commands.
When/Why
Some commands are available from the right click context menu, e.g. Wipe Device…. However, some commands would be unwieldy in this manner e.g. iOS Wallpaper. Imagine having hundreds or thousands of devices or if you wanted different Wallpaper based upon location, department, etc.
To provide this flexible working, some commands have been placed inside the Profile Editor and all these commands exist within the Command Policy view. This method allows the association of such commands based upon Smart Groups, for example, and allows easy association across many devices.
if still assigned, commands will be re-sent with every MDM Verify, be that the 24 hour timer or a Model Update
Since these are commands and not Profile Payloads, there will be:
* No request type of ‘InstallProfile’ listed in the Command History
* These will not be listed in the ‘Installed Profiles’ view.
* There will be no Fileset Report for these Command Policies
* The Fileset Status will remain grey and only ever report Associated
MDM Commands from Command Policy will show in the Command History view with a request type of ‘Settings’
Starting in FileWave 16.3.x, this distinction also matters in mixed DDM/MDM environments. Command Policy Filesets are not treated as DDM-installed Profiles. They are excluded from DDM installation and converted into the corresponding MDM commands during deployment.
Fileset Disassociation
Where a command instructs a device to enable a setting, for example: Remote Desktop, Idle Reboot, etc. there is a sub option. This sub-option provides the option to disable the setting if the MDM Command Policy Fileset is disassociated. If not set, the setting will remain enabled on disassociation.
Gated Exceptions
It is feasible, that some commands may change settings, but local users may override these settings. Whilst the assignment of the MDM Command Policy Fileset is in place, with each new Verify, the command should be re-sent. By default, MDM verification not only occurs every 24 hours, if a device has no other reason to check-in, but will occur with every Model Update. This, though, can have consequences, where re-sending the command may not be desirable or should be less frequent. As such, there is a gated exceptions list.
Wallpaper
MDM communication was designed for small configuration files to be sent, not large images. Although Apple allowed the possibility of providing images through MDM commands, they can have a significant impact on server performance where lots of devices exist and frequent Model Updates are actioned.
For this reason, Wallpaper MDM Commands are limited to once every 24 hours per device, even if a manual Verify is triggered.
Time Zone
Since Time Zone information is available from devices, FileWave will not re-send the command, whilst the Time Zone of devices match the Time Zone of the MDM Command Policy. Only if the two differ will the command be re-sent.
Shared iPad
As with Time Zone, Shared iPad commands will not be re-sent to devices with a Verify, unless the devices current setup does not match the Shared iPad configuration within the Command Policy. Only if the two differ will the command be re-sent.
Accessibility Settings
Similar to Time Zone and Shared iPad commands, again the command will not be re-sent unless there is a difference between the device's settings and those in the Command Policy. Unlike Time Zone and Shared iPad, only those items that differ will be re-sent, rather than the entire dictionary of Accessibility Settings.
Remote Desktop
Remote Desktop requires a mention here. At this time, Remote Desktop is not gated. There are issues unique to the Remote Desktop command. Apple pre-determine certain settings, for example, when using the Remote Desktop command to enable Remote Desktop, configuration will enable Remote Desktop for all users, regardless of any prior configuration locally on the device.
Configuration could be altered, after the Command Policy to enable Remote Desktop has been received, but a re-send of the Remote Desktop command may overwrite this configuration. A method of disassociation would be desirable to prevent this from occurring. In this instance, ensure the option to disable the service is not set for disassociation.
If the desired Remote Desktop settings match those of Apple's defined settings, leaving the assignment of the Fileset with the device would be ideal, to ensure they are correct with each Verify.
How
- Open the Profile Editor
- Select Command Policy
- Edit as desired
- Associate to test device(s) first before deploying across many devices
Example Command History view for a setting to alter the Wallpaper:

No comments to display
No comments to display