Currently Being ModeratedFeb 20, 2012 7:57 AM (in response to burton11234)
reverse and forward lookups - yes
I'm not using the DNS service.
The certs correspond (servers were having problems last week, so that part took forever).
And yeah, I followed everything you had posted step-by-step.
Currently Being ModeratedFeb 20, 2012 10:21 AM (in response to tmcmurtr)
the only variation I can see from your instructions is that my computer name has the short name listed. I would be concerned, but all my certs have the FQDN associated with them regardless...
Currently Being ModeratedFeb 20, 2012 10:36 AM (in response to tmcmurtr)
I have posted a few different places and everyone was able to get things working at some point or another.
When you re-created your OD master, with the FQDN did you revoke your apple push certs?
Did you remove all of your certs after destroying your OD Master?
I moved a mini I had to our lab, on a different domain and everything, just removed the certs after removing OD, and wiping devicemgr. No need to reformat... I didn't have any issues at all enrolling after everything was said and done.
There has to be some mismatch in what was done when you went through the instructions. Maybe there is an invalid cert that was left lying around before you re-created OD?
Currently Being ModeratedFeb 20, 2012 11:27 AM (in response to burton11234)
burton, thanks for your help. It took purging everything again, but it finally worked. Based on your experience, is there a need to open anything besides 2196 and 2195 if I don't plan on device enrollment occurring outside of my environment? All I want is remote wipe capabilities to occur on iOS devices and the ability to perform remote udpates/policy changes through profile manager.
Currently Being ModeratedFeb 20, 2012 11:38 AM (in response to tmcmurtr)
Your more then welcome!
Unless the networks are seperated by a firewall, you dont need to open any ports. If your network is seperated by a firewall you will need to open a few ports. Our mini in the dmz serves just iOS devices and these were the ports opened inorder enroll and push services. Obviously ping was enabled for verifying the device was up, and https was browsing the to the web page so you can enroll the device. The other 4 ports were for the process of enrolling to work and push services.
tcp - 2195
tcp - 1640
tcp - 2196
tcp - 5223
Currently Being ModeratedFeb 20, 2012 12:23 PM (in response to burton11234)
So more of a verification on my logic here ...
I'm assuming that all communication from Lion Server to the endpoint occurs via Apple Push Notification Services. Meaning that if I wanted to send a remote wipe to a device, I would need those ports open through my firewall in order for that to occur?
Currently Being ModeratedFeb 20, 2012 12:47 PM (in response to tmcmurtr)
Well lets start by not assuming anything :-) That word seems to always get me when I assume something, without verifying.
Unless your core is a firewall, or your server subnet / user subnet are inbetween a firewall, then you shouldn't need any firewall rules.
If you have devices in the wild and use 3g. ex iOS devices then you would want to create a public DNS record and that record would have to match up with your FQDN's that you had an issues with earlier, and open a few ports up. Im guessing 2195 and 2196 would do the job. Although I would have to test that out in order to confirm. I cant remember why I had to open 5223, I think I was having issues with policys pushing for some reason, and thats why I opened that port up.
We have a device in the DMZ that only does iOS devices, and our production x-serv does laptops / desktops.
Currently Being ModeratedFeb 20, 2012 12:59 PM (in response to burton11234)
Most of the documentation I've come across suggests 5223 was for wifi enrollment. But if that's what's carrying policy for wifi devices as well, I can see that being an issue.
Currently Being ModeratedFeb 20, 2012 1:05 PM (in response to tmcmurtr)
That would make sence!
As to where the mini resides in the DMZ users can hit it from the public as well as the internal network. Although both sides are locked down by firewall rules. Our x-serv doesn't have any firewall rules, but then again its internal only.
My guess is 2195, 2196 and 5223 should be acceptable for pushing, although to enroll you will need 1640 and 443.
Currently Being ModeratedFeb 20, 2012 1:22 PM (in response to burton11234)
Thanks burton, you've been very helpful!
Currently Being ModeratedFeb 20, 2012 2:02 PM (in response to tmcmurtr)
Your more then welcome!
Good luck with everything!
Currently Being ModeratedFeb 20, 2012 5:22 PM (in response to burton11234)
So what do I need to do to get this working? I've tried enabling root (logging in as root results in an security error on the enroll page).
changeip -checkhostname shows the same thing for both.
And yet I keep getting an error when enrolling Macs, iOS devices, and even the OS X Lion server itself. I get the same certficate error (with a '.bootstrap' added to the end of it).
Any ideas on what I could possibly do? I've been wrestling with this on and off for the last couple of months, and I'm really tired of it. This should not be this hard to get working.
Currently Being ModeratedFeb 21, 2012 5:37 AM (in response to AbMagFab)
You dont need to enable root to get this to work, you should only use the root account if you must. When you run changeip -checkhostname that is being run on the host itself which may do a proper lookup, but are you using the dns server on OSX and pointing the host to itself? If so that type of lookup should always work.
You want to verify the FQDN of the host from a machine that is on the user subnet this can be done in windows or OSX by running "nslookup hostname.company.com" and "nslookup x.x.x.x" They should both resolve to the OSX server that has profile manager running on it.
That FQDN on the user subnet should then match up to the push certs you obtained from apple, as well as the OD certs that were generated upon configuration of open directory.
My best advice would be to revoke everything by running the script to clear device manager, blow away OD, by making your server a standalone member / server. Remove all certs that were valid, adjust DNS to work properly from the user subnet, and start over.
In other peoples cases, they have done the process correctly, although there may have been a stale cert that was left behind and was not revoked properly. There should be no need to reformat in any way if you remove everything properly. This process is not that time comsuming and is faster then to reformat / redownload form the internet.
Currently Being ModeratedFeb 29, 2012 11:06 AM (in response to John B Portland)
I have a mac mini and having a tough time getting the profile manager setup the correct way. I think i need to start over and clean out what i have done so far. Whats the best way to do this? I have read thru the tread and and i have seen many different ways to do this. I just want to setup profile manager to help manage less than 60 iphones/ipads. So i would like to know whats the best way to clean up and start over?
Thanks for any information you can give me.
My setup is a Mac-mini lastest Lion server 10.7.3 (1.3.1)
Oh yeah i am new to the Mac world so a step by step would be great!