How often should I reinstall Jamf?

@dresslah Do you have users running as admins and likely to be intentionally disabling the JAMF Software? If not I'd suggest contacting Jamf Support and trying to understand why the problem is occurring in your environment as it's not generally a problem.

This is not common. This really shouldn't be happening. I've got a handful of machines on 10.9.5 with very specific purposes so they are staying on 10.9.5 & they havent been touched in YEARS & deployed on old old old (casper) jamf pro versions, they are still managed and checking in just fine.

The jamf client has become fragile ever since enrollment strings were introduced, and compounded with the need to approve an MDM Profile. Jamf can point the finger to Apple on the later, to be fair.

@sdagley Majority of users for us are Admins. But majority don't know to go into Profiles and remove the MDM. Also I've seen computers that have necessary profiles that have stopped checking in.

The issue might be lots of users haven't "Approved" the profile in Profiles. If I'm logged onto their machine, I'll make sure it's approved, however, I probably haven't done everybody.

I just don't know why some things are installed/configured on the machine, and other things fail. It does say until you 'Approve' the profile, functionality will be limited.

Also, there is a way to disable JAMF software without removing the MDM Profile?

@dresslah Based on your comments I'm guessing you're enrolling machines using a QuickAdd package. Is that correct? You might want to look into DEP as that can be configured with non-removable MDM Profiles. If DEP isn't an option you could try enrolling directly with your JSS as that will result in the MDM Profile being approved during installation.

The MDM Profile is just one aspect of Jamf management. The limited functionality without an approved MDM Profile is mostly related to other profile managed capabilities like kernel extension and privacy related approvals. The Mac will still check in and run policies.

For Macs that aren't checking in you could try running sudo jamf checkJSSConnection in a Terminal window to see if the configuration for the Jamf binary is correct. You might also try sudo jamf manage to enforce the management framework and see if that restores communication.

When first deploying, we were using QuickAdd. We've since integrated DEP, so we use that for some sites. Is DEP the only method that allows for non-removable MDM Profiles? And is there a setting to check? It sounds like if enrolled via DEP, it's automatically enabled to be non-removable, correct? Also, I'm assuming this also approves the MDM automatically?

I Re-installed the JAMF client using a policy that runs every day and that policy triggers another policy which in turns triggers the original policy.
Basically I'm always re-installing the JAMF client.

@dresslah When the MDM Profile is installed by DEP or the Enrollment page of your JSS it will automatically be approved.

I don't believe you can block removal of the MDM Profile except when it's deployed by DEP.

The setting to control removability of a DEP installed MDM Profile is in the General panel of the PreStage Enrollment configuration.

@sdagley Thanks. Trying to track down what is breaking on Inventory/Checkin. I've found that my config profiles were failing due to not being "Approved".

On those 2 machines that have been approved. It's nearly been 30 minutes but neither has checked in. Inventory was updated due to me doing a recon on each machine.

Diagnostics entries and results are below:

I've verified LaunchDaemons are active with 5 minute increment.
sudo jamf check JSSConnection = JSS Connection is active
sudo jamf manage = The management framework will be enfroced as soon as all policies are done executing.

It's been 20 minutes and neither has checked-in. What else can I check to see whats broken?

sudo jamf manage = The management framework will be enfroced as soon as all policies are done executing.

What policies are currently running? maybe you got a policy that is hanging on those machines. Try this command(increase the number if necessary) and see what's going on.

tail -n 20 /var/log/jamf.log

Was heading over to look at logs now! If a policy is stuck, how do I clear it out?
Does this correlate to the "Waiting Room" folder in /Library/Application Support/JAMF/Waiting Room ?

@sdagley So last CheckIn was 09/20/2019 at 2:22 PM
Found this in logs as the policy that kicked off at that time: Fri Sep 20 14:25:28 Mason Prince Macbook jamf[15512]: Executing Policy Test Disable MacOS Update Settings

After this, the logs show it continues to check for patches and policies but never updates to JAMF.

Then on 9/23, the syntax switches to this: Could not connect to the JSS. Looking for cached policies...
Checking for policies triggered by "recurring check-in" for user

Then JAMF framework was updated on 9/23 as well, and then no data until I did a jamf policy today.

Mon Sep 23 09:53:59 Mason Prince Macbook jamf[19963]: Upgrading jamf binary...
Mon Sep 23 09:54:02 Mason Prince Macbook jamf[19963]: The management framework will be enforced as soon as all policies are done executing.
Tue Oct 22 14:26:22 Mason Prince Macbook jamf[3619]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.bgrecon.plist...
Tue Oct 22 14:28:56 Mason Prince Macbook jamf[3924]: The management framework will be enforced as soon as all policies are done executing.

So, just checked it on another machine, same results. It appears the Check-In portion broke when I pushed the policy "Executing Policy Test Disable MacOS Update Settings"

Majority of computers got this just fine and are working properly, with the exception of 40-50 computers.
Lots of users that currently aren't checking in show completed for the policy. I've flushed it on one to see if it would clear it up.

What's the solution here to untwist this other than just reinstalling JAMF?

Ive been seeing this more and more often where i have to re-enroll a computer. Ill run a sudo jamf recon and itll kickback an error about invalid device signature.

That being said all my failures are computers that were before my DEP workflow and used quickadd. As i get computers back i put them into my DEP workflows

I envy the people that can use DEP. We are a BYOD environment, so DEP is out of question and we suffer a lot from Macs that can't connect any more, can not install apps via Self-Service any more and so on. And I don't think that most cases are due to bad actions of the users with admin privileges.

Tracked it down to a hung policy that showed Completed but I guess never got cleaned up. If I issue a 'killall jamf' and then do a 'jamf policy' in Terminal, it seems to grab everything and Check-In continually.

My problem now is, I wrote a script containing these 2 commands. The jamf.log shows it executed it, but Jamf policy log never changes from "Pending". Also, after the script ran, it DOES NOT Check-in, so don' t think is actually executing.

Is there something special to add this killall command to a script?

@dresslah Don't do that. If you put killall in a Policy script it will terminate the process that's running the Policy so you will never see it complete.

@sdagley - Gotcha. Can you advise what exactly the killall does? It seems to be the only thing that gets me working again. In the log, when doing the entry, there is a Daemon stop and exiting. I didn't know if it's just reloading the launch daemon or what.

Overall, I'd want to distribute that entry remotely (or the result of that entry) but not sure if thats possible.

@dresslah A killall jamf means terminate any process running named jamf, which would include the process running the Policy if you had it in a script. The LaunchDaemon com.jamfsoftware.jamf.daemon.plist will automatically re-launch an instance to monitor application usage so I expect that's what you're seeing in the log.

Thanks all! Came down to a simple reboot to clear out the stuck policy. Didn't even think of it, as some computers had checked in for months. How do people go that long without a reboot?! I smell a new policy coming soon.