Sean

If Focus can indeed overrule the restrictions profile settings provided to supervised devices, then you may wish to raise this with Apple.

The database only stores the last 20 models, but that itself is minimal data. Each backup will have its own 20 models though, but again this is tiny and you can delete the older backup archives, it is the Data Folder that holds the large quantity of data and this is all Filesets, from when the backup first ever ran, until the latests backup. Probably the easiest thing to do is: Copy the current backup folder to an external storage (wise to do this anyway) Remove it from the server Purge older Filesets no longer used, using FileWave Central Run a fresh backup At some point in the future, when happy, remove the externally stored copy (consider copying the latest backup instead) Identifying Filesets by size can be done with a query. This query has: 'All Devices' > 'Device Name' 'Fileset' > 'Name' 'Fileset' > 'Install Size' 'Fileset' > 'Fileset ID' 'Main Component' > 'Fileset' Then order by Install Size. If you add the following Criteria, I think that should list Filesets not used: Worth doubling checking before deletion. If you highlight a Fileset and choose Report, that should show all current status reports for that Fileset, which will be blank if none.

Backup are additive only. Imagine what would occur if they weren't and you then wanted to rollback. You could alter the rysnc in the script to use a --delete option to remove anything that is in the backup that is no longer on the server if you wanted, but that has the obvious consequence if you needed it, so not recommended as a continuous use option. However, you could shelve the backup you have now onto another drive somewhere and then run a fresh backup to effectively start from scratch. To help reduce the size of data currently in use, you could purge Filesets that are no longer required using the FileWave Central Admin application. You can build out Inventory Queries to show size and then sort by size if you wanted to find the larger Filesets.

There is no equivalent for i(Pad)OS. On macOS, Custom Settings Payload uses the old MCX method of managing OS X that carried over to Profiles. MDM is the only option on i(Pad)OS, with only the basic options provided for deferring updates. With updates being managed through the Software Updates view.

Glad you found the reason and thanks for the update.

Not quite sure I follow your desire. You suggested you don't want to use FileWave MDM and then suggest you want to use Apple's MDM. Apple's MDM is FileWave's MDM. All the issues that have occurred through the Software Update Process are an issue for all MDM vendors; an issue that has actually hindered their process for years. The profile mentioned would look something like this: As noted in their KB, the newer DDM will hopefully improve the control of Software Updates. FileWave 15.3 will introduce DDM at a basic level, with newer features of DDM being introduced subsequently. Likelihood that Apple mentioned the above Profile, is mainly because of this statement: All MDM vendors are hoping that MDM Software Updates will improve with DDM, but it is early days; we need newer updates to exist and for the status to be monitored. However, if you configure the above Profile to automate the entire process, then the OS should take over and updates should just instal, but with no granular management control, when Apple tells the device there is an update, it will just do it; MDM need not be involved.

What is running this script? How are you determining the device_id? Have you considered sending details to a log file from the script? For example: print(api)

Yes, but it isn't public. (It could therefore change, so if you use it, it may break in the future). Put a browser into development mode and view the details if you open that group in the FileWave Anywhere Web Admin. It will show the path, etc used for the query. If it is a Smart Group, copy the key elements from the JSON viewed in Swagger of the api/doc in Anywhere and use the Command Line API instead, to run that query and view the results.

Cookies can be denied with a Profile: But I'm unaware of Apple allowing the ability to remove those already created. Shared iPad however, has a Guest Mode option: https://support.apple.com/en-gb/guide/deployment/dep9a34c2ba2/web Does Chrome Management (or other browser) provide something for this? You could perhaps deny Safari and look at an alternate Browser. https://support.google.com/chrome/a/answer/10377492?hl=en

Apple no longer instal Python by default on devices. Have you pushed out Python to these devices? If you have pushed out Python, what version are the clients running and does this match the version you are running and therefore compatible with the script you have written?

I should probably mention that the Custom Fields are stored locally, but in a non-readable file format. The client extracts them into the above mentioned script file, runs the script, then removes the script file for each Custom Field.

I have a feature request to make this more obvious, but it does describe the required format in the Custom Field info: If you look at a client's log, you will see multiple entries for custom_field_script. Every Custom Field uses the same script file, it is just overwritten each time and then eventually no file is left behind afterwards.

TCC/PPPC rights, as they are known, are managed with Security & Privacy profiles. There are two different Security & Privacy Profile types (Apple used to have this all in one profile and then they split out TCC from the rest): There are two profiles in our example TeamViewer recipe which offers two approaches to options which you may find useful, since there will be some similarity: https://kb.filewave.com/books/teamviewer/page/teamviewer-macos-client-setup Apple never made this easy, when it comes to identifying what is required: https://kb.filewave.com/books/profiles-apple/page/macos-privacy-preferences-payload-in-mojave-1014 But you may well find examples on the Web specifically for Teams. Many major vendors supply the necessary details to configure these settings. Printer settings are different. This is standard admin permissions and staff users do not have the ability to manage many print features by default. However, you can add users to additional groups. Something like: /usr/sbin/dseditgroup -o edit -n /Local/Default -a staff -t group lpadmin

What version of iOS? Apple have had a long running issue that stops devices from checking in: https://kb.filewave.com/books/apple-general-info/page/address-stalled-mdm-commands