Pierre-Nicolas

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.

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.

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...).

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.

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.

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.

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.

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.

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.

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 !

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

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.

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).

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.

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.

For our French speaking community, @Guillaume Gete shared some details on his blog : https://blog.gete.net/2022/10/24/comment-bloquer-macos-ventura/ - he's pointing to the same script as shared above, but lots of good info there (as usual ).

Usually : Apple announces major changes during WWDC in June - that's the time we start working on integrating changes into FileWave - and we test with beta versions for the next month. Apple is not 100% clear about what we are allowed to disclose or not - when we sign for Apple Seed program to download to early access, Apple makes it clear the content should not be shared publicly, even the vast majority of the information is shared either by Apple directly or by the Apple community. But we can't say we support macOS Ventura until macOS Ventura is out - and history has shown that there may be changes between the last RC and the release, even for MDM features, so we'll run final round of testing on macOS 13 release before we claim "we support it". That said - unless there is a very huge change between RC and the release -, our current testing shows that FileWave 14.8 works with the current beta / RC (new OS name is known too late to be added to 14.8 so it will be reported as generic macOS Intel - something to change), and new features like the usual profile changes will come very soon in the coming version.

As far as I know, there is a disconnect between Preferences / Security & Privacy and the profile itself. I tried on macOS Ventura - deploying a terminal app (Alacritty) and a TCC profile to grant full disk access. While the profile / management details confirms the value is accepted: But Preferences say differently: Doing this, the terminal app I deployed could access all folders (tried as well with Desktop), which I could not before I sent the profile. So I would not rely on Preferences / Privacy and Security pane, only on Profile details.

The issue is limited to the notification system - all boosters are connected to the server (for notification, boosters are not chained, they all go directly to the server). Notifications are used for various internal needs : it is used when you upgrade boosters from FileWave admin, or it can be used when you remove a client from FileWave - this invalidates the client certificate used by the device, and a notification is sent to all boosters to tell them to update their CRL (Certificate Revocation List), to ensure a removed device can't connect to boosters. The issue is that the server requires notification peers to have a unique name, and it closes any connection with the same name when a new one occurs. So as all our boosters have the same name, the notification system is constantly dealing with "same" booster reconnecting. This has a negative impact on features using notifications on boosters (as mentioned, booster upgrade mechanism may be degraded), but also has an impact on server performance as it has to recycle resources constantly for each re-connection. To reiterate, it limited to the notification system, not on how you name your boosters and how you set them up for fileset delivery.

I would go with inventory based SmartGroup: So : all iPads, but where state is *not* pre-enrolled. Pre-assigning license was advised by Apple to ensure apps can be installed as soon as possible, as assigning licenses may be delayed on Apple side (specially in Summer time when most K12 systems are going back to school). Since then Device-based licensing has been added and are supposed to be much faster, but we still pre-assign license to speed up initial enrollment.

There is no known restriction yet (or at least Apple did not document it). The way to go is to deploy the Wi-Fi setup via profile ; in this case the device will not offer to copy or reveal the password.

We have identified an issue happening for setups with multiple boosters ; this issue is linked to NATs, the internal notification system, and how it is configured on boosters. Boosters are currently incorrectly configured to have the same server_name while NATs expects each booster to have a unique server_name. FileWave 14.9.0 fixes the configuration, but in the meantime you can fix it by changing the following booster setting: In /usr/local/etc/filewave/nats or C:\ProgramData\FileWave\FWBooster\nats remove in booster.conf files any line with server_name: "FileWave NATS Booster" and restart boosters. Sorry for the inconvenience.

Currently, only one LDAP server can be used for authentication - the one you select in preferences. When you enroll a device, the only information captured will be the username. Having multiple LDAP servers / enrollment authentication is not possible yet, this is a feature request (this has been brought a few times during last US training day meeting). A possible workaround would be to go via custom field. Thinking quick, but I'd add a custom field to indicate which server to contact, and have a script which would read server, user name, and then populate another customer field with mail based on LDAP query - another option is to go with export / import but it's less automated.

You can configure how frequently FileWave will request iOS (iPadOS, tvOS) devices checking in preferences: Default value is once every 24h. Apple MDM works as follows: device reacts to APN (Apple Push Notification) request, and connects to MDM server MDM server responds with an MDM request, which can be a Query (typical : Device Information) or a Command (for instance: InstallApplication) device responds to the request (acknowledge, query data, error...) if any, MDM server sends next request, or "You're set" message. So, when FileWave needs to do/read something on the device, it adds corresponding commands to the device command queue and send APN request to Apple. Apple will then order the device to check in and the process starts. Above setting will add everything Inventory to the command queue ; opening Client Info as well (this allows us to show the most up to date data in Client Info). But after model update, if anything changed for this device, checkin will be requested to install or remove apps or profiles. If the device enters a smart group, same happens. If the device is not contacting FileWave, you can check: is your server able to connect to Apple APN server ? is your APN certificate up to date and valid (you need to be careful when renewing the certificate each year) is FileWave server running ok ? The main component used to deal with Apple APNs is what we call the "scheduler" (to avoid server heavy load, APNs are sent by batch and not all at the same time to make sure not all your devices connect to your server at the exact same time). As @Josh Levitsky mentioned, if you're sure you don't have network / firewall issue and if your APN certificate is good, then it may be a FileWave issue. I'd start with restarting the services (assuming you're running service on prem), and then contact our Support to figure out what could be the issue.

Restarting the server should not trigger mass verify / inventory report. Inventory report is triggered locally by desktop clients and via persistent scheduled task (persistent means it will resume as it was before restart) server side. You may be able to trigger a mass verify using the API: /api/devices/v1/devices/verify takes a list of client ids (which can be fetched from other API call) and triggers verify, which in turn triggers inventory report. I'd just be careful using it too often as this may cause some load on your server if all devices report in a short timeframe. Clients are designed to wait a random time before reporting (based on tickle time), APNs are not all sent at the same time, Android EMM is also working based on batch size so the load will be spread, but it will nevertheless impact the server if you do it too frequently.