jamf command to force a APNS push??

The jamf mdm command was removed in version 9, in case that's what you're using.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1388

I'm not sure if there's a way to do it other than through that now deprecated command, but maybe.

Any time a push hasn't worked for me it has turned out to be a certificate problem. Go to Computers > Global Management > Push Certificates > MDM Push Notification Certificate

Has the certificate expired? If you renew the certificate, does it fix your problem?

The Cert is Valid and I am getting the CPs, just not immediately. It seems to be an "interval" when the device does a check-in with the APNS network. I just wish I could force this. Unfortunately, the way my envionment is setup the client has to initiate the request to APNS (which contrary to what some say here, it does), and receive the go ahead form APNS to check the MDM server.

A few things to keep in mind about APNS:
1. APNS has two "priorities" for notifications. Security-related priorities such as locking a device or erasing it are higher and should be near immediate or within a minute or two. Lower priority requests, such as taking inventory, may take up to 20 minutes.
1. If a device is offline, APNS will hold the request until the device comes online again, but only for a limited time.
1. If a device is offline, APNS will only hold one recent request for when the device comes online again.
1. In addition to port 2195 for the JSS to communicate with APNS, you want port 2196 open for APNS to respond to the JSS. This doesn't make push notifications work any better but it does give you feedback in the JSS when the APNS has responded.

Quite often we'll see lower priority requests nearly immediately, however, that just indicates Apple's notification system is processing requests in near real-time.

This may be redundant & I apologize if so but the JSS can send a Blank Push to APNS. Go to an individual device record (e.g. for an iOS device or Mac that is in the scope of your Configuration Profile) select the Management tab & click on the Blank Push button. It does not "force" the APNS service to act but it does "poke" it to repeat the pending action. If the initial communication failed for some reason the Blank Push should send the command again. Also as mentioned above, port 2196 is not absolutely necessary for APNS to work, but, that is the port on which feedback is returned from APNS to inform the JSS of activity status.

yeah blank push works fine..... its just in a case where I need to force when I dont have access to JSS immediately.

We've been having problems too, just last week a machine had been on the network for hours an no config profiles came down, no blank pushes seem to go through. The networking group claims the ports on the switches are open...

Prior to these recent issues, the longest we ever had to wait was maybe 5minutes...

(our cert is set to expire in 2015)

Anyone get anywhere with this? I have an issue with only some machines (mine for example) other peoples laptops are getting the push's not me though, MDM enrolled etc, re-enrolled, run manage....bit stumped

I'd like to see blank push available in the API so an endpoint can request it when required - ie during a network state change.

This is one of the major failings with JAMF. Unlike Profile Manager that does an immediate push of settings changes, JAMF does not. You have to wait until the device checks in, which doesn't seem reliable, so settings can take up to an hour to actually take effect. It also means that you can't actually push critical actions which seriously cripples the software, and in some cases renders functions useless. Why they require a push cert when it's never used I don't know, other than Apple may require it even if the push isn't happening. The fact that the premier solution lacks basic functionality, and has not been fixed in the last 5 years, is really unforgivable. I maintain that JAMF owes customers a lot of refunds because the products doesn't even come close to living up to the price tag.

@ebonweaver, Jamf sends APNs commands immediately. It doesn't rely on devices to check in to send them. And if the environment is clustered, the push command comes directly from the server where the setting was last saved. If that server doesn't have access to gateway.push.apple com on 2195, then the command gets queued to be pushed by the Master Jamf Pro server, which may take up to five minutes to try again.

Only configuration profiles, MDM commands and VPP app installs use APNs.

Policies and Restricted Software will rely on check-in. Those aren't APNs-related technologies.

Sorry but that's not the case. Profiles, name changes, etc all take almost 30 min to apply on Mac and iOS. They just sit pending until the device checkin period comes around.

iOS devices don't check in. They update inventory at minimum once per day. APNS is not based on device check-in at all. APNS is much more immediate but if commands are being sent out to several thousand devices at once it might take some minutes to propagate to all devices.

Regardless of MacOS or iOS, number of devices in scope, time of day, etc, it ALWAYS takes 23-26 minutes for changes to be sent to devices. It's like clockwork really. Sometimes a checkin seems to be missed, so you're up at 45ish minutes. It is NEVER any faster. App assignments on iOS usually take about 1-3 minutes, so those seem to be sent by push. Everything else seems to be by a check in schedule. I have in fact watched as app installs occur, and the management action sent before the app assignment has to wait another 15 minutes until we get to the scheduled "checkin" as those sit pending. You can say they don't check in, but that's the behavior.

Can you give an example? Is this a policy you’re doing or a configuration profile? Because those are 2 very different things.

As you mentioned App assignment is via APNS. Apps assigned through the Mac App Store are via APNS.

In regards to @wmateo question - I have had better luck with MacOS VPP app installation when I scope to a Smart Group, rather than individual devices. There is no speeding the app installation up though through manual methods, but if you have not tried to scope to a group, try that.

@ebonweaver We had this issue a few times in the past year, once when we upgraded to Casper 9.100.0 and once when we upgraded to Jamf Pro 10.3.1.

In each case DEP, Config Profiles, MDM commands and VPP apps all took about 30 minutes to push. For each case we contacted Jamf Support who worked with us to get the issue fixed and performance back to the point where this all went back to happening fairly instantaneously (or at the worst a few minutes).

When we upgraded from Casper 9.93 to Casper 9.100.0 Jamf Support had us change some of our Tomcat and MySQL settings to fix it. When we ugpraded from Casper 9.100.0 to Jamf Pro 10.3.1 they discovered it was due to a performance related Product Issue that occurs when you have all of your Mobile Device Apps set to Automatically Update. I was very skeptical when they wanted me to run a MySQL command to disable Automatic Updates for all Mobile Device Apps (we have hundreds of mobile device apps due to fact that we have about 50 Sites that each manage their own), but in the end it atcually fixed it for us.

I would recommend contacting Jamf Support so they can look at your specific situation.

@spalmer thanks for that info, it's the first useful response related to this that addresses a problem that JAMF has previously indicated was normal. We'll take this info back to support as reference that something needs to be fixed. We have never seen the system work instantly, this has been a headache from day one. JAMF indicated it's all check in driven instead of push driven. Many other users have had the same complaint. Hearing actual info that this is a common problem they seem to have and can in fact correct is encouraging. It's a shame they have not addressed this in the product given it creates an ambiguous support problem that their own people don't seem to understand that plagues many customers.

@ebonweaver The PI issue that was causing our APNS slowness after upgrading to 10.3.1 is still listed as a Known Issue in 10.6.0 (which we haven't upgraded to yet since we are waiting on 10.7 for macOS Mojave support).

[PI-005048] When the Automatically update app checkbox is selected for a large quantity of apps installed on a large quantity of devices, the quantity of InstallApplication commands may cause Jamf Pro performance issues.

If this is your problem as well, hopefully reporting it to Jamf Support it will help move that issue up a notch or two in priority.

I think it is incorrect for Jamf Support to say this is a check-in process, but I think there may be a reason that it seems this way. Before our APNS slowness was fixed after our upgrade to Jamf Pro 10.3.1 I did a few tests where I sent out a Config Profile and then proceeded to wait for 30 minutes since that was our usual time to wait for APNS actions to complete. After about 15 or 20 minutes I decided to assign several other config profiles, VPP apps and MDM commands. However, what was interesting is that ALL of those actions occurred at exactly the same time as the initial config profile that I first sent out.

My theory is that what is happening is that when Jamf Pro has performance issues that prevent push notifications (for Config Profiles, MDM commands, VPP app installs, etc.) from going out immediately they start to queue up and Jamf Pro starts sending them in intervals. So while it seems like a check-in process because it happens in consistent intervals it is still an actual push that is just getting queued up for performance reasons.