Configuration Profiles

[awjohnso]

Greetings,

I'm still in my evaluation process with Casper, and I have the latest version as far as I 8.52. I have about 7 or so computers in my JSS 8.5.2, with a mix of 10.7 and 10.6.

My issue seems to be with Configuration Profiles for 10.7.x. In all honesty I am not happy Apple has moved away from MCX, since I had it running very well for the past 6+ years. I'm finding that the Profiles approach feels like taking 10 steps back. With the advent of Mountain Lion, I am forced to move away from MCX even though they still work on 10.7.

Anyway, I setup a Profile in my JSS, and when I try to setup the scope, I can't add individual computers except for one out of the 7 or so. Now I can understand that the 10.6 clients would not show up, but 10.7 should be fair game. If I add a group in which some of those 10.7 clients belong to, the profile doesn't get pushed down to those computers.

I can only seem to install it on the one computer which shows up under the scope.

The documentation is vague, and searching the discussions hasn't led me to any kind of solution.

Any suggestions?

Thanks,

-Andrew

-----------------------------------------------------

Andrew W. Johnson
Senior Macintosh Systems Administrator
Department of Teaching Learning + Technology
Division of Information Technology
Stony Brook University
S-1464 Frank Melville Jr. Memorial Library
Stony Brook, NY 11794-3350
Tel: (631) 632-1824
Fax: (631) 632-1373

[tomt]

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.

[awjohnso]

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

[awjohnso]

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

[tomt]

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

[awjohnso]

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

-Andrew

[justinworkman]

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

[tomt]

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.

[bentoms]

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.

[tomt]

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.

[bentoms]

@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

[tomt]

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

[Kumarasinghe]

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