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
Reboot Notifications
+3Best answer by oluna777
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 0I'd say you have 3 main options.
- Have your script check uptime before prompting anyone
- Add an Inventory Update on Startup for machines in the same group
- Use a different solution like the root3nl Support App to nudge your users into regularly rebooting.
+7We 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.
+8We 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.
I second this. We have a similar policy and have it set to once a day.
+4As 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
+3As 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 0Thank 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?
+4Thank 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?
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.
+3Correct, 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.
Great - thanks again for the help!
+2@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!
+3@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!
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!
+2I 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!
Hey no worries at all. Thank you for the reply. 🤙
+5As 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 0I am searching for a reboot notification too. I'd like my users to be notified every 12 days after their last reboot. Security Policy wants everyone to reboot every 14 days but I'm giving them 2 days notice to reboot. I used the above script but it seems there is another script to run after yours (This is what I would add to your script:). Do you know what is the script is that needs to run before yours to trigger the reboot alert?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.