Configuration Profiles

Are you by chance behind a web proxy? I was running into the same issue and finally figured out (with help from JAMF support) that the Lion machines need to communicate with Apple once after receiving the profile in order to enable management. In my case, I just have to put each machine on an outside line for a couple of minutes after I image it and then it will appear in the scope.

P.S.: I also find that many settings in my Profiles don't stick. If I go back and look at them, many settings are back to be not set. Anyone else see that issue?

-Andrew

We are indeed behind a web proxy. In my test environment I would say that's fine, if I roll this out to 300 computers I don't have the time to move each machine out from behind the proxy just to get them enrolled.

Apple told us some time ago that we should allow students to use iCloud, and I asked if it worked behind a proxy and the Apple Engineer told us no. So I would not be surprised if it's the Proxy the problem. I'll test it right now, but if it is, it's going to be a serious issue for us...

-Andrew

I used Little Snitch to try and figure out where the machines were going when they contacted Apple. I was hoping to have our network guys whitelist the address.

This is what I found:

"Connection report for process: applepushserviced (/System/Library/PrivateFrameworks/ApplePushService.framework/applepushserviced)
Total: 10.4kB sent, 18.1kB received 4-courier.push.apple.com (17.172.232.129), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received 44-courier.push.apple.com (17.172.232.208), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received 24-courier.push.apple.com (17.172.232.202), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received 14-courier.push.apple.com (17.172.232.81), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received albert.apple.com (17.171.27.65), Port 443 (https), Protocol 6 (TCP), 294 Bytes sent, 2.2kB received albert.apple.com (17.149.240.65), Port 443 (https), Protocol 6 (TCP), 7.9kB sent, 13.2kB received 35-courier.push.apple.com (17.172.232.154), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received 5-courier.push.apple.com (17.172.232.72), Port 443 (https), Protocol 6 (TCP), 154 Bytes sent, 0 Bytes received 14-courier.push.apple.com (17.149.36.128), Port 5223 (unnamed), Protocol 6 (TCP), 1.4kB sent, 2.7kB received"

It appears that they are connecting to #-courier.push.apple.com where # is a variable. I'd guess they do that to load balance the traffic. Our proxy (Bluecoat) doesn't seem to be able to use any type of wildcard character in the whitelisting. We are changing over to Symantec this summer so I am hoping it can be done on that system.

Hopefully this helps you somewhat.

Tom

Actually our Server is not behind a proxy, since I could not get GSX, and communication with JAMF to work with TomCat.

-Andrew

Just FYI, Apple owns the entire 17.x.x.x class A network. If you can whitelist that, you should be golden.

It's not a server issue, it's that each client needs to contact Apple to receive an APNS Token before it will allow itself to be managed.

Do the clients have the MDM profile, just no other profiles?

The below is from my change request, not sure if it helps.

Network requirements 5. Firewall b. Outgoing port 2196 from JSS-01 to 17.0.0.0/8. i. Outgoing ports 80, 443, 2195 & 5223 from all to 17.0.0.0/8.

Just FYI, Apple owns the entire 17.x.x.x class A network. If you can whitelist that, you should be golden.

Hi Justin,

I can't speak for Andrew but at my company they block access to iTunes and some other Apple sites. I could not get my guys to go for that when I tried. I wish it was that easy for me.

@Tom, i had to battle.. but all the documentation i could get from Apple Dev, JAMF & our MDM provider (AirWatch) said to whitelist the whole of 17.x.x.x

@Ben Thanks for that bit of your change request. I requested that those ports be opened just from our IT subnet where the imaging will be done. Hopefully that will work as an acceptable compromise.

For the users behind Proxy/Firewall;

17.0.0.0/8 range is huge and we are still trying to get this range exempted from our IT Security and Networking departments. In the mean time we have narrowed it down to smaller network ranges but Apple's recommendation is to use the 17.0.0.0/8 range as all the hostnames are load balanced and can change the IP addresses anytime.

We have gone through a long diagnose phase and these the findings;

1. First of all you have to allow albert.apple.com over TCP 443 (HTTPS) get the OS X device activated before you do anything with APNs.
This is an automated process and all you need to do is allowing outbound traffic from client machines to albert.apple.com over TCP 443.

e.g- 17.149.0.0/16 17.171.0.0/16

With 10.7.4 update we have seen some OCSP certificate validation issues. So you have to exempt ocsp.entrust.net (over HTTP) maybe some other ocsp addresses in your firewall to get alber.apple.com site certification validated. Otherwise you'll get "invalid certificate chain" issues and will not get the device activated.

2. Then you have to allow x.push.apple.com over TCP 443 and 5223. It seems like the IP range used by x.push.apple.com may be different to the Country/region you have your clients. We have 17.149.0.0/16 for x.push.apple.com range (Australia/Melbourne) and @tomt has got 17.172.0.0/16

We have an authenticated internet (Cisco SCE) system and as for the HTTPS requests we have to use IP addresses instead of hostnames because HTTPS requests are encrypted.

Ideal solution would be to open 17.0.0.0/8 via TCP 443 and 5223