Skip to main content

Hi folks,

We have a policy for our Core Apps that is set to execute once per computer each day and is triggered by a check-in. This is to ensure that users don't delete apps that they shouldn't delete, and if they do then running this policy should re-install any apps. There are multiple apps that use this same event trigger "Core-Apps".

I'm currently in the process of developing a new enrolment procedure, however in testing it appears that a recurring check-in is occurring and when this happens, the enrolment process halts until the Core Apps policy has complete. As you can imagine this increases the time it takes to perform the enrolment. The Jamf.log states the following:

"Checking for policies triggered by "recurring check-in" for user..."

Previously, we have used this trigger to install all the core apps during enrolment, however this doesn't provide very good on-screen feedback, so instead of this I've created separate enrolment policies for each app so that better feedback can be shown on-screen using swiftDialog, so ideally I'd like to keep it this way.

Having a look, some suggestions seem to indicate that stopping the Jamf daemon using one of the following commands should work:

bin/launchctl bootout system /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

or 

/bin/launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task.1.plist"

However, I've tried both and the check-in is still occurring during enrolment.

Any ideas on how to stop the check-in happening?

@rcoleman I don't have advice on stopping the checkin process, but I used a different approach to prevent policies that automatically remediate core apps from running during enrollment. I created a Smart Group for Macs that have not completed enrollment (my enrollment script creates a flag file once enrollment is successfully completed and an EA reads that flag to determine when a Mac falls out of the Smart Group) and that group is used as an exclusion for all of the automatic install policies.

@rcoleman I don't have advice on stopping the checkin process, but I used a different approach to prevent policies that automatically remediate core apps from running during enrollment. I created a Smart Group for Macs that have not completed enrollment (my enrollment script creates a flag file once enrollment is successfully completed and an EA reads that flag to determine when a Mac falls out of the Smart Group) and that group is used as an exclusion for all of the automatic install policies.


Yep that makes sense and seems like a very good idea. Many thanks, I'll give that a go 😊

We use a smart group for Macs enrolled less than 24 hours/1 day. We use this as an exclusion for policies that are recurring check-in triggered but we don't want to run during enrollment or for policies like removing admin rights where we might need the user to be admin during enrollment for other reasons, but remove admin rights a day later. Then after 24 hrs/1 day the Mac will run policies as expected.


We use a smart group for Macs enrolled less than 24 hours/1 day. We use this as an exclusion for policies that are recurring check-in triggered but we don't want to run during enrollment or for policies like removing admin rights where we might need the user to be admin during enrollment for other reasons, but remove admin rights a day later. Then after 24 hrs/1 day the Mac will run policies as expected.



We also have a policy that drops a file on the Mac at the end of the enrollment process. We use the receipt for the install of the file in a different Smart Groups for Macs that are "Enrollment Complete" or "Enrollment Not Complete". We also use that group as exclusions for policies we don't want to run during enrollment, we don't want running if the Mac isn't correctly/fully enrolled, or we don't want a policy showing in Self Service if the Mac isn't correctly/fully enrolled.


One of the things I learned early one, was to not connect unrelated things. Instead of having all your core applications using the same Core-Apps trigger, instead give each of them their own trigger. Also only have one trigger per policy if you can help it, this makes troubleshooting MUCH easier.


 


Use device check-ins to your advantage and leverage smart groups to force the applications to install on devices missing the applications.


 


My suggestion:



  • Create one smart group for each of your core applications to report on if it is installed or not.

    • You may need Extension Attributes depending on where some of the applications install.

    • Make a catch all smart group checking for all the applications to know if a device is compliant and has all the applications installed.



  • Create a "force" policy for each of your Core Applications.

    • Occurrence: Once Per day (this stops the policy from looping while Jamf is updating its inventory)

    • Trigger: Check-in, and possibly enrollment depending on your needs.

    • Target: All Users, All Computers

    • Exclusion: Smart group for Devices with the given app installed. Once inventory updates, and Jamf will know the app is installed it won't run the policy again. If the App gets removed, Jamf will know it is missing at next inventory update, and rescope the policy to force the install. (this is your compliance force)

    • Do not put an Inventory Update on this policy. 



  • Create an "on demand" policy for each of your Core Applications.

    • Occurrence: Ongoing

    • Trigger: Self Service (if desired), and set a custom trigger unique to the application

    • Target: All Users, All Computers

    • Exclusion: None



  • Create a script to call each of the core app policies. (Optional for a single policy configuration to ensure everything runs in the order you want)

    • Something simple like sudo jamf policy -event install_security tool 1 and sudo jamf policy -event install_security tool 2 and so on.

    • Create a policy to deploy this script.

    • Deploy the Script as you see fit, enrollment, self-service. one-click button for a tech or user to run. 




 


You can merge the "force" and "on-demand" policies if you want but keeping them separate has a lot of advantages and allows you to ensure the policies you call from events do not mess with forcing the applications to be installed. 

Many thanks everyone for the suggestions. Will certainly take all of this on-board.

This is actually a great thread, and good advice in here.


I was going to do something like this to prevent just this and I got some good ideas! 👍

Reply


Terms & ConditionsCookie settings