Posted on 10-21-2022 09:59 AM
Hey everyone. I deployed a policy that runs a script which notifies users that they need to reboot their Macs. The policy is scoped to a Smart Group that contains users whose Macs have been up for 10 days or more. The issue I'm running into is that after the users reboot, they're seeing the notification again. My guess is that an inventory update isn't happening quickly enough after the reboot to remove them from the Smart Group. Can anyone help me configure this properly? Happy to provide any other details. Thanks in advance!
Solved! Go to Solution.
Posted on 10-24-2022 01:37 PM
As far as I understand, it seems that the smart group is using an extension attribute that reads the last time the computer restarted. Then, the extension attribute gets the most up-to-date data only after the inventory is posted to Jamf. If this is the case, then your policy is behaving like that because the the inventory that updates the extension attribute with the latest reboot time is not being posted BEFORE the next time the reboot policy runs.
As a personal preference, when I script I prefer to do validations on real time before assuming that the extension attribute is accurate.
This is what I would add to your script:
#!/bin/sh
# SOME VARIABLES WE NEED TO VALIDATE. YOU CAN USE HRS TO VALIDATE THE SCENARIO IN WHICH THE COMPUTER HAS BEEN UP FOR SOME HOURS. I AM USING DAYS BECASUE I PERSONALLY THINK IT IS MORE ACCURATE.
DAYS="days,"
HRS=" hrs"
# LET'S CHECK UPTIME IN REAL TIME. DON'T TRUST YOUR EXTENSION ATTRIBUTE FOR REAL TIME EXECUTIONS!
DAYS_check=$(uptime | awk {'print $4'})
# UPTIME CAN GIVE YOU MINUTES, HOURS OR DAYS. CHECK IF THE WORD 'DAYS' IS IN THE STRING
if [ $DAYS_check = "$DAYS" ]; then
# USE AWK AND SED TO CLEAN UP, ISOLATE AND CHECK IF THE DAYS IS MORE THAN 7
result=$(uptime | awk {'print $3'} | sed 's/,/ /g' | sed 's/d/ d/g')
if [ $result -gt "10" ]; then
# ALL GOOD. GO AHEAD LET'S ECHO SOMETHING FOR JAMF
echo "*** 10 DAYS VALIDATION: OK"
# THEN PUT YOUR CODE HERE, OR CALL ANOTHER POLICY WITHT THE RESTART MESSAGE
/usr/local/bin/jamf policy -event <<policy to restart the computer>>
exit 0
else
# UPTIME IS NOT GREATER THAN 10 DAYS, LET'S ECHO SOMETHING FOR JAMF AND GET OUR OF HERE!
echo "*** 10 DAYS VALIDATION: User restarted. Restart message will not show. ABORT! ABORT! ABORT! ABORT!"
fi
exit 0
Posted on 10-21-2022 01:20 PM
I'd say you have 3 main options.
Posted on 10-22-2022 08:58 AM
We do the same. In order to avoid that, set the policy to only run once per week when the device is in scope for the policy. But we have ours set to 90 days (10 seems a bit tight IMO). You could also consider setting the Update inventory to run at startup and/or login.
Posted on 10-24-2022 09:59 AM
I second this. We have a similar policy and have it set to once a day.
Posted on 10-24-2022 01:37 PM
As far as I understand, it seems that the smart group is using an extension attribute that reads the last time the computer restarted. Then, the extension attribute gets the most up-to-date data only after the inventory is posted to Jamf. If this is the case, then your policy is behaving like that because the the inventory that updates the extension attribute with the latest reboot time is not being posted BEFORE the next time the reboot policy runs.
As a personal preference, when I script I prefer to do validations on real time before assuming that the extension attribute is accurate.
This is what I would add to your script:
#!/bin/sh
# SOME VARIABLES WE NEED TO VALIDATE. YOU CAN USE HRS TO VALIDATE THE SCENARIO IN WHICH THE COMPUTER HAS BEEN UP FOR SOME HOURS. I AM USING DAYS BECASUE I PERSONALLY THINK IT IS MORE ACCURATE.
DAYS="days,"
HRS=" hrs"
# LET'S CHECK UPTIME IN REAL TIME. DON'T TRUST YOUR EXTENSION ATTRIBUTE FOR REAL TIME EXECUTIONS!
DAYS_check=$(uptime | awk {'print $4'})
# UPTIME CAN GIVE YOU MINUTES, HOURS OR DAYS. CHECK IF THE WORD 'DAYS' IS IN THE STRING
if [ $DAYS_check = "$DAYS" ]; then
# USE AWK AND SED TO CLEAN UP, ISOLATE AND CHECK IF THE DAYS IS MORE THAN 7
result=$(uptime | awk {'print $3'} | sed 's/,/ /g' | sed 's/d/ d/g')
if [ $result -gt "10" ]; then
# ALL GOOD. GO AHEAD LET'S ECHO SOMETHING FOR JAMF
echo "*** 10 DAYS VALIDATION: OK"
# THEN PUT YOUR CODE HERE, OR CALL ANOTHER POLICY WITHT THE RESTART MESSAGE
/usr/local/bin/jamf policy -event <<policy to restart the computer>>
exit 0
else
# UPTIME IS NOT GREATER THAN 10 DAYS, LET'S ECHO SOMETHING FOR JAMF AND GET OUR OF HERE!
echo "*** 10 DAYS VALIDATION: User restarted. Restart message will not show. ABORT! ABORT! ABORT! ABORT!"
fi
exit 0
Posted on 10-25-2022 08:22 AM
Thank you for providing this script @oluna777. I'm testing and so far it's working well. One question - because the script itself takes care of checking uptime, I can scope this to everyone rather than the Smart Group that I was previously using (which checks for the 10 day uptime), correct?
Posted on 10-25-2022 10:38 AM
Correct, you can do that too. Although I think that the EA can still be used to narrow down the scope and avoid sending policies that might not be required. With the smart group. you know that there is a high chance that those computers haven't restarted, whereas if you scope it to the entire fleet then it will be sending out the same policy everyday for computers that might not need it.
It will work either way. I would use both, the smart group and the script to check in runtime.
Posted on 10-25-2022 11:58 AM
Great - thanks again for the help!
Thursday
@jjgoolsky any chance you might be able to share any screen grabs of your setup for this? I am looking to try this sort of thing in our environment but not 100% the right options to pick or use and even more for the notification part. I know how to setup the smart group part.
Thanks so much!
Thursday
I would, @JBartkowiak, but I believe we moved away from this method of asking users to reboot a while ago. We likely have something new in place, but I'm a lot less involved with the Jamf side of the house these days. I'm sorry - I wish I could be more help!