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.
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
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.
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...
Still an issue with 10.0.0-t1508873342. So Bump.
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.
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:
- Renew the APNS certificate
- sudo jamf trustjss
- sudo jamf manage
- sudo jamf removeMDMProfile
- sudo jamf mdm
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/ .
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.
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.
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.
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.
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
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.
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.
What API should i look for about the pending commands - always the problem for me to find the right one
computerhistory/id/$computername/subset/commands is what I search for per machine
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..
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.
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.
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.
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.
Is there a good script to fix this remotely? One with little interaction from the user??
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.
