Macs not checking in

[mthoma]

We are tearing our hair out with this problem.

Some of our Macs (random, not always the same) are not checking in with the JSS on the 15 minute Check-in Frequency set under Computer Management. This means that when a policy is available it takes sometimes hours and even days for the policy to apply to all the Macs (currently around 40 as we're still in early stages of rollout).

Our network admins say that all the ports are open to APNS. What are some of the reasons why some Macs might not be checking in? We have verified that they are turned on, plugged in (wired not wireless) and not sleeping.

[sdamiano]

On the affected macs, do you get any errors if you try to call a policy manually in terminal?

On the affected macs, do you see anything in /Macintosh HD/Library/LaunchDaemons/com.jamfsoftware.task.1.plist that would say anything other than every 15 minutes?

edit: APNS wouldn't have anything to do with check-in. APNS would only touch things related to configuration profiles. The jamf binary runs separate of APNS.

[obi-k]

What do you see when you enter sudo Jamf checkJSSConnection in Terminal?

Also, did you try sudo jamf policy to force all policies?

[mthoma]

@sdamiano /Macintosh HD/Library/LaunchDaemons/com.jamfsoftware.task.1.plist looks good - StartInterval is set to 900

Thanks for clarifying about APNS. Still learning!

[mthoma]

@mvu Thanks, I get that the JSS is accessible.

Forcing the policies works.

I still have Macs that haven't checked in since this morning at 7:48am - I flushed the policy after this time so that explains why the policy is still pending on those Macs.

[mthoma]

Logging in to one of the affected Macs seemed to have triggered the check-in and then the policy ran within a few minutes. I'm assuming that even when on the loginwindow screen (not the FileVault one) the Macs will still be able to check-in? These are all wired Macs using static DHCP addresses.

AFAIK these Macs are being shutdown overnight and started up early morning via the built-in macOS scheduler.

[mthoma]

So it appears that the Energy Saver config policy we were pushing out to the Macs was causing issues. It had the Wake for Network Access option checked off. We've currently un-scoped it, but will revisit it at some point.

[mikebookpro]

I have a handful of Macs that went through pre-stage enrollment and set up as expected with no issues but are now not checking in. Some have not checked in for a week or more. I've tried all the sudo jamf commands and get the same result with each: "command not found". I tried sudo profiles renew -type enrollment and received the message that a current management profile already existed. Eventually chatted with Jamf support and got it resolved by appending our enrollment URL with /?type=QuickAdd however that required an admin credential to run that installer. Anybody else seen this? If so, were you able to resolve without putting hands on each system?

[The_Stardog]

@mikebookpro I am having the same issue, not sure why. It happens if I use pre-stage enrollments or manual enrollment. The computer enrolls, but in Jamf Pro it never checks in (but I can see the computer). I also get the Command Not Found in terminal.

However, putting that /?type=QuickAdd at the end seemed to have fixed the issue for now. After the package installed, I was able to run sudo jamf policy in terminal and it worked. Checking back in Jamf Pro and the computer is now there and checking in.

If I figure something out I will post back.

[bugsin]

Same issue here. Attempted removed management via Jamf, ran removeFramework, deleted computer record and re-enrolled with a QuickAdd package. For some reason, still no check-in. Sudo Jamf policy / recon runs fine and verified the the Daemon exists and looks alright. Can't seem to get this figured out :-

[snowfox]

Quickadd packages are being deprecated with reduced functionality. Not sure what version of macOS you're installing on or which version of Jamf Pro you're using but recent release notes warned against using quickadd packages going forward especially under Big Sur. 10.13 onwards should really use the certificate install if possible. Either a full DEP re-enrollment or a User Initiated Enrollment via the Jamf/enrol URL. I try to avoid using quickadd packages where possible.

[ctarbox]

Today (June 17, 2021) I have a number of clients that are reporting a recent Inventory Update, but long past Check-In time.

Last Inventory Update: 4 minutes ago
Last Check-in: 11/11/2020 at 9:01 AM

I have no failed commands for these devices. When I ping random IPs, they are reporting 100% packet loss.

jss 10.29.2, macOS versions 10.13.6 - 10.15.7

Cheryl

[user-lFdRjzkONM]

Jumping on this thread...

Random endpoints managed by our Jamf Pro instance are not checking in/performing an inventory update for even more than 10 days.

Our ad-hoc solution is to request the user to run a policy from the Self Service app which forces Inventory Update (Policies -> Maintenance -> Update Inventory)

Does anyone have an idea regarding what causes it and how do we eliminate the issue for the long term?

[kacey3]

I've been seeing this more and more, lately, as well.

For example, I have 40 computers in a smart group that are all supposed to do a "nightly check up." The policy runs at Check-In, the frequency is Once Per Day, and it is limited to only run between 1am and 5am. Last night, only 13 of them ran. It's not that the others ran and failed, it's that they never triggered at all.

It's a bit frustrating, because nothing in the logs shows anything because literally nothing happened.

I checked com.jamfsoftware.task.1.plist and it looks fine. I also tested checkJSSconnection and it's communicating just fine. Policies run fine if I actually use sudo jamf policy. It's just that they aren't running the Check-In trigger.

This has never been a problem in the past, but it seems like something has become significantly less reliable of late.

[DeuTom]

Same here...

[MPL]

We are having this same exact issue in our environment. Is there any update on a permanent fix for this?

[tkolsto]

We are also having this issue. Please look into this asap.

[skythrock]

Adding my name to the list of folks who are experiencing this. I have had success fixing the issue by running sudo jamf enroll -prompt and sudo jamf policy (in that order), but obviously this solution requires me to either put my hands on the computer or try to walk the end user through Terminal, which is suboptimal. I've got a Smart Group that tells me which computers haven't checked in in x number of days, but that's not great either. And again, the affected computers seem to be randomly distributed throughout our organization, so it feels impossible to proactively deal with this.

[user-lFdRjzkONM]

@skythrock Good job on finding terminal commands which fix that issue.

What you can do as a temp solution is:

1. Consolidate those commands to a script and the script to a self service policy

2. Have an API based automation to email/message users in request to run that policy based on membership in the smart group

[ajamfadmin1810]

How will the machines get the updated policy if they are not checking in to receive that update that the policy is available in Self Service? Or do self service policies show up even without a check in? Im running into the same issue, something to do with certificate so I think i will need to run what @skythrock suggested on these machines. @skythrock does this prompt for an admin user and pass? or just user password, the sudo jamf enroll -prompt command that is

[skythrock]

Yes, the sudo jamf enroll -prompt command does require a Jamf admin username and password, so that would be an obstacle to pushing it out as a self service policy.

[user-lFdRjzkONM]

It's a great question regarding the policy. From my findings - Pendo Self Service updates without a dependency on checks in/inventory updates. Moreover, I was talking about a long term solution rather than a short one. We all have those cases where you have no choice but to physically access an endpoint 😀

[mikebookpro]

Hi all, thanks for the responses. I'm curious if you've noticed any regularity with regard to business department/team and the MDM drop offs? Asking as we have discovered a handful of our engineers who during the course of a workflow end up breaking the device certificate which in turn causes a break in MDM sync. 

[ralpmets]

@mikebookpro What are your engineers doing to cause the device cert to "break", causing the MDM sync to not occur? I'm wondering if this is what we're experiencing as well. 

[SmallCompanyMac]

I am also experiencing this issue. Random devices that are not checking in and not updating inventory but are on the network. Still hoping to get an answer from Jamf support. 

[user-mgregory]

We have some machines doing this now as well seem that they all broke on our about 8.31.2022-9.2.2022. What was the solution here?

[SmallCompanyMac]

For us, the solution ended up being running:

sudo profiles renew -type enrollment

on each affected computer. But the root cause was us accidentally making the management account and the automatically created user account with the same name. 

[user-mgregory]

So you have to actually get to each user and manually do something? its not the end of the world, but these folks are all over the place.  

[rsantos]

But the root cause was us accidentally making the management account and the automatically created user account with the same name. 

---

this causes an issue?  I'd love to know more about this, since I think we've been setup that way for years!  do you have a link I can chase or anything where I can learn more?

[user-mgregory]

Can you expand on that? You made your local admin account the same as the users account? Im confused on that wording. 

[rsantos]

sorry I misunderstood - fresh eyes now and reading this properly - we are NOT making local admin account the same as the users account.

[SmallCompanyMac]

We did, which was rough. There are some other tools you could employ if your issue is different than ours. There's a connection healing tool that jamf support walked us through that may work for you that didn't work for us.

[user-OslMYbXoKj]

We see this consistently. It’s more or less impossible to get devices to consistently check-in according to the check-in policy, which makes remote administration (we aren’t a school, folks aren’t on the same network, devices are sometimes across the country) completely unusable.

We are moving off of JAMF at first opportunity.