Recon after micro update

[Scotty]

So we started pushing out our first micro update (10.14.4 combo) and I noticed when a machine hits the dead line, it will install the update and reboot as intended. However when it comes back up, its not updating the JSS that its on .4 and since its past the dead line it tries again.

Im thinking I know the answer but I wanted to check, i'm thinking i need inventory update scheduled to run at startup, and/or reoccurring check in. We dont reboot often so that shouldn't create too much extra work on the JSS.

thoughts? FYI: Im just using patch management, with the update pkg uploaded.

[mm2270 · Accepted solution]

Yeah, if there is no recon taking place after the update and reboot, then the Jamf Pro server will still have a record of the machine being at the previous version. It's an age old problem actually. Especially with products that force a reboot after installation like these. It's not as much of a problem for regular updates since you can specify that an inventory collection should take place after those. But if a restart interrupts an inventory collection, you'll be left with out of date information.

In the past we solved this with a special package that would install a script and LaunchDaemon. After reboot the LaunchDaemon would kick in and run the script that would check to make sure the Mac could connect to the Jamf server, loop several times if it couldn't, and once it could, send in new inventory. The only reason we did it this way was because inventory set to happen at startup means the Mac has to have an internet connection (read: hardwired) at startup. If it's using wireless that doesn't kick in until after someone logs in, the recon at startup will fail. Just something to think about as you design this out.

[Scotty]

@mm2270 Excellent info and more!

This is what I was starting to wrap my head around for sure. I was thinking simply adding a check in to startup would do the truck but I didn't think about the Wireless connection. The LaunchDaemon is a solid option we might end up using.

For now, Im thinking it would be best to remove the micro updates from Patch Management and use a custom script and policy to do them. We also are not happy with the deadline features (specifically the lack of prompts) in Patch Management, so a custom script a prompt will do the trick. trigger one time, so it doesn't run again after they reboot.

But I will keep the LaunchDaemon and loop script in the back of my head

you rock!

[Scotty]

addition question, does anyone see an issue with having it run inventory at logon or startup? our users done reboot often so it should be a huge deal and that should solve this issue altogether. no?

[jramm]

@mm2270 Would be able to share your script and LaunchDaemon?

[Kyuubi]

@mm2270 I would also be interested in seeing that script and LaunchDaemon if possible?

[mm2270]

Hey all. For those asking about the script I mentioned, while I do not have that original process anymore, I actually came up with something considerably better (or at least I think so)

I'm posting it to my GitHub repo shortly and will post back here to let everyone know when it's available. I think what I came up with will make performing post reboot recons much easier to implement. There won't even need to be a package to deploy. It's just an initial script that needs to run on your Macs, and from there you'll be able to add something into the Advanced > Run Command field of a policy to tell the Mac to do a recon on next reboot.

[Surajit]

@mm2270 Hello Mike, please let me know once you post it on GitHub, even I am waiting for it to use with Catalina upgrade.☺

[mm2270]

@surajitbpn Thanks for the nudge :) I had forgotten to get that posted up because I started doing some other cleanup stuff related to my GitHub items. I'll work on getting the process posted up and will comment back to this thread once it's there.

[mm2270]

Ok folks, @surajitbpn, @Kyuubi, @jramm, and anyone else interested, I finally got my GitHub repo updated (renamed and somewhat cleaned up actually), but more importantly, I added the script I was referencing above.
You can find the description of it here on the README, and the actual script is located here. The script itself has most of the same comments as in the README.

Try it out and let me know if it helps you, hurts you (hopefully not!) or if you run into any issues etc. Issues can be submitted to the repo as well and I will do my best to respond accordingly.

[raphhyyy]

@mm2270 - thanks for the update!
It seems to be working with the test machines, but just shows Failed in the logs - would that be normal?

[mm2270]

@raphhyyy No, it shouldn't be showing "failed" as far as I know. Are you testing it with Catalina or Mojave? I had done a bunch of tests on Mojave with no issues, but hadn't gotten around to testing under Catalina, so I will do that now to see if anything in the script has to be adjusted for it.

[raphhyyy]

tested with Mojave

[mm2270]

Ok, so let me make sure I understand. What's showing as Failed is the command to flip the plist setting to "TRUE" to enable a post reboot recon? If so, that's odd. Is the Execute Command the only item in that policy or do you have other items executing in it as well? From the log you posted it looks like it's the only item in it, but I just wanted to be sure.
What trigger is running that policy? Check-in, or something else?

I don't see anything in the log that indicates a failure, other than the fact that it says "Failed" in the log status window in the background. I'll have to run some more tests, but off the top of my head, I don't see a reason why it would be registering as failed.

[mm2270]

@raphhyyy Quick follow up.

Set up two new policies. One to deploy the script that creates the LaunchDaemon, local script and plist file. I let it run on a 10.14.6 Mac by the check-in trigger. I let it run on it's own, so meaning the Jamf LaunchDaemon triggered it, not me in Terminal. No issues. It created all the files and plists as designed.
Second policy was created to flip the setting in the local plist file to true. Also set up using the check-in trigger and allowed to run naturally, on the same Mac. No issues. Here is the policy log for that, which essentially matches that of what you posted above, minus the customization of the plist name of course.

The only other difference is my command used true, and not TRUE I think both should work, and I will test that to see, but just in case, try using lowercase. Maybe it doesn't like the uppercase TRUE in the command?

Other than that one possibility, I don't have an explanation on why you'd be seeing those failures. I would check any other payloads (if there are any) in the policy to see if something else may be causing it. Or check to see how it's being triggered, when and so on. Maybe something else is affecting it. Without any more detail in the log on why it's seeing it as a failure, its pretty hard to troubleshoot.