App + script + OS setting library

[noahtalerman]

• @harrisonravazzolo: Deduplicating apps is worthwhile as a user, and it's also helpful for scripts, and profiles. In other platforms that have done this well, there are certain key/"celebrity" apps like Zoom, Chrome, etc that you want to patch pretty much immediately with as little IT intervention as possible. E.g. "ok here is Chrome. I want it to be up to date within 1 week after release." You can have multiple instances of the same app, e.g. Docker. All of the engineers got one version of Docker, and the other group got a different version of docker. That was all controlled with multiple "instances" of an app in the library. Couldn't reference both of those Docker app instances from the same team. Things other than apps in the library? You could have config profiles, custom scripts, and apps from various sources could all be in the library and you could attach them to particular teams (or the equivalent). It's nice to be able to pick "Latest" AND for all of the explicit versions to be available in a picklist. But "Latest" is probably more important. Why would you extrapolate config profiles and scripts to the library? Same reason: deduplication; or like engineers might want their computers to sleep at different intervals. When adding a library item, you can choose what it applies to. You could do that from the library or you could do it from the team itself. When you have scripts and apps and config profiles that are the same on every team (which is most of them), you want to deduplicate them. In our case, we turned off Chrome updates in Google Workspace and used the MDM instead (we're already in MDM anyway, might as well do it there.)

• @nonpunctual: This is relevant even at larger organizations. (At 700+ employee companies, do they still need this much of a turnkey solution?) It seems that way. Many companies use tools like Munki, or are using Fleet to move completely over to GitOps. But on the other hand, there are a lot of (even very sophisticated) customers who don't, and want it to be simple. So it's like everyone wants simple solutions, but the simple solutions aren't compatible/available to you based on various enterprise restrictions or cultural mismatch with other more downmarket-focused products. Innovation has stalled somewhat in legacy MDMs, and some competitors have been slowly chugging along on this for 10 years. If you're a company that's heavily reliant on Adobe stuff for content creation and fonts. If I didn't have Google Workspace, I'd use the MDM to manage Chrome versions

• @mikermcneil: If we accomplish it with a hacky script, make sure it's not a db migration and that it's fully documented as a supported feature. If we do it the other (complete) way, I think we go ahead and do it for scripts and config profiles too at the same time. This is the biggest net benefit for users and thinks long term, avoids duplicating work and adding surface area. Harrison's description does a good job painting the picture of how it could work. I think we should consider getting rid of inheritance at the same time, with a one-time migration for compatibility, or otherwise would need to call it Fleet 5. Or keep inheritance for policies and queries, but if doing that it's more complicated (maybe still the right choice, unsure haven't thought through it). Would need to work w/ customer's timeline though.

Gong snippet: https://us-65885.app.gong.io/call?id=5675275036186430438&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1349%2C%22to%22%3A1436%7D%5D

Problem

A white label MSP wants to build features to install the same app on hosts that belong to many organizations. The problem is that apps are unique to a team in Fleet.

Potential solutions

Noah: Handle this complexity in the white label app and build features around the way Fleet works today: app is unique to team.

Noah: App library in Fleet.

Luke: Pure hack solution: Write a database migration that will populate all “teams” with the same software items (including URL) from a target team.

[allenhouchins]

We definitely need an easy way to deploy apps, scripts, profiles, etc. to multiple groups of devices. However, I'm not sure if this should be accomplished via Teams or via Labels though. Here are some thoughts and use cases in no particular order...

• Everyone is using "Teams" differently. On dogfood, we use it to group device classification. Others are going to use it to group devices by department, teams within a department like an engineering guild, etc (or a mixture). Labels are an easier way to group app deployments dynamically. Teams is more static or driven by initial enrollment secret.
  • A security use case to consider is to enroll your devices into a "No team" waiting room or quarantine until you can verify the authenticity and security of the device then moving the device in to a Team that is receiving corporate settings.
• Use case: InfoSec requests an updated version of an app deployed. Very cumbersome to go team by team.
• Use case: Onboarding, all new hires should receive X app or setting (Slack, VPN app, Security Agent, etc).
• If we start supporting "All teams", we will need an interface for an "All teams except" selection process too. Ex: I need Zoom on all end user devices, regardless of team, but not include the "Servers" team/devices. A select list is likely the best way to accomplish this. Or put the onus back on the customer, and give them the flexibility they need, by making this feature available through dynamic Labels.
• Major product differentiator is if we can say put Google Chrome on all devices in this team or label and its OS agnostic.