Jump to content

Pierre-Nicolas

Members
  • Posts

    31
  • Joined

  • Last visited

  • Days Won

    11

Pierre-Nicolas last won the day on January 13 2023

Pierre-Nicolas had the most liked content!

2 Followers

Recent Profile Visitors

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

Pierre-Nicolas's Achievements

Explorer

Explorer (4/14)

  • Dedicated
  • One Month Later
  • Collaborator Rare
  • Conversation Starter
  • Week One Done

Recent Badges

22

Reputation

  1. Depends on what you want to do, but the most common approach to avoid model update is to rely on Smart Groups and custom fields. Once Smart Groups definition is set, your devices are enrolled, your deployment is set (Associations or Deployments) - so you need at least one model update - you can deploy filesets to devices by changing a custom field value - model update is not required. As smart group evaluation runs on a regular basis, it's not as immediate as hitting model update, but the main advantage is that you can use API or scripts to trigger the change.
  2. Quick look at the service logs shows that we sometimes experience time out when contacting teamviewer (could see that it happened when you triggered session). We're investigating - I'll update this thread as soon as possible.
  3. If this is a one shot operation, you can right click on an existing smart group and apply custom field values to all devices currently in the smart group (to be precise, all devices in the current version of the smart group). So if you have already some smart groups based on IP that you want to convert, you can assign custom field value for each SG easily. If this is too time consuming because you have already hundreds of smart groups, I'd go with script / API approach. You may already have a good old spread sheet with the list of serial numbers for each building ? then you can use the API to assign the custom fields based on the serial. If you have 1:1 and enforce authentication against Active Directory during enrollment, you may already have the information in your LDAP system (who is attached to which building) - and if you have it in LDAP, you can create a custom field based on LDAP, FileWave will sync inventory with your directory, and you can have smart groups based on these custom fields. As you see, you have a lot of options, it really depends on what you want to do (one operation, something updating regularly, something directly synchronized with your directory...).
  4. Sorry, I missed this question - answer is very late, but hopefully better late than never. Indeed, we had a bug reported in FileWave 14.7.2 where Native Admin would fail to display properly some inventory data in clients view. When fixing this issue for 14.8.0, one case was not managed properly, which would lead Native Admin to incorrectly save the column names in local settings. This issue has been fixed for 14.9.1 - your console should now behave properly for both issues - data should be properly displayed, and the columns should not be gone after restart. Sorry for the inconvenience.
  5. Actually this should not be read as "-220" but as list bullet points. So exit 220 should do it. Just seeing that https://fwkb.atlassian.net/wiki/spaces/MAN/pages/4719213/5.11.+Fileset+Scripts could be updated to give more details about requirements scripts and specific exit codes.
  6. On iOS, you need to install: TeamViewer Quick Support https://apps.apple.com/app/teamviewer-quicksupport/id661649585 (and not classic Team Viewer). our native kiosk Once the device reports that both apps are installed, the option should show up. Note that to work, you need to make sure that end user accepted notifications for FileWave kiosk - when you start remote session, a notification is sent to the kiosk app with the "magic link", which tells Quick Support all information related to the remote session.
  7. We've identified an issue which can impact Apple App Store related features. FileWave still has some places where identifiers are 32b, and iTunes ID is part of them. We expected to have time before itunes id go beyond 4 billions but it happened sooner. The impact is that the process which integrates App Store data from Apple fails with an error, which can break VPP sync. While we are working on a proper fix, we made available a patch to ignore "problematic" apps so VPP sync can run through - this app won't show up in FileWave, but this won't block other apps. I'll update the thread once proper fix will be available. Sorry for the inconvenience.
  8. Correct - this is done locally between fwcld (the agent) and fgGUI (the visible kiosk / app portal), and then using the binary protocol (client / booster / server). fwcld holds a list of fileset that must be installed, and a second list of kiosk fileset. Simplifying the process, when user presses "Install", fwGUI tells fwcld to add the fileset to the "to be installed list" - fwcld will then run the process to make sure the fileset is there and respects verification setting. When the user presses "Uninstall", fwGUI tells fwcld to remove the fileset from the to be installed list, so the fileset will be removed, as if the association would be gone for a non-kiosk fileset. When a new set of manifests (either due to model update or to smart group membership change) is processes, fwcld will make sure that fwGUI state remains if the fileset is still part of the manifest, and that the winning association is still kiosk. There is no callback to the server using the http API call - all of this has been in FileWave for more than a decade, way before we added the http API.
  9. The first issue looks like a refresh issue - if you restart the admin, is the sub association showing properly ? If yes, this can be related to some of the notification system issues we fixed in 14.9. On the installation side - there is no easy way to tell Windows to install a specific driver during imaging process. The way it works is that Windows allows (via a registry setting), to specify a folder where you can copy drivers, and Windows will look into this directory when it installs and requires a driver. So when you have a driver association, what we do is that we make sure that drivers are copied in a specific directory after restoring an image, and that the registry setting is properly set to look into this directory.
  10. I'd like to take the opportunity to thank you for participating to the early access program - this was indeed an issue on our side which could not be reproduced in our internal labs but being able to witness it live helped tremendously investigating and finding a fix. Thanks !
  11. If you want to tell FileWave your cert is trusted, you can change a flag by echo "from ios.preferences_manager import PreferencesManager;PreferencesManager.set_mdm_cert_trusted(True)" | /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc shell This will tell FileWave to show only one step in OTA enrollment pages. While there is currently no plan to change this part, please keep in mind that this is not part of the public api we support and maintain, so if after upgrading FileWave this throws an error, go back to the forum
  12. Hi - not that I know, unfortunately. The closest option on Apple side (https://developer.apple.com/documentation/devicemanagement/profile?changes=latest_minor&language=objc) would be DEP Profile setting for language but it's tvOS / macOS only and it's only at activation / enrollment time. With iOS 16, Apple brought Accessibility Settings to MDM, so there is maybe some hope to see Regional Settings as well in the future.
  13. You also need to check if fwcld process is running. FileWave Kiosk is the process running in the User scope, while fwcld is the agent / daemon running as root in the background. As @Josh Levitsky answered, the icon shows in the menu bar if: fwcld can connect to the server (directly or via boosters) there are kiosk associated filesets (by default ; you can configure the client to always be visible but by default it only shows up if there are kiosk filesets). To ease support ticket, you can prepare client log (and raise log level, this usually helps).
  14. Declarative Management is Apple MDM future, but is still in early stage. In 2021, it was limited to iOS devices enrolled with User Enrollment (BYOD) ; Apple extended it this year to all OSes and enrollment types and expanded available features. The challenge is for now on our side - FileWave MDM for iOS has been introduced with iOS 4 and is based on a set of commands and queries ; typically, to install an application, you send InstallApplication command with all details. To install 80 apps, you send 80 times InstallApplication commands with a different iTunesID. Declarative Management is, as the name stands, declarative, so you send one declaration with everything, and the device deals with it. Which means we have to change FileWave's internals so deal with it. The new system is actually closer to what FileWave is doing since early days : when you hit model update, FileWave computes the device manifest, which is nothing else than a list of filesets to be deployed ; and Apple's declarative management is nothing else than a list of profiles / apps to be deployed. So instead of converting the manifest into a "send InstalledXXXList, compare existing List, send corresponding InstallXXX / RemoveXXX commands", we have to convert our manifest into Apple's manifest declaration. The challenge comes with backward compatibility: iPads can use declarative management only from iPadOS 16.1 which went out on the 24th of October (User Enrollment is a niche setup). So we need to support both old and new ways to manage devices until it's ok to stop supporting devices which can't be updated to iPadOS 16.1 or macOS Ventura. Profiles have been rewritten. There are parts of the new "assets" which can be declared, and they don't match 1 to 1 existing profiles. Thankfully after a few versions Apple introduced an option to add raw "legacy" profiles the declaration, but still, we have now 2 ways of defining how to configure network on a device ; the old way for which we already have an editor and you've been using for 12 years, and the new one which has likely more features but needs to be rewritten. So, same, but not as good as the old one, why bothering then ? DDM comes with nice additions: the fact it's one big blob makes it nicer for the server. You enroll a device, the device receives the declaration from the server, then it installs the 80 apps and 20 profiles without the need to ask the server what is the next step. Less load on the server ! DDM comes with notifications. MDM server can register and then be notified when an application is installed for instance. Today, we send InstallApplication command, device responds with "OK, your command is valid, I'll see what I can do". And we've to poll the device to know if the app is installed: send APN request to Apple, device checks in, we send InstalledApplicationList command, device responds, we parse the list and check the specific app status. If we do it too frequently, your 25000 devices will overload your server. If we don't, your data will be outdated. Now with notification, we know when the app is installed. Less load on the server, and more accurate data. DDM brings on-device condition. Apple's example is "enable this Network profile only if password is 6-digit". This is something you can do today with FileWave Smart Groups, but having it on the device is way more efficient, as you don't have to poll the device for the state, and it can even work if the device can't reach out your MDM server. Ok, now you know what DDM brings - what about FileWave ? As said, we've to be super careful with backward compatibility, so we are building DDM support along with old protocol - one day we'll be able to kill the old one, but there are plenty of devices still doing their job which can't got with iPadOS 16 / macOS Ventura (and with the current context, it makes it harder to justify throwing to the bin a running device, specially when Apple said security updates are still delivered for them). The other point is conditional feature, which is Smart-Group on the device, but does not really match our platform agnostic Smart-Group feature. We need to bring this very Apple centric (for now) feature into a cross platform tool. Some years ago we started to work on something similar (client-side conditions on associations, which would allow for instance to activate the Fileset "between 8AM and 6PM local time"), but this got paused due to focus change. Maybe that's the right time to revisit this. What are our next steps ? Apple understood that DDM is a major breaking change and added since the first tech-preview multiple "help-with-transition" items, so we will be able to bring DDM step by step. In the coming FileWave releases, we would like to focus on: first step for notifications - so you know exactly when an application or a profile is installed first step for sending legacy profiles in a declaration Once we've these pieces for iOS 16+ devices, we'll be able to expand to apps installation, and have a clearer view for the "new" profiles.
  15. You may also want to check or re-create your DEP profile - assuming you're enrolling your devices via DEP. DEP profile contains the server cert (in the "anchor certificates" part) and the server cert, used to certify the communication with both MDM and SCEP server, needs to match the one in the profile. If you created the profile and then uploaded a new cert, your DEP profile may be outdated. Depending on how the cert has been uploaded to FileWave profiles will be updated and re-associated, but some workflows skip this step.
×
×
  • Create New...