Jamf binary and check in question

[szultzie]

Hi All,

So I am going back and forth with Jamf support about some issues i have been experiencing, and i get an interesting statement back....

given how the jamf binary is expected to execute; if there is no active user at any point during the 24 hour window, the binary cannot issue the commands to check-in and therefore the inventory update policy is never triggered.

I am pretty sure that is not correct, or at least it wasnt at some point in the past.

Can anybody confirm this is accurate behavior? Check-in Polices such as an Inventory Update only run if a user is logged in?

-Peter

[mm2270]

Never heard of that, and I agree I don't believe that's correct, unless Jamf changed something in how it all works recently. The check-in is controlled by a LaunchDaemon, so it runs as root, which means a user doesn't need to be logged in for it to execute. At least that's what I've known and believed for many years now.

The one issue I can see, and perhaps this is what the support person was alluding to, is that if your Mac's network connection is contingent on a user being logged in, for example, if it's using a user level certificate to connect to Wi-Fi, AND you do not have a Login Window Wi-Fi configuration profile applied to it, then the Mac may not have a network connection when someone isn't logged in. If that is the case, then they are correct in saying that a Mac can't actually do a "check-in" with Jamf Pro when sitting at the login window. The LaunchDaemon will still kick off when it needs to throughout the day, but as it wouldn't have a connection to the Jamf server, it will never run any policies, including the inventory collection.
That of course doesn't apply if there is a hardwired Ethernet connection in place.

Could that be the case here?

[szultzie]

So i have a test machine that last update was yesterday at 11:29 am, The checkin is working as expected, last checkin was a few minutes ago.

I will see if it runs the built in Inventory Update payload policy (unless the issue is the policy?)

Yes my mac is hardwired, shouldn't have the wifi issue you stated above.

[diradmin]

@szultzie Reference the Jamf's name and your support case # and escalate to your CSM. They can then escalate the case to someone within support that actually knows how the product functions.

Support giving out incorrect information is happening far too frequently and needs to be remediated.

[larry_barrett]

MacBook/iMac school here:

Any laptop with the lid closed will not and cannot communicate with JAMF. Any laptop that's asleep will not and cannot communicate with JAMF.

This has nothing to do with JAMF, this is how MacBooks work.

A hardwired computer with Wake for Wi-Fi network access enabled is going to communicate for a day. Unless you have a way to wake it up (with a user logged in), that bad boy is done checking in indefinitely. Source: Every iMac in my building over the summer.

That all being said: If anyone has a way or method to allow checkins (and even better, the ability to run policies on macbooks with the lid closed), please, share it here. You'll take 30 days of work off my summer checklist.

[Brad_G]

@szultzie , how is your inventory policy setup? Do you see where it's run in the machine's policy log history?

We had an issue where the built-in policy for inventory wasn't running with consistency. According to the logs the policy would run but it would never submit any inventory or update the machine record in the JSS. That policy simply had "Update Inventory" checked under the Maintenance category.

We ended up creating a new policy and under Files and Processes category put /usr/local/bin/jamf recon in the "Execute Command" area. Running the inventory from the jamf command line has worked consistently for us where the built-in option in the policy would not.

A colleague of mine worked with Jamf support, but they were never able to figure out why the built-in policy wasn't working like it should.

[szultzie]

@larry_barrett We are not in the situation you are seeing, but i did solve it for a laptop lab... you have to make sure you have a hardwire connection to the laptop and power, then close the lid and it shouldn't go to sleep, assuming you have your power settings properly set up to not allow sleep on plugged in power

@Brad_G Yes i am using the built in "Update Inventory" payload. I even explained that to the tech, and it was actually set that way up during our JumpStart about 4 years ago. I am pretty sure it worked fine up until recently. Another couple hours I will be able to confirm the behavior, as my test machine is approaching 24 hours for the last Inventory Update. It is sitting at the log in screen.

If this is the issue, Jamf support should know that the work around should be the "Files and Processes" payload... here is what i got back as a work around, and i think this is my elevated support person already...

- Log in with a local admin account via ARD and run the recon command locally via Terminal. - Access the machine via SSH and run the command in Terminal. - Set up a daemon on a timer which runs the recon command, or calls the policy to then run the recon.

[ike]

The Recurring Check-in event on macOS is a launch daemon so it will execute every 5/15/30/60 minutes regardless if a user is logged in.

[diradmin]

@ike Please advise your Jamf colleague of the same.

[szultzie]

Update...

My test machine did another Inventory Update to day at 11:43 am, ruffly 24 hours later, wih NO user logged in.

So my Jamf contact is wrong, or its not the "expected" behavior.

I agree that Jamf support is getting horrible, and also does your Jamf Buddy and Success person keep changing like ever 3-6 months?

So thank you all that have confirmed how the checking works, i thought i was going to go crazy if it was working like the Jamf tech said.

[diradmin]

@szultzie >>also does your Jamf Buddy and Success person keep changing like ever 3-6 months?