Posted on 11-20-2019 09:44 AM
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.
Posted on 11-20-2019 11:38 AM
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.
Posted on 11-20-2019 12:07 PM
What do you see when you enter sudo Jamf checkJSSConnection in Terminal?
Also, did you try sudo jamf policy to force all policies?
Posted on 11-20-2019 12:45 PM
@sdamiano /Macintosh HD/Library/LaunchDaemons/com.jamfsoftware.task.1.plist looks good - StartInterval is set to 900
Thanks for clarifying about APNS. Still learning!
Posted on 11-20-2019 01:11 PM
@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.
Posted on 11-20-2019 01:19 PM
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.
Posted on 11-21-2019 01:28 PM
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.
Posted on 03-02-2020 01:02 PM
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?
Posted on 07-08-2020 08:51 AM
@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.
Posted on 11-16-2020 06:11 AM
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 :-
Posted on 11-16-2020 05:21 PM
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.
Posted on 06-17-2021 07:00 AM
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
Posted on 11-14-2021 04:47 AM
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?
Posted on 02-23-2022 07:54 AM
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.
Posted on 03-22-2022 02:14 PM
Posted on 03-25-2022 11:21 AM
We are having this same exact issue in our environment. Is there any update on a permanent fix for this?
Posted on 04-02-2022 06:24 AM
We are also having this issue. Please look into this asap.
Posted on 04-08-2022 07:59 AM
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.
Posted on 04-11-2022 07:22 AM
@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
Posted on 04-13-2022 03:41 PM
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
Posted on 04-14-2022 06:16 AM
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.
Posted on 04-24-2022 05:32 AM
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 😀
04-27-2022 06:52 AM - edited 04-27-2022 06:58 AM
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.
Posted on 04-28-2022 04:10 PM
@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.
Posted on 07-25-2022 06:43 AM
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.
Posted on 11-23-2022 04:43 AM
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?
Posted on 11-23-2022 05:11 AM
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.
Posted on 11-23-2022 05:13 AM
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.
Posted on 11-23-2022 05:25 AM
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.
Posted on 03-13-2023 05:46 AM
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.