Build up of pending management commands

[CasperSally]

Does anyone else notice when poking around their machines management history a build up of pending management commands (CertificateList & ProfileList over and over).

We're seeing this for our shared machines mostly, the ones in carts or labs. Like 10 to dozens of pending commands per machine, but on same machines there are successful management commands same day as well, it's not like they're all stuck pending.

JAMF's answer has been to run a sql command to clear them out, but I'm curious as to why it's happening, and really not sure running a sql command every X days is something that's normal or to be expected.

Appreciate any thoughts.

[bjones]

Question i am having the same issue as many when looking at the Management console on multiple systems i find that alot of the commands are pending and a few systems have all configuration profiles going through with no problem.

I went to one of the systems in question and ran the following :
sudo jamf removeMdmProfile
sudo jamf manage

And all the pending files have went through with no problem. Has anyone created a script that you can run that will run those commands and take care of the issue?

I have an On Prem setup and the Jss is 9.96 thanks in advance.

[maccentric]

@bjones I think that Jamf IT made a script along those lines https://github.com/jamfit/Reset-MDM

[ABigRock]

Anyone know if this is still an issue in 9.97?

[normanchan]

@ABigRock Just tested this and it is still an issue. I think it may be worse now actually.

I ran the sudo jamf removeMdmProfile and sudo jamf mdm -- resulted in the MDM profile not being re-installed. I am getting the generic 'Error installing the computer level mdm profile: profiles install for file: '/Library/Application Support/JAMF/tmp/mdm.mobileconfig' and user:'root' returned 500 (The operation couldn't be completed. (MDMResponseStatus error 500.))

I have this same error message now on 3 different machines.

[slewis59]

I had a lot of machines that were doing this and it was really tiresome when trying to push updates and configs and never knowing how many of them were actually going to the damn things.
then i found Casper Check it automated the entire process of checking a machine's connection to casper, and re enrolling if necessary to fix this issue. its literally saving me from pulling my hair out on a daily basis.

[normanchan]

@slewis59 I actually have a policy ready to go to install Casper Check. After reviewing the script, it seems to attempt to fix things by either reinstalling a quickadd package, or by running jamf mdm. I've tried both things on my affected machines however, and I still cannot get the MDM profile to get re-installed. Consequently, those machines do not have our configuration profiles installed.

Were you able to figure out how to get MDM working again? I can run recon, I can even run the custom trigger from Casper Check and JSS responds with "up".

[pwinfield]

The post by @denmoff worked for me (running 9.93)

sudo jamf removeMdmProfile
sudo jamf mdm

[nhubbard]

It's pretty maddening that 3 years later from the original thread of this post the problem still exists. No suggestion here helped me until I re-read rcorbin's post. I had to go into JSS and remove the mdm profile manually. Then recon the machine again. Reboot twice. Then it finally took hold. 3 hours later I finally have ONE machines pending apps all sent out. I have over 300+ machines...I can't do this for each and every one of them. Sigh.

[mnewman]

This is the response I got:
If you have iPads that have an app that is no longer available in the App Store you will be unable to deploy it to any other devices. If the app is currently installed on a device it should still be usable. All other iPads have the app go into pending commands. Deleting all pending commands didn't do it because it will continually try to install.
I had to go in and exclude the iPads that were getting the pending commands.
I don't know if this is the problem you are having but it solved mine.

[nhubbard]

These are managed apps that the state gives us so we have x amount of licenses, it's still showing I have plenty left available. Once I went through the process of removing the mdm profile, rebooting, reinstalling recon, rebooting and then rebooting again I noticed the pending apps disappeared on my server and they started installing on the users macbook. The problem comes in when I can't physically touch over 300 machines to make sure this happens. The interesting part is that I can see what apps, etc are pending for each user and there's no consistency to it. For example one user currently has a pending app for pages only (out of the whole suite), another user has ALL the mac app store apps pending that the state gives us. No rhyme or reason to it.

[Typhoon_87]

I have this issue as well on 9.98. It is disappointing that something so basic like I don't know the agent taking commands from the server can stop working. But self service and software installs keep working.

[CasperSally]

Just wanted to follow up that I am still seeing this and I am not sure anyone at Jamf is really working on it. I don't have a ticket opened on it, and I think it's somewhat expected when deleting local directories for users on computers at least.

I have a quarterly calendar reminder to delete pending/failed commands via mysql.

I ran the sql command to get a count of number of pending/failed commands recently and then ran "Cancel all pending and failed management commands" in the console expecting that count to go to 0. It didn't. It only cleared a small percentage of commands I believe (I ran the count sql command after).

I then ran the delete sql command and the count went down to 0. It seems to me "Cancel all pending and failed management commands" does not do the same thing as the sql commands. Jamf support wasn't sure why, I didn't spend the time to persue with them, but wanted to give everyone in the thread a heads up that the console 'cancel' may not do the clearing you'd like.

[nhubbard]

This script finally worked! I made a policy with it.... and sigh of relief, it worked. Hope it helps someone else.

!/bin/sh

jamf flushPolicyHistory
/bin/rm -rf /var/db/ConfigurationProfiles/

if [ -n /var/db/ConfigurationProfiles/ ]; then
/usr/local/jamf/bin/jamf mdm -userLevelMdm if [ -n /var/db/ConfigurationProfiles/ ]; then exit 0 else echo "Failed to enroll with MDM, after Profiles directory was deleted" exit 2 fi
else echo "Profiles directory not properly removed"
exit 1
fi

[nhubbard]

After speaking with the engineer again at Jamf (because the above script wasn't working 100% the way I wanted) he gave me a script that does just what I need and finally gets rid of those pesky pending commands.

[mschroder]

Hi,

I am very surprised about the "if [ -n /var/db/ConfigurationProfiles/ ]", that does not make much sense, as it just checks that the string '/var/db/ConfigurationProfiles/' has non-zero length. If it would be "if [ -d /var/db/ConfigurationProfiles/ ]" it would make much more sense.

Throwing out the whole directory also appears to be quite drastic...

[joshuaaclark]

Still an issue with 10.0.0-t1508873342. So Bump.

[KSchroeder]

It gets trickier if you have your MDM profile deployed via DEP, and have "Do not allow removal of profile" (err, however it is labeled; basically the restriction against removing the MDM profile). In that case it seems that you can't remove MDM, even with the Jamf command.

[mark_mahabir]

We're still on v9.98 and see this reasonably often. We plan to upgrade to 10.3.1 soon.

The solution given to us by our TAM is as follows:

1. Renew the APNS certificate
2. sudo jamf trustjss
3. sudo jamf manage
4. sudo jamf removeMDMProfile
5. sudo jamf mdm

[tcam]

Just as a FYI,

Last time I checked, if you have a DEP machine, and you

sudo jamf removeMDMProfile
sudo jamf mdm

The machine is no longer DEP enrolled. It's now self enrolled. Which means you can no longer use features that required DEP enrollment. Like remote whipe, remote lock, lost mode, extra.

if you want to re DEP
10.12 and bellow rm -Rf /private/var/db/ConfigurationProfiles/*

and then re-enroll by ether
/usr/libexec/mdmclient dep nag
and then clicking the popup to enroll
or rm /var/db/.AppleSetupDone
rebooting and re-go through setup assistant

For 10.3, and above, if SIP is enabled. /private/var/db/ConfigurationProfiles/ is protected. And you'll need to boot into recovery mode to clear out clear out /private/var/db/ConfigurationProfiles/ .

[jmahlman]

You know what's amazing..that this is almost 4 years old and still not resolved. We still see it on 10.4.1.

And what makes it better is if you're enrolling 10.13 machines with User-initiated enrollment it can take a long time to get the management framework installed because the "installapplication" command just waits and waits and waits.

[mark_mahabir]

This is still a problem for us running v10.7.1 on-prem.

When I contacted Jamf Support about this recently, they could only offer the advice mentioned in this thread.

[ryan_ball]

Jamf Pro 10.9 Release Notes - Bug Fixes and Enhancements

[PI-002379] Fixed an issue that caused MDM commands at the macOS user level to queue even after a user logs out of their computer.
[PI-002996] Fixed an issue that caused MDM commands to sit in a "Pending" status indefinitely if the computer was re-enrolled with Jamf Pro via a PreStage enrollment.

[tnielsen]

MDM Profiles really suck if you have computers that are not DEP eligible and some that are. Two completely separate paths need to be taken based on OS version and Enrollment type.

It's worth it to get this resolved, our company is simply building a list of users and asking users to approve the MDM profile (for those who forgot to do it during setup). If they don't do it, a physical visit is required. I have only 500 users, companies with thousands.... I feel bad for you.

[jameson]

Just stumbled over this post. I also often see Mac´s with these pending commands as I can see from other it is something that seems to be a general issue even in 10.9.
But is there a way to monitor Mac´s that have pending commands in one view(smart group ?), as checking manually each Mac is a full time job

[allanp81]

You could utilise the API and query each machine for pending commands, I do something similar for failed commands that runs through our ~800 macs and returns a list with failed commands.

[kerouak]

Here is a way to manuall purge all the pending command from the Database via MySQL

1) Make a manual backup of the server. 2) Stop tomcat 3) Run the following commands in a mysql shell: Use Jamfsotware; delete from mobile_device_management_commands where command IN ("DeviceInfoAccountHash","DeviceInfoITunesActive","ProfileList") and apns_result_status=""; 4) Exit mysql shell, restart tomcat.

[jameson]

What API should i look for about the pending commands - always the problem for me to find the right one

[allanp81]

computerhistory/id/$computername/subset/commands is what I search for per machine

[macmanmk]

I've been paying ever closer attention to these pending management commands as we've seen three machines over the last week "lose" their MDM profile and any other installed config profile. In all cases, there were pending management commands, presumably because the MDM profile was gone...or did whatever gum up the management commands also result in the MDM profile getting removed? No idea. Luckily I have been able to get the three users back up and running by SSH'ing to their machines and running sudo jamf mdm, but not knowing why it is happening is deeply unsettling. I'm worried 500 machines may lose their profiles overnight some evening and then we have chaos the following morning..

[allanp81]

I've always had machines randomly losing their MDM profiles for no obvious reason. It mostly seems to happen on machines with the most amount of unique users, such as in our open access rooms.

[vinu_thankachan]

I think some bug fixes are available in the version 10.9.0 http://docs.jamf.com/10.9.0/jamf-pro/release-notes/Bug_Fixes_and_Enhancements.html
[PI-002379] Fixed an issue that caused MDM commands at the macOS user level to queue even after a user logs out of their computer.
[PI-002996] Fixed an issue that caused MDM commands to sit in a "Pending" status indefinitely if the computer was re-enrolled with Jamf Pro via a PreStage enrollment.

[imagnone]

I have some Macs that got into this state because of an MDM error. The best writeup I've found so far of the issue is here:
http://rachelviniar.com/non-removable-mdm/

Sadly, the only way Jamf and Apple have given me to fix this is to wipe and reinstall macOS, something my users don't want to do obviously.

[abrahamT]

In my experience, the build up of MDM commands is related to renamed keychain issues. If there is a renamed or second 'login' keychain then the installation or removal of Configuration Profiles is affected.

The same applies to the System keychain. Any profile depends on the valid certificate from the JSS or your third party PKI which is stored in the System keychain. If the system can't see that certificate in your System keychain then the profiles stay in a pending state.

[swapple]

Is there a good script to fix this remotely? One with little interaction from the user??

[rblaas]

Ok this is an old topic but I still want to put in my 2ct as it may help in discovering the problem

I also had a client which was not responding to apns. After some investigation I found out that there was a mismatch in APN token. There was a different token on the client from the one I found in the JAMF database.

I used this command on the client to find the APN Token:
/System/Library/PrivateFrameworks/ApplePushService.framework/apsctl status Lots of output but search for "application port name: com.apple.aps.mdmclient.daemon.push.production"
below that section you will find: token: Yes, {length = 32, bytes=<xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxx xxxxxxxx>}

Compare this token with the one in the JAMF database. You can find the token in the database using mysql
mysql -u root -p
use <databasename>;
select computer_name, computer_id, apn_token from computers;

lookup your client id (or name) and verify the token.

If the token is not the same you have to re-enroll the device (jamf removeMdmProfile && jamf manage)

This solved my problem.