Sean

I think we are going to need specific detail to be able to answer this.

Do I understand correctly? You have one Fileset that you want to associate to multiple devices, yet for each association (hence each device) you want a different path?

FileWave won't remove the PKG, unless the file is set to either 'Self Healing' or 'Download if missing' and then the association is removed. However, there is nothing to stop the developer of the PKG adding additional code to remove the PKG after installation; the PKG shouldn't be required anymore after the drivers are installed. It is a sneaky way to ensure you always download the latest driver if you need to reinstall. You don't have to build a PKG Fileset though, you could build an empty Fileset and add the PKG as just another file. From here you would then add a Fileset Script to run the PKG. If that Fileset Script was a Verification Script, then it would run on every Verify. Additionally, if the PKG itself was also set to either 'Self Healing' or 'Download if missing', then if it had been removed, the verification would put it back. Of course, you could avoid the re-download if the installer is removing itself. Add a copy command in the script for the PKG, run the PKG installer command against the copied version, then the PKG will always be on the device, since the copied one would be the one removed. The weird part is the driver missing. Why would a user even want to remove a printer driver? Are these shared devices, so you don't know who is removing the driver? You could in theory have a timed script to monitor the existence of the actual driver files and if removed cause an action, e.g Slack/Teams notification. The only times I have seen things mysteriously 'disappear' are: AV Software quarantining An Actual Virus Another Fileset that has the files at file level, set as self-healing and that Fileset becomes disassociated The Fileset has an uninstaller script to remove items and the Fileset is disassociated by mistake Another product like, .e.g. DeepFreeze, which is restoring the device to a known state and that known state does not include those files. Hopefully the verification script method will provide you with your original desire, but also perhaps the other information might help you to locate the original cause.

It is automatic. It will occur at multiple points, e.g. Update Model, Inventory, Verify, etc. We then know what to push to the device based upon the latest manifest and the current device details. A series of MDM commands are sent together, one of which is the OSUpdateStatus. When we get the reply, we then know whether to send additional commands or not to devices. E.g ProfileList command will be sent, the reply will be compared with the manifest and, if need be, commands to instal or remove Profiles will be sent to the device. Manually the process can be triggered on a single device just by opening the Device Info and selecting the Command History view. If there are not already queued entries, then a fresh set of commands should be triggered at this time.

Only place I think you will find that info is in the Admin logs. I don't believe we have any kind of variable for that. At best you could create multiple Custom Fields to include the name of each admin and expect the admin to select the correct one for themselves from the list otherwise. You can always make a request: https://foundry.filewave.com/mod/page/view.php?id=583 Make sure to accept/reject cookies, otherwise the big red button to add requests is hidden.

Perhaps try: https://github.com/carlashley/appleloops https://github.com/carlashley/loopdown

Multiple Requirement Script will increase the traffic back to server, so I'd keep to one if possible. Try the following: #!/bin/zsh counter=0 total=$# found_profile="" while [ $# -gt 0 ] do find_this="profileIdentifier: $1" found_profile=$(profiles list all | awk -v search=$find_this '$0 ~ search {print $NF}') if [ ! -z $found_profile ] then counter=$(( $counter + 1 )) fi shift done if [ $counter -ne $total ] then exit 1 fi exit 0 Add each required profile ID, of each profile to be located, as individual Launch Arguments in the scripts Get Info > Executable. Doesn't matter how many you add, script should only exit 0 if all added Launch Arguments are found.

Yes two separate launch items. Users are able to disable LaunchAgents, but it has always required shell command knowledge, but it is generally easier to do user interaction with an Agent rather than a Daemon. However, with Ventura, LaunchAgents are just viewed in System Preferences and you can just tick a box to turn them off or on. Hence, Launch Daemon does the killing of the App, user can't disable that (unless they are Admin), Launch Agent informs the user; if they want to turn that off, so be it. As such, everything has been changed to adapt to this new setup.

Not sure I follow. The importer creates Filesets and has always been able to add .app files. For example, my Cyberduck override recipe includes: Parent recipe(s): /Users/Shared/Autopkg/RecipeRepos/com.github.autopkg.filewave/CyberDuck/Cyberduck.filewave.recipe /Users/Shared/Autopkg/RecipeRepos/com.github.autopkg.recipes/Cyberduck/Cyberduck.download.recipe Input values: 'NAME': 'Cyberduck', 'SPARKLE_FEED_URL': 'https://version.cyberduck.io/changelog.rss', 'fw_destination_root': '/Applications/%NAME%.app', 'fw_fileset_group': 'macOS Autopkg - %NAME%' On upload, it adds the Fileset to my chosen Fileset group with appropriate name I then have a subgroup which is the group I associate to devices. After testing the new Fileset, I then switch out the old version with the new version in the sub group. The Fileset itself is: The final output of running the recipe is: The following fileset was imported: Fw Fileset Id Fw Fileset Group Fw Fileset Name ------------- ---------------- --------------- 736065 macOS Autopkg - Cyberduck Cyberduck - 8.5.4 Which aspects do you feel you are missing?

I've updated the KB with the new Fileset, if you'd like to test it.

I already have an updated version that is due to be posted, but if the script doesn't act as expected, then it is likely it hasn't set the count and so the Custom Field is just a victim. Hopefully it will be live soon.

We initially send a ScheduleOSUpdate as an MDM command to inform the device to talk to Apple to action the update. It then commences the download. We periodically send OSUpdateStatus as MDM commands which will tell us how far it has got in downloading so far. (Apple don't automatically send back how the update is doing, so we have to keep asking). I think we send these every 5 minutes. Once reported back as download completed from the OSUpdateStatus command, we then send ScheduleOSUpdate MDM command again, but this time it should instal the now downloaded update If the command is acknowledged, then everything is down to Apple thereafter, but that goes for each command sent, of course. There have been multiple bugs with this whole process, e.g. Device does not report updates it requires Sometimes the device reports updates it requires Device will report an update as required, but then when the command is received to action that update, the device then fails to report it as required (it reconfirms in case the update has been actioned otherwise since) and the command is ignored. Since the command needs to be sent twice, once to download and again to instal, the device might action the download, but then ignore the request to instal it! Due to the silent ignoring of the request, we may not get any failure information back from the device, and as such the Fileset might appear as complete, even though it hasn't done the requested update. Kiosk being involved is meaningless, as long as the command is acknowledged. Commands can be viewed from the Command History tab of a Client's Info. I've tested this whilst writing this on a single device with a Safari update. First OSUpdateStatus command reported 30%, with the next reporting 97% download complete. There have been two more OSUpdateStatus commands sent since and it still reports 97% complete. So each 5 minutes we are going to keep sending this status report from the server and it looks at the moment like it is going to be stuck here forever. Clearly we don't expect the situation that the download will never complete, so we don't expect to be constantly sending out OSUpdateStatus commands to devices, they should eventually and naturally disappear once download is finalised. Oh and the next one has just reported 97% complete still again. I imagine that the download did complete, but the device doesn't think it needs the update anymore so isn't replying to the request for the download status and so we are stuck in limbo.

Inventory Query no. Client View holds this information and Client View is not inventory data. However, you can obtain the Comment from an API based upon: curl -X 'GET' 'https://[server_address]/api/devices/v1/devices/[device_id] You'll need auth token and to supply the desired data to extract 'comment'

If you format the output to match our expected date format, then you can both set the Custom Field as a date field and then use date specific criteria in an inventory query, e.g in the last x days, older than, etc. To give an example, this is my equivalent of the same thing: #!/bin/zsh PlistBuddy=/usr/libexec/PlistBuddy # New path since macOS 10.10 tm_plist="/Library/Preferences/com.apple.TimeMachine.plist" # Old path if [[ -e "/private/var/db/.TimeMachine.Results.plist" ]] then tm_plist="/private/var/db/.TimeMachine.Results.plist" fi backup_enabled=$($PlistBuddy -c 'Print AutoBackup' "$tm_plist" 2>/dev/null) if [[ "$backup_enabled" == "true" ]] then last_date=$($PlistBuddy -c 'Print :Destinations:0:SnapshotDates:' "$tm_plist" 2>/dev/null | awk '{penultimate = last; last = $0} END {print penultimate}') fi if [ ! -z $last_date ] then date -j -f " %a %b %d %H:%M:%S %Z %Y" "$last_date" "+%Y/%m/%d %H:%M" fi

Does appear to be outdated, but I don't have an Apple TV at hand to test. Did you try making a blueprint, adding the two profiles to the blueprint and then triggering the preparation using that blueprint?

The profile doesn't match any profiles defined by Apple. If you try and upload a mobileconfig file to FileWave, FileWave will expect it to be one of Apple's defined profiles, e.g Dock, SCEP, Network, etc. However this is none of those. FileWave can take Custom Settings for such things, but this expects a plist file. You could try renaming the mobileconfig files to plist, import them into the Custom Settings payload and see if that then gives you what you are after.

Hi, You'll want to make a new Fileset (Empty will be fine). Drag the MSI into a location within this Fileset and then create an activation script to include your BATCH contents to trigger the MSI. When you drag an MSI directly into FileWave Fileset view, it creates a special Fileset that automatically runs the MSI for you. If you create an Empty Fileset and add the MSI, then the MSI will just be treated as a file and won't be ran. You can then have your script control the installation.

Does the device have a Wi-Fi network configuration or connected with an Ethernet cable? We have a couple of KBs that may interest you: https://fwkb.atlassian.net/wiki/spaces/KB/pages/4329514/Apple+TV+and+AC2+Apple+Configurator+2 https://fwkb.atlassian.net/wiki/spaces/KB/pages/4332857/Apple+TV+Automatic+Advance+DEP Otherwise please consider making a support ticket.

Usual things could include: Ports not open APNs is out of date Server cert has an issue of some nature Could try rebooting the server otherwise Failing those, make a ticket with support. They'll likely want to see server logs

You don't need to read the logs, you could instead query the server for that value if you like. Just consider how often you would be doing this though. This would check if the device had not checked in within the last 7 days: query='{"criteria":{"expressions":[{"column":"last_check_in","component":"Client","operator":"within_past","qualifier":7,"unit":"days"},{"column":"serial_number","component":"Client","operator":"is","qualifier":"'$serial_number'"}],"logic":"all"},"fields":[{"column":"last_check_in","component":"Client"}],"main_component":"DesktopClient"}' Note, this is an Admin console query, so port number required: curl -k -s -H "Authorization: $auth" https://$server_dns:20443/inv/api/v1/query_result/ --data $query -H "Content-Type: application/json" Of course, this would depend upon why it hasn't checked in. Clearly if it can't actually get to the server, then the API won't work either, but there are ways around that.

Uptime is probably not a standard inventory item, since it can't be reported accurately. If a device were on for 10 days and then turned off, the uptime would still report 10 days, even though it is now 0. Additionally, when you turn the device back on, the check-in time will update straight away, but only at the end of verification, when inventory occurs, could the update time be corrected. As such, a device could look like it has a much larger uptime than is actually true. There would be a period of time from the example above, where the uptime may be only minutes, yet it would still be reporting 10 days and that data would seem like it were correct. The only sure way to know if the data is current is by comparing the Last Update Time for that particular Field against the actual value, within the Client Info > Device Details. However, built-in Inventory doesn't provide a Last Update Time, that is a Custom Field thing. Regarding the reporting, my equivalent Custom Field is a Boot Date and returns a DATE value. By using the Date data type, you can then use the before/after date, in the last x time frame, etc. When creating a query: If you define a criteria for the Last Connected date to be within a relatively short time frame (perhaps an hour or two), this will eradicate the devices that are off/offline If you define another criteria in the same query for the Last Connected date to be within a much shorter time frame (for example 20 mins) and set this as NOT, any devices that fall into the second category above, may be also excluded from the list. The second timeframe will be unique to individual setups and to particular events within any one setup (imagine pushing out a really large Fileset, e.g. an Adobe app). How much runs and how long does it take for devices to update from a verify or model update, is not a simple question. But this should at least give you a much better idea of actual uptime on devices. N.B. Locked clients also won't be able to update their inventory, yet Last Connected can update. However, FileWave Client Locked is another inventory item that could be added to the query criteria to exclude locked devices.

This is expected behaviour. The privacy settings viewed through System Preferences are the settings that would be in place if there is no profile applied; these are the user's personal settings. As such, if a profile is deployed through MDM to override these settings, the System Preferences won't alter what is viewed, since the MDM Profile settings are applied by the system. You should expect the MDM Profile settings to be active though. This experience has been the case since Apple introduced TCC/PPPC Privacy Profiles. It means the user has visibility of their settings if the Profile were removed.