Sean

Apple don't provide a method to achieve this, they consider it user choice. I think the best on offer is: https://chromeenterprise.google/intl/en_uk/policies/#DefaultBrowserSettingEnabled It should be possible to create a Custom Settings Profile to set the key. Expectation afterwards would be for Chrome to prompt when opened, asking the user if they would like to make Chrome default. Clearly, they don't have to accept, but as a managed setting it should keep prompting on each open. Opening Chrome could be achieved with a script, to trigger the user to be prompted, which could be handled through FileWave with the following: https://kb.filewave.com/books/filewave-general-info/page/execute-macos-scripts-as-console-user Alternatively, it could be setup in a LaunchAgent for login. As for Safari, you could create a Profile to block Safari from being allowed, essentially forcing users into using Chrome.

Symptoms include BSOD. CrowdStrike Engineering identified an issue and have already reverted those changes. They have suggested any devices that were not yet affected, should be fine from now with this reversal. If hosts are still crashing or unable to pick up these changes, they have supplied the following details: Boot Windows into Safe Mode or Windows Recovery Environment Navigate to C:\Windows\System32\drivers\CrowdStrike Locate the matching file: 'C-00000291*.sys' and delete it Boot the host normally

Feature Requests can be made at the following. You need to be logged in to view: https://kb.filewave.com/books/community-engagement/page/filewave-roadmap-feedback-and-product-suggestions-portals Others can then see these and should also be able to vote for them.

I downloaded the Fileset and imported it into my setup without issue. You must have imported it, otherwise you would not be able to supply a Fileset. At what point did it fail?

Last Connected is referencing the time/date when the device actioned a check-in Device State change is when the Client State changed, for example, changing the state from tracked to untracked

Do none of the following KB assist in your particular requirement... https://kb.filewave.com/books/filesets-payloads/chapter/fileset-revisions

Don't believe it is possible to view archived devices in FileWave Anywhere or choose to archive them. These are features in FileWave Central only, as far as I am aware. You could request a feature though our roadmap product board: https://kb.filewave.com/books/community-engagement/page/filewave-roadmap-feedback-and-product-suggestions-portals

Discord are currently reviewing a couple of issues, so you may experience some unresponsive behaviour:

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)