Hopefully you had time to review my last article on how Apple’s Push Notification System (APNS) works when managing OS X and iOS devices. It’s not required reading to comprehend, but it does provide an an overview on how complicated APNS is AND the beauty in its architecture to make everything happen in an instant! What I now want to discuss is not when APNS works, but when it doesn’t “What are the common things I check when APNS is not working”. Most of these debuging steps are for the initial setup of your APNS environment, if this were working “fine” but now nothing works… there may be something else at hand.
Network APNS issues
First and foremost, when APNS doesn’t work I’m blaming your network. Are you allowing the proper ports out of your environment; specifically ports 2195, 2196, and 5223? You can do some testing for 2195 and 2196 be trying using the ’nc’ command
feedback.push.apple.com over port 2195 and 2196 respectively, and this needs to happen FROM your MDM (JSS specifically regarding the Casper Suite). Below are successfully examples using the nc command:
1 2 3 4
The second item is your devices connecting to APNS network over 5223. This is the network element that would allow your devices (OS X or iOS), to talk to Apple.
When running these test be sure to perform them their perspective network segments. Most networks are NOT flat except inside your house/home. Server networks may have tighter requirements than WiFi networks for your iPads. Remember, all three of these sessions are being established from the inside to the outside world. Most firewalls are setup to allow this type of network communication as most people are worried about people getting in, not going out of the network environment. Lastly, if your network administrator starts thinking WE HAVE A GIANT DOOR FOR THINGS TO GO OUT ON THREE PORTS! OMG!, request that these ports are only valid for the 17.x.x.x Class A network. Apple owns the whole class A block.
It goes without saying that DNS needs to work from the Server and your clients. I have been in some situations where the ONLY DNS available in the server room is for the internal domain, this way virus cannot find the “command central” and spread their diseased infested “ones and zeros” throughout the servers (this is a lie, but whatever). With no DNS, PUSH commands will never be sent. May need to move your MDM to a DMZ.
Along with DNS, there may be certificate issues. With Certificates you MUST use the Fully Qualified Domain Name (FQDN). Sorry… I know “server1” is much easier than “server1.domain.tld”, but that doesn’t work when you need certificates to validate. USE the FQDN. In fact, ALWAYS use FQDN in any setting on the JSS with the exception for NetBoot server, and that is a requirement because the bless command is looking for an IP address.
Lastly I want to bring up a strange issue that I discovered some time ago when testing OS X 10.8 and the Casper Suite by creating multiple Virtual Machines with VM Ware Fusion. I hope this was an issue because I created 10 VMs on my MacBook Pro Retina, Mid 2012 and started enrolling them into my test JSS. With the help of JAMF Support we discovered at some point my VM’s were not getting a token from Apple. The way I found this was by searching inside the MySQL database. 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
You can see there are two computers that I enrolled into my JSS, however, they never received an APNS token. The end result is these computers will never receive any PUSH commands because Apple has no way of finding the devices. My initial clue that something was wrong was after the two computers were successfully enrolled, I looked for them to assign a Configuration Profile. They were missing in the “Individual Computers” list. It must be a MySQL command that requires the apn_token be return in order to populate the list.
No these are not my real APNS tokens! You think I would publish that… on the INTERNET!? Randomly generated by [rand] ↩