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.

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.

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

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.

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

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.

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.

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.

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

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.

:(

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

@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? ¯_(ツ)_/¯

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.

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

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

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.

Hey jamf... ::poke::

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

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";

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)

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

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.

@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;

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

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.