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

Think you've answered your own question. No information... yet. Perhaps WWDC this year will provide some insight, likely the question will be asked by MDM vendors. If/when it happens, pages like this one should start to show up: https://support.apple.com/en-gb/guide/deployment/dep34c5cd30f/web

Strictly speaking, you shouldn't need to. When a new user attempts to log in and maximum is reached, the device should make way for the new user, by removing one. https://it-training.apple.com/tutorials/deployment/dm135 However, if content has not yet uploaded for backup, then a user will not be removed (otherwise user data could be lost undesirably). This can then prevent users from logging into a device where they do not yet have cached data and maximum users has already been met. If content is not caching fast enough, consider including Content Caching on one or more macOS devices locally to improve this. The remove user command is really a brute force removal. Don't care if user data has been backed up, just blow it away anyway. Hence it hasn't really been designed with mass removal in mind, if you want to remove all users, you are getting close to just wiping the devices (clearly that takes longer depending upon the quantity of apps to reinstall). The Command in Profile adheres to the idea that user data should not be removed unless synchronised: It may be possible to trigger the all user deletion server side with code. Support might be able to assist with that. However, I would consider improving the situation with backups, so that you hopefully don't ever have to do this.

API are usually used for linking 3rd party products, but could be used in scripts to interface with the server. If you haven't configured any of these, then there shouldn't be any in use. Whilst the model is updating, clients will temporarily be unable to communicate with the server. It would only be if you had something designed to automatically trigger lots of Model Updates could this even be a consideration, so it sounds unlikely. With routed messages, things should be good too. Have you enabled DEBUG on the client to see if this highlights something in the client logs? Have you opened a ticket with support?

With that in mind: How many devices do you have and of which type? Do you use Boosters? Do you use Booster routing? Does the FileWave Central Dashboard show any resource that are being fully utilised? Perhaps the server is being overloaded with requests. Other things that can impact this: API requests Tickle time too low Too many requirement scripts that are never successful Frequent Model Updates Maybe the above will highlight something.

Do the client logs show if inventory back to the server was successful?

You can use Fileset Filter in Smart Groups. From your description: E.g. List of macOS devices with a Fileset: List of macOS devices which do not have that Fileset: You could add device name begins with as a criteria. Not sure I follow the actual example, but hopefully the above will assist.

Do you have acknowledged commands in the device's Client Info > Command History for any or all of the commands listed?

The details in the KB assume a user is currently logged in; it relies upon the owner of the console at the time it is ran. If no user is logged in at that time, it will not be the a user on the device, but root or perhaps another hidden OS account. I have also adapted the script example, since some commands will work with 'sudo -u', but some commands will require 'launchctl asuser'. However, both may be supplied at the same time, which should ensure all eventualities are covered. What does not work mean? The script failed or it didn't do as you hoped? Perhaps you could post the script.

The defaults command references the user's domain when you do no specify a path. Is this intentional? FileWave runs as the root user, so if you do not specify paths, then this will only impact the root user. With that in mind, are these global settings in /Library/Preferences or are these desired to be user settings? If you wish for them to be in /Library, they you may merely specify the path with the file name when running the command. If they need to belong each user's Preferences though, then you will need to script a way to identify those files or a way to run the scripts as the current user, noting that there may not be any user logged in at that time. However, if your devices are MDM enrolled, they you can set these within a Custom Settings Profile Payload instead. Profiles of this type can be set as either User or System.

Is there any proxy configuration that could impact the macOS device and not the Windows device? Have you tried to log into the Web Admin (FileWave Anywhere) from the same device?