Time frames of Pending Commands

[ctarbox]

iOS 11, JSS 99.101

In the past, with iOS 9.3.5 or IOS 10.x, when pushing Configuration Profiles or other Management commands to iOS devices they pushed out pretty quickly -- within a minute or two.

Now I am seeing that any change I make to a Configuration Profile or other commads initiated via the JSS can take up to 15 minutes or longer.

Has anyone else noticed these delays? Trying to figure out if its the newly released iOS or maybe a network issue on my end.

Cheryl Tarbox
Binghamton University

[thejenbot]

are you seeing any errors in your logs? or anything that might help explain the delays?

[ctarbox]

The Events Logs are only showing started and completed. I'm fairly new to managing the iOS devices. Where would other logs be located that may be relevant?

[kwsenger]

@ctarbox We are seeing the same thing. Our commands push through in a consistent 9 minutes. Config profiles changes almost happened in an instant before. We have a case open with Jamf support.

[miregan]

My changes to config profiles are pretty much instant

[jmahlman]

I'm seeing this on iOS and MacOS; about 15 minutes it seems.

[AVmcclint]

Have you had any changes to your network infrastructure? Proxies, firewalls, and any other network security tools will absolutely get in the way of APNS working in a timely manner.

[ctarbox]

Thanks, all for the replies.

It's interesting to note, that is isn't just me that is seeing this lag.

@AVmcclint We are always in constant change and upgrades to our network. I will speak with the Network Admins and see what changes have been made since June (when was the last time I was working heavily with iOS and JAMF implementations).

Cheryl

[thejenbot]

@ctarbox , to answer your earlier question - if you add /logging.html to the end of your JSS URL you can see the logs, it may help see what's going on in the background. It shows general info and warnings that aren't really that big of a deal, but I always keep an eye out for Errors and if I see them persistently. I pop in there every once in awhile to check for problems after an issue we had that we were able to track back to a problem in the database. Problems that weren't addressed ended up snowballing and causing bigger errors and eventually Apple started throttling our ability to communicate with their servers. When I notice the JSS loading poorly or commands taking awhile to go through I take a look in there; don't know if that will help you out in any way but it won't hurt :)

[ctarbox]

@jnelson64. Thank you for this info. I have had JAMF Support point me to this URL in the past, but never put the two together.

[ctarbox]

After perusing the logs for today, I see very few errors. One is a communication error at a specific IP that would be part of our wired network.

This one shows up twice with the exact same time stamp. No continuous occurrences of it, and it does not coincide with any times that I pushed out Configuration Profile updates to the iOS device I am testing with.

2017-10-17 11:15:54,511 [ERROR] [duledPool-7] [PatchSecurity ] - Error processing CRL data from certificate information
java.lang.NullPointerException at org.apache.http.client.utils.URLEncodedUtils.format(URLEncodedUtils.java:389) at org.apache.http.client.utils.URLEncodedUtils.format(URLEncodedUtils.java:369) at org.apache.http.client.utils.URIBuilder.encodeUrlForm(URIBuilder.java:195) at org.apache.http.client.utils.URIBuilder.buildString(URIBuilder.java:157) at org.apache.http.client.utils.URIBuilder.build(URIBuilder.java:120) at com.jamfsoftware.jss.services.ManagedServiceConnection.buildFinalUri(ManagedServiceConnection.java:148) at com.jamfsoftware.jss.services.ManagedServiceConnection.doGet(ManagedServiceConnection.java:90) at com.jamfsoftware.jss.patch.security.PatchSecurityDownload.uriDownloadThroughProxy(PatchSecurityDownload.java:33) at com.jamfsoftware.jss.patch.security.PatchSecurity.getCRLFromURI(PatchSecurity.java:209) at com.jamfsoftware.jss.patch.security.PatchSecurity.getCRLSFromCertPath(PatchSecurity.java:158) at com.jamfsoftware.jss.patch.security.PatchSecurity.checkForTrustedCert(PatchSecurity.java:98) at com.jamfsoftware.jss.patch.PatchNationService.performSecurity(PatchNationService.java:211) at com.jamfsoftware.jss.patch.PatchNationService.getFullSoftwareDetails(PatchNationService.java:170) at com.jamfsoftware.jss.patch.SoftwareTitleMonitor.handleSoftwareUpdate(SoftwareTitleMonitor.java:97) at com.jamfsoftware.jss.patch.SoftwareTitleMonitor.runMonitor(SoftwareTitleMonitor.java:91) at com.jamfsoftware.jss.patch.SoftwareTitleMonitor.run(SoftwareTitleMonitor.java:59) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)

[thejenbot]

this part:

2017-10-17 11:15:54,511 [ERROR] [duledPool-7] [PatchSecurity ] - Error processing CRL data from certificate information

doesn't have anything to do with the rest of it; everything after java.lang.NullPointerException is similar to what i see in my logs on a daily basis, nothing to worry about, just info. the good news is that there isn't a 96xx number in the error information, because that means that apple is not happy with you and you have something to fix.

CRL is certificate revocation list. that doesn't help me in any way and i don't know if it helps you, but at least you have a jumping off point.

if you continue to see slowness and this error keeps popping up it may explain it, but it may not. i don't see anything on JN about that error, so you may need to reach out to support in order to dig deeper - they may have you go into debug mode to get more detailed info.

curious to see how this turns out for you. i'm such a nerd... :)

good luck!

[ctarbox]

Thanks again for the info. Glad to know I'm not making Apple unhappy. :-) I will open a ticket and send the error message to support and see what they come up with. I will post any replies or info I receive from them here.

[jmahlman]

Thanks for the tip on the logging.html. When I look through the logs I see this (with different computers and IDs) warning a lot:

2017-10-18 09:47:32,981 [WARN ] [duledPool-2] [pleMDMCheckInNotification] - Unable to create push notification for device: UserPushToken [ID=66079, Name=sbecht]. A required field (UDID, APN Token, Push Magic) was empty.

This might have something to do with a previous ticket we had open where management commands would build up on our systems due to multiple users using our lab machines.

[ctarbox]

@thejenbot ] I did open a support ticket regarding this. We first confirmed that my JSS setup was in good shape by looking at logs, and running some monitoring scripts against the JSS. Then with the help of a very knowledgeable Support Technician, we ran some queries against the MySQL database and found two things:

1. There were over 19,000 pending command built up for some unknown reason.
2. There were duplicate local users registered for eleven different devices (I do believe these were all MacOS Desktops, not iOS devices).

Both of these were described as anomalies. Once we cleaned both of these up -- with queries he readily supplied to me -- my JSS was once again pushing commands in a very timely manner.

If anyone is having this issue, I highly recommend opening a support ticket. Not only are my commands pushing as they should, it was confirmed the JSS was in a good functioning state, which gives me more confidence for a successful upgrade to JAMF Pro 10 when the time comes.

Cheryl