declarative management of devices...what does it mean in FileWave?

[sean_a]

So, in regards to Declarative Device Management (DDM), I sort of get it.

Sort of.

Apple talks theory (see link from WWDC 2021), but what are the nuts and bolts, as it relates to FileWave?

[Pierre-Nicolas]

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.

[sean_a]

Speaking only for myself, though I would think a sentiment shared by others, I greatly appreciate your exhaustive, detailed answer to my admittedly open-ended question to this topic.

I look forward to FileWave's developments with DDM.

Thanks again!!