Jump to content

Sean

Moderators
  • Posts

    94
  • Joined

  • Last visited

  • Days Won

    20

Sean last won the day on March 13

Sean had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Sean's Achievements

Enthusiast

Enthusiast (6/14)

  • One Year In
  • Conversation Starter
  • Reacting Well
  • Collaborator Rare
  • One Month Later

Recent Badges

26

Reputation

  1. 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.
  2. Glad you found the reason and thanks for the update.
  3. 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.
  4. 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)
  5. 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.
  6. 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
  7. Sean

    Date Format

    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?
  8. Sean

    Date Format

    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.
  9. Sean

    Date Format

    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.
  10. 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
  11. 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
  12. 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
  13. 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.
  14. 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?
×
×
  • Create New...