Pending Commands - iTunes, profiles

m_higgins
Contributor

Getting this on most of our machines, becoming a real pain. Anyone got any ideas?c24bacd85d4244879c82f569e734d81e

31 REPLIES 31

Chris_Hathaway
New Contributor II

I am having the same issue. I have been unable to push out ARD to the affected laptop as well. Hopefully someone has seen this and can point us in the direction of a fix.

Chris_Hathaway
New Contributor II

I resolved the issue by removing the MDM profile and then deleting the device from jamf. I then enrolled the device back into jamf and added back to the software push via self service install. The device didn't have the iTunes account info and and status pending issues any longer and was also able to install ARD via self service. Hope that helps somewhat.

jrippy
Contributor III

@m.higgins @Hathawayc You shouldn't have to remove the device from jamf.
As @Hathawayc mentions though, a quick way is to do jamf removemdmprofile. Then you can give it a few seconds and do jamf mdm. That should get all the mdm stuff back in order.
A word of warning though: if you are pushing out Wi-Fi or AD profiles, these will be removed with the first command and could render the computer off the network where you would need to go physically find it and work on it.

jmahlman
Valued Contributor

This is a known issue and I've been working with/in contact with JAMF engineers about trying to find a fix. It seems that it's an issue with shared machines like labs. I'm really hoping for a fix soon. In the interim we were given an SQL statement to run to clear our backup of commands:

DELETE FROM mobile_device_management_commands WHERE apns_result_status != 'Acknowledged' AND computer_user_pushtoken_id != -1 AND command IN ('DeviceInfoITunesActive','DeviceInfoAccountHash','ProfileList') AND date_sent_epoch < 90000000000000000;

Unfortunately the commands started backing up the next day again.

We have some issues running the jamf removeProfile and jamf mdm commands due to some certificate issue which we're also working on, but that set of commands SHOULD remove pending commands but as stated by @jrippy, be careful if you push wifi settings out with profiles.

jmahlman
Valued Contributor

If you're having this issue please contact jamf and mention PI-002379: "Computer User MDM Commands queued after user logs out".

bmchs
New Contributor

Is there a solution to this issue yet? It's been 6 months since this thread was started. I upgraded to JAMF Pro 9.101 yesterday and I'm still seeing the massive number of queue iTunes and Profilelist commands.

lynnp
New Contributor

We're also experiencing this issue while running 9.101. That sql query posted above doesn't work at this point due presumably to a db table change. There no longer appears to be a "computer_user_pushtoken_id" field in the "mobile_device_management_commands" table.

mysql> describe mobile_device_management_commands;
+-------------------------------------+--------------+------+-----+---------+----------------+
| Field                               | Type         | Null | Key | Default | Extra          |
+-------------------------------------+--------------+------+-----+---------+----------------+
| mobile_device_management_command_id | int(11)      | NO   | PRI | NULL    | auto_increment |
| device_id                           | int(11)      | NO   | MUL | -1      |                |
| command                             | varchar(255) | NO   |     |         |                |
| uuid                                | varchar(255) | NO   | MUL |         |                |
| profile_id                          | int(11)      | NO   |     | -1      |                |
| profile_udid                        | varchar(255) | NO   |     |         |                |
| date_sent_epoch                     | bigint(32)   | NO   |     | 0       |                |
| message_id                          | int(11)      | NO   | MUL | -1      |                |
| date_completed_epoch                | bigint(32)   | NO   |     | 0       |                |
| push_sent_epoch                     | bigint(32)   | NO   |     | 0       |                |
| date_received_epoch                 | bigint(32)   | NO   |     | 0       |                |
| date_read_epoch                     | bigint(32)   | NO   |     | 0       |                |
| command_valid_after_epoch           | bigint(32)   | NO   |     | 0       |                |
| apns_result_status                  | varchar(255) | NO   | MUL |         |                |
| inactive                            | tinyint(1)   | NO   |     | 0       |                |
| error_code                          | int(11)      | NO   |     | -1      |                |
| error_domain                        | varchar(63)  | NO   | MUL |         |                |
| error_localized_description         | longtext     | YES  |     | NULL    |                |
| error_english_description           | longtext     | YES  |     | NULL    |                |
| passcode                            | varchar(6)   | NO   |     |         |                |
| command_attributes                  | longtext     | YES  |     | NULL    |                |
| device_name                         | varchar(255) | NO   |     |         |                |
| device_object_id                    | int(11)      | NO   |     | -1      |                |
+-------------------------------------+--------------+------+-----+---------+----------------+
23 rows in set (0.38 sec)

Not sure if any of those correspond with that older field name, but wasn't really willing to clear anything out that would have caused problems.

Does anyone have a solid workaround until this gets fixed? Using DEP/VPP to reimage machines (as will be the only way going forward after APFS is mandatory) isn't really viable if we're waiting >= 45 minutes for commands to reach clients.

Over9000
New Contributor III

I am having this issue as well and the VPP software deployments rarely work. I'm not sure if they are related but VPP deployments are basically useless for us because the command stays pending like the iTunes Account Status and the others.

bmccune
Release Candidate Programs Tester

Any status on a fix for this? All of our lab machines at the school have multiple pending commands just like these. They are AD bound and students log in with AD accounts. It's been going on for years!

iTunes Account Status Pending Yesterday at 4:19 PM UserName Cancel
iTunes Account Info Pending Yesterday at 4:19 PM UserName Cancel
ProfileList Pending Yesterday at 4:19 PM UserName Cancel
iTunes Account Info Pending 02/02/2018 at 10:36 PM UserName Cancel
ProfileList Pending 02/02/2018 at 10:36 PM UserName Cancel
iTunes Account Status Pending 02/02/2018 at 10:36 PM UserName Cancel
iTunes Account Status Pending 10/26/2017 at 4:45 AM 01/19/2018 at 2:07 AM UserName Cancel
iTunes Account Info Pending 10/26/2017 at 4:45 AM 01/19/2018 at 2:07 AM UserName Cancel
ProfileList Pending 10/26/2017 at 4:45 AM 01/19/2018 at 2:07 AM UserName Cancel
iTunes Account Status Pending 10/24/2017 at 4:07 PM 01/19/2018 at 2:07 AM UserName Cancel
iTunes Account Info Pending 10/24/2017 at 4:07 PM 01/19/2018 at 2:07 AM UserName Cancel
ProfileList Pending 10/24/2017 at 4:07 PM 01/19/2018 at 2:07 AM UserName Cancel
iTunes Account Info Pending 10/04/2017 at 3:00 AM 01/19/2018 at 2:03 AM UserName Cancel
ProfileList Pending 10/04/2017 at 3:00 AM 01/19/2018 at 2:03 AM UserName Cancel
iTunes Account Status Pending 10/04/2017 at 3:00 AM 01/19/2018 at 2:03 AM UserName Cancel
ProfileList Pending 08/08/2017 at 5:37 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Info Pending 08/08/2017 at 5:37 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Status Pending 08/08/2017 at 5:37 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Info Pending 05/17/2017 at 11:02 PM 01/19/2018 at 2:10 AM UserName Cancel
iTunes Account Status Pending 05/17/2017 at 11:02 PM 01/19/2018 at 2:10 AM UserName Cancel
ProfileList Pending 05/17/2017 at 11:02 PM 01/19/2018 at 2:10 AM UserName Cancel
iTunes Account Status Pending 01/26/2017 at 10:50 PM 01/19/2018 at 2:10 AM UserName Cancel
iTunes Account Info Pending 01/26/2017 at 10:50 PM 01/19/2018 at 2:10 AM UserName Cancel
ProfileList Pending 01/26/2017 at 10:50 PM 01/19/2018 at 2:10 AM UserName Cancel
ProfileList Pending 12/08/2016 at 1:15 AM 01/19/2018 at 1:58 AM UserName Cancel
iTunes Account Info Pending 12/08/2016 at 1:15 AM 01/19/2018 at 1:58 AM UserName Cancel
iTunes Account Status Pending 12/08/2016 at 1:15 AM 01/19/2018 at 1:58 AM UserName Cancel
ProfileList Pending 12/02/2016 at 12:43 AM 01/19/2018 at 1:58 AM UserName Cancel
iTunes Account Info Pending 12/02/2016 at 12:43 AM 01/19/2018 at 1:58 AM UserName Cancel
iTunes Account Status Pending 12/02/2016 at 12:43 AM 01/19/2018 at 1:58 AM UserName Cancel
ProfileList Pending 05/19/2016 at 1:05 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Status Pending 05/19/2016 at 1:05 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Info Pending 05/19/2016 at 1:05 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Status Pending 05/18/2016 at 1:03 AM 01/19/2018 at 2:09 AM UserName Cancel
iTunes Account Info Pending 05/18/2016 at 1:03 AM 01/19/2018 at 2:09 AM UserName Cancel
ProfileList Pending 05/18/2016 at 1:03 AM 01/19/2018 at 2:09 AM UserName Cancel
ProfileList Pending 02/12/2016 at 1:19 AM 01/19/2018 at 2:04 AM UserName Cancel
iTunes Account Info Pending 02/12/2016 at 1:19 AM 01/19/2018 at 2:04 AM UserName Cancel
iTunes Account Status Pending 02/12/2016 at 1:19 AM 01/19/2018 at 2:04 AM UserName Cancel
iTunes Account Status Pending 09/29/2015 at 11:31 PM 01/19/2018 at 2:03 AM UserName Cancel
iTunes Account Info Pending 09/29/2015 at 11:31 PM 01/19/2018 at 2:03 AM UserName Cancel
ProfileList Pending 09/29/2015 at 11:31 PM 01/19/2018 at 2:03 AM UserName

jmahlman
Valued Contributor

A year later, and I'm still seeing this issue. Does't look like jamf is going to be doing anything about it.

This is a big problem when trying to use DEP (at least for us). It's taking 10-15 minutes for the enrollment complete trigger to get pinged because DEP commands are just backed up and waiting it seems.

As soon as I clear all failed and pending commands, DEP enrollment is down to 2-3 minutes.

:(

lynnp
New Contributor

uhh, bump? We just upgraded to 10.5.0 and are still experiencing this. No one has responded to my previous post on this from 7 months ago. We've just been dealing with this so far, but it's getting rather tiresome..

jrippy
Contributor III

@lynnp Yeah, we're on 10.4.1 and still seeing it.
Common response is either "it's something with your network/firewall etc." or "These just build up from time to time from random dropped packets. Nothing to worry about. Move along."

Personally, I, like I assume you, don't like those answers, but I've not found any information or way around them.
Whatcha gonna do? ¯_(ツ)_/¯

Howard_Trevor
Contributor

We've got about 700 iMacs at the moment and every single one I have checked has "profile list, iTunes account info and iTunes account status" pending commands. Some of the dates issued go back almost a year. Any word on this? Even if I manually clear the commands they start up again almost immediately.

bmccune
Release Candidate Programs Tester

Just bumping again since it still happens and no fix in sight...

szultzie
Contributor II

We are seeing the same issue, and if the answer was to just "move on" and no issue where caused by these pending commands I would be happy with the answer. But us as i assume most of you with the issue, are having other side effects, we are seeing that any new configuration profiles don't apply, old ones don't delete as well. So if i need to push a change with Jamf using a configuration profile im stuck and then start troubleshooting what went wrong when i come to this as the issue of it.

I had better results using ARD.

-Peter

dgreening
Valued Contributor II

Imagine what happens when you are at a 20k+ scale and are seeing this. Yeahhhh lots of excess CPU utilization. No word on when a fix will be in sight, but I have been having to babysit Jamf to prevent the various MDM PIs from bringing Jamf to its knees.

jmahlman
Valued Contributor

Hey jamf... ::poke::

jmahlman
Valued Contributor

::sigh:: It's still listed under known issues in 10.7.

lynnp
New Contributor

We've effectively been doing this on a cron job:

http://edtechchris.com/2018/03/04/clear-pending-failed-commands-jam/

For what it's worth, our conditional uses double quotes...

select count(*) from mobile_device_management_commands where apns_result_status !="Error";
delete from mobile_device_management_commands where apns_result_status !="Error";

select count(*) from mobile_device_management_commands where apns_result_status !="Acknowledged";
 delete from mobile_device_management_commands where apns_result_status !="Acknowledged";

lynnp
New Contributor

The selects just give you an idea of how much cruft you're clearing out :P

mysql> select count(*) from mobile_device_management_commands where apns_result_status !="Error";
+----------+
| count(*) |
+----------+
|    12602 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from mobile_device_management_commands where apns_result_status !="Acknowledged";
+----------+
| count(*) |
+----------+
|     2294 |
+----------+
1 row in set (0.01 sec)

mark_mahabir
Valued Contributor

I see this issue occasionally; we're currently using v10.3.0 and planning an upgrade to v10.7.1 later this month. We don't yet use DEP/VPP.

We recently moved to a third-party Tomcat SSL certificate, so what worked for me today on a client was:

sudo jamf trustjss
[Cancel all pending commands in the web interface]
sudo jamf removeMDMProfile
sudo jamf mdm

kerouak
Valued Contributor

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.

dgreening
Valued Contributor II

@kerouak Jamf gave me this command to run via scheduled task. They confirmed that I can run this on live Jamf and do not have to shut down Tomcat.

delete from mobile_device_management_commands where command IN ("DeviceInfoAccountHash","DeviceInfoITunesActive","ProfileList") and apns_result_status="" and device_object_id=12;

mark_mahabir
Valued Contributor

@dgreening Can you confirm that the 'device_object_id' is the same as a Jamf Pro Computer ID, and the argument is changeable, depending on what device you want to remove the pending management commands from?

I'm by no means a MySQL expert....

dgreening
Valued Contributor II

From what Jamf told me, "device_object_id=12" pertains to user level configuration profiles. I have since de-scoped our on user level profile in favor of a system level. It is slowly being clawed back.

jmahlman
Valued Contributor

According to Jamf's release notes, this has been resolved in 10.9.

[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.

bradtchapman
Valued Contributor II

So apparently this has been happening to us for a while, and it wasn't automatically resolved in 10.9. This issue has been carried forward all the way to 10.26.1 and our only recourse is to reënroll the Macs.

This query shows the number of commands sent to the computer_id in a 24 hour period. Do I win a prize?

select mdmc.device_id as pushtokenID, mdmc.command, cupt.computer_id, count() from mobile_device_management_commands mdmc left join computer_user_pushtokens cupt on mdmc.device_id=cupt.computer_user_pushtoken_id where mdmc.device_object_id=12 and mdmc.date_completed_epoch>unix_timestamp(date_sub(now(), interval 24 hour))1000 group by 1,2 order by 4 desc limit 1000;

pushtokenID command computer_id count(*)
1916    RemoveProfile   9206    32872
12700   RemoveProfile   10964   32790
4692    RemoveProfile   7656    31108
6837    RemoveProfile   12511   26745
7076    RemoveProfile   12594   17327
9249    RemoveProfile   13303   17045
14596   RemoveProfile   15427   17017
21032   RemoveProfile   18841   16513
14817   RemoveProfile   9809    15880
16514   RemoveProfile   16308   15775
514 RemoveProfile   5263    14712
1293    RemoveProfile   7534    14152
1319    RemoveProfile   7735    14079
14911   RemoveProfile   6126    13287
2723    RemoveProfile   10424   12763
4587    RemoveProfile   11619   12208
3749    RemoveProfile   6638    12207
16234   RemoveProfile   15802   12118
7135    RemoveProfile   12599   11740
16243   RemoveProfile   8789    11280
17188   RemoveProfile   16410   11156
15235   RemoveProfile   5095    11088
1410    RemoveProfile   7943    11082
6102    RemoveProfile   12120   10956
20863   RemoveProfile   18781   10671
318 RemoveProfile   5261    10531
13676   RemoveProfile   5046    10520
17171   RemoveProfile   5073    10211
1854    RemoveProfile   8978    10090
6455    RemoveProfile   5080    10006

I know Jamf advertises that the "Renew MDM Profile" command from the computer management dashboard is not supposed to fix anything, but in this case, it fixes this issue for me. This has been bugging me especially because it happens on newly pre-staged enrollment machines and is not a legacy issue per se.

I tried a few things first, so I do not know if this is a singular fix, but according to a sample of 1, it worked.

I'll update this if it is a singular fix on my next pre-staged enrollment.

wifichallenges
Contributor II

Thanks this worked for me. I dont have an SQL server because its jamf cloud, but simply renewing the profile and cancelling the commands worked. had about 10 macs with this problem stuck since 2019

 

2022-05-26 13_23_31-D__.png

 

 

dtrockman
New Contributor III

I have been told to never use "renew profile". I had not heard the justification. But, there it is!

This issue has bugged me for a long while. I am not sure if it still going on or if I just don't see it anymore. I am also on Jamfcloud.

Any comments on the danger of using that command?

wifichallenges
Contributor II

worked for me.