Custom frequency rates for Policies

[spalmesano0]

• customer-shackleton: Gong snippet.

• @noahtalerman: customer-mozartia requested this because they want to install several apps when a host enrolls to Fleet. They want end users to be able to remove those apps if they don't want them.

• @noahtalerman: For enrollment, we can use Fleet's setup experience

• @noahtalerman: For apps installed after enrollment, in the interim, we could help them tweak the policy to check for the receipt.

  • This way, the policy will still pass after the software is installed and later removed by the end user.
  • @nonpunctual: Watch out: In some scenarios, the receipt might also get removed.

---

[noahtalerman]

Problem

customer-mozartia would like to deploy an app to all end users, but allow end users the ability to remove the app without forcing an automatic reinstallation from Fleet.

What have you tried?

Deploying apps through Policy Automations to a temporary Team, then manually moving hosts to a permanent Team that does not have the Policy Automation in place to install the app.

Potential solutions

Allow admins to set a custom frequency for how often they want Automations to run. Some examples include:

• Once
• Every X days
• Every X minutes

What is the expected workflow as a result of your proposal?

I create a Policy Automation and select the frequency for how often I want the Automation to run.

[noahtalerman]

• @noahtalerman: For enrollment, we can use Fleet's setup experience
• @noahtalerman: For apps installed after enrollment, in the interim, we could help them tweak the policy to check for the receipt.
  • This way, the policy will still pass after the software is installed and later removed by the end user.
  • @nonpunctual: Watch out: In some scenarios, the receipt might also get removed.

Hey @ddribeiro can we get your team's help on this?

[ddribeiro]

@jakestenger Do you want to take a crack at this? TLDR is we want to craft a policy that will pass if a specified piece of software has ever been installed on a system, not just if it's currently installed.

I'm thinking maybe we could use the plist table to parse the /Library/Receipts/InstallHistory.plist file to see if the desired software title has ever been installed on a system and get to the policy to pass if it appears?

I think this seems more reliable than checking for a .bom or .plist in /var/db/receipts/

[jakestenger]

This will only work for Mac App Store / VPP, and .pkg installs. Drag and drop / .dmg installs don't write to /Library/Receipts/InstallHistory.plist

SELECT 1
FROM package_install_history
WHERE package_id = 'com.tinyspeck.slackmacgap'
LIMIT 1;

This will work if it was ever installed as a MAS/VPP or PKG or if it is currently installed (any method).

SELECT 1
WHERE
  EXISTS (
    SELECT 1
    FROM package_install_history
    WHERE package_id = 'com.tinyspeck.slackmacgap'
  )
  OR
  EXISTS (
    SELECT 1
    FROM apps
    WHERE
      (bundle_identifier = 'com.tinyspeck.slackmacgap' OR name = 'Slack')
      AND path LIKE '/Applications/Slack.app%'
  );

I don't think there is a way to get historical data for non MAS or .pkg installs short of converting .dmg installers to .pkg or some other runner that pops a receipt file onto the FS if the app is installed. This would have to be a recurring process, like a script that runs once a day, and it would only work from the first day of deployment onwards.

[jakestenger]

FWIW, I think the original feature request has real merit for lots of reasons beyond this very narrow use-case.

[spalmesano0]

Thanks @jakestenger. I think there are many additional use cases for this.

Some examples:

• Annoying a user by executing an automation every few minutes when the host fails a really important policy that can't be automatically remediated.
• Running a policy immediately after enrollment.

@noahtalerman Our competitors do this in various ways, but I think we can do better than them on this! Jamf's "Enrollment Complete" trigger is so woefully unreliable that Mac admins recommend never using it for anything important (ironic, since "immediately after enrollment" is usually a critical point in time).

Also, there may be confusion around this as we provide an interval option for queries, but not policies.

[noahtalerman]

@spalmesano0 agreed! In the interim, does a combination of these Fleet features work for mozartia's workflow specifically? If not, what's Fleet missing?

• @noahtalerman: For enrollment, we can use Fleet's setup experience
• @noahtalerman: For apps installed after enrollment, in the interim, we could help them tweak the policy to check for the receipt.
  • This way, the policy will still pass after the software is installed and later removed by the end user.

cc @ddribeiro

[spalmesano0]

For mozartia today, Setup experience resolved the immediate pain.

If they need to deploy an app to everyone later, I can work with them to create a query to try to work around this; but this feature is still a "nice to have" for them.

[spalmesano0]

Adding :product back as shackleton recently requested this as well.