Thanks for the quick responce DOLAdmin.
But look on Page 3 of the forum, and 5th post from the bottom of the page.
But there was also a few things that "DOLAdmin" found that were not exactly word by word from what I listed and he referenced those in another reply, they are on page 4 (4th post down from the top).
I would try going through these phases, since the exact process was listed already. I dont have any issues helping if needed, although most of the answers should already be in the thread :-)
If your looking on solutions on the Magic Triangle I have a sandbox PDF that may help with that one as well.
Ok i did the reset and got the big green look good check. I can reach the profile server now from the internet!
But here is what is happening now when i try to enroll a iphone 4 this error comes up https://server.apps.net/devicemanagament/api/device/ota_service is invalid.
Internet or Intranet?
The reason your iphone is coming up with that error is because of a FQDN issue with what the certs.
Can you do a forward / reverse lookup of the address on your local LAN? If so try to register with the FQDN on your ios device.
Did you setup apple push certs? If so, they need to be matched up for the FQDN and your forwrad / reverse lookup on your LAN, as well as the OD certs need to be in the same uniform.
If your server is called server.apps.net which it looks like thats what its called from your last post. You shoudl be able to do an nslookup server.apps.net on your LAN and resolve the IP, you should also be able to do a nslookup IP address, and it should resolve the hostname. If not please make sure that your forward / reverse lookup zones are correct.
After that is said and done, I would verify that the OD FQDN was created for server.apps.net and make sure your apple push certs say they were from server.apps.net.
Once everything alligns and you can reach the host server.apps.net from the public internet, you then should be able to enroll.
The reason why its failing is that an OSX system can use the shortname since they can trust the cert, although iOS devices need to be enrolled by the FQDN since there is no cert management done from the iOS device. If not everything matches, there is no enrolling....
I've read everything in this thread and a bunch of other things on the web. At this point, profile manager it's an Intranet only install. It's a AD/OD Master install as well. Our intranet does not block ports and the mac server has the firewall off. When I reinstalled the OS from scratch during the "configure" stage it automatically creates the certs and I received an email.
As far as I can tell all certs are registered with the correct FQDN. I'm also using https://myserver.mydomain.com/mydevices to enroll these. But I still recieve the error "ota_service is invalid". I have the forward / reverse lookups working correctly. I'm connecting the ios device (ipad) to a wireless ap connected inside the intranet. I'm getting the correct dns servers on the ipad as well. A MBP is able to enroll just fine.
I can't seem to find the problem still. Any other ideas?
Also you said you have a PDF of a golden triangle. Can you post that somewhere I can download it?
Thanks for all the troubleshooting you've done this far for others.
From what you say, thats good you can enroll a MBP. Although the difference between an iOS device and OSX device is how they manage certs. iOS doesn't have a cert manager, and it handles certs differently.
If you are using a self signed cert on the server, you will need to donwload the trust profile on the iOS devices, after you install the trust profile you should be able to enroll. If your still having issues then there is some sort of mismatch on whats being used for the FQDN.
Just for clarification, when you signed up for the apple push certs, do they have the FQDN that coresponds to the same as when you do an "nslookup FQDN" on a client machine.
Here is a good artcile on the AD-OD configuration, it goes over basic authentication / configuraiton. Although your not using workgroup manager anymore since it moved to profile manager (aka devicemgr). Although the PDF doesn't specify the CLI commands to remove the kerberos realm of the OD master, and join the kerberos realm of AD. They do go over it in the GUI, but I never had good luck with the GUI. I did specify in my list of instructions about the "dsconfigad" command reguarding how to unbind the kerberos realm of OD and join the AD realm.
Yes the FQDN and the cert matched up correctly. I'm not sure what I did different but I tried downloading the trusted profile first and it worked as you said it would. This let me install the cert just fine after that.
I was trying this before and it wasn't working. I'm not exactly sure what caused the change but it probably was the cert. This thread was very helpful in setting this up correctly.
I'll take a look at the document and make sure I set that portion up correctly as well. Thank you for the link and your help.
One more question. When setup correctly are AD users suppose to be able to login to the enrollment area? Do i have to find each user in Profile Manager and check the box "Can Enable Remote Management"?
Your welcome :-)
Glad you could get it up and running.
Requarding your question on AD.... If you have multiple domains in your forest please specify that your not going to use any domain in the forest to authenticate you. AD-OD gets ****** off when there is more then 1 domain in the forest. If you specify what domain your using it is a much happier environment and things work properly.
AD users can login to the enrollment area, you can adjust this by only allowing specific users if you want or groups. Normally this works by nesting an AD group inside an OD group and applying the security to the OD group on the mac environment. This way anyone that adds a user to an AD security group will have permissions to enroll if needed.
If you havn't download Server Admin Tools and connect to your OSX server via the "Server Admin.app". Once logged in Select the server and go to "Access" on the Group of Icons along the top of the application.
There will be spot for Services / Administrators. You can add groups in here to allow only specific users to login to specific services. AD users will be able to login these services once you have the proper AD/OD authentication configured.
The box "Can enable Remote Management" means the user was given access to administrate the server. Hope this info helps!
That was very helpful as well. Thank you. I think the last step is to get push notifications working. We don't block internal ports and the following ports going out from the server are open (80, 443, 1640, 2195, 2196, 5223) does any port incoming need to be open?
When I change the profile and it attempts to push the profile it just sits at sending and the device never gets it. I can confirm this in active tasks. Any thoughts here are welcome as well.
Your more then welcome!
I would only use port 443 instead of 80 from the outside. (HTTPS is more secure then HTTP) The other ports that you listed were ports that need to be opened by either NAT (1 to 1) or port forwarding if your using Dynamic NAT (Router owns the public IP and you forward the ports to an internal IP)
These ports would need to be opened coming inbound. Our firewall rules from the DMZ to Untrust are (any any). So I dont have the proper outbound rules.
When you are talking about the profile is never pushed is this on IOS devices? If so it may be because the wrong firewall rules were created. I have also seen some odd things happen with my iphone 3g. We have Aruba Wireless controller with aruba ap-125's. They seem to be happy and push to most devices, although my iphone 3g sometimes has issues when the network is congested during the day.
You can also try pushing to the devices on 3g. With the ports opened for incoming that you listed do work over 3g access.
Does the server push to your macbookpro properly?
Another note is that I have seen some macbookpro's be picky, and they only push settings upon logging off / rebooting.
OK i finally back to working on my mac mini push server! Had to stop for other projects. I am able to push the trust cert self signed (i am not using a purchased signed ssl cert) out to my iPhone 4 and i can i also push out a VPN profile setting as well. But i cannot enroll the iPhone 4 device with the profile manager. I get the following listed below when i try to click on enroll device from the iPhone 4 browser.
Btw i am installing over the internet.
Thanks for any help.
Try enrolling locally to the FQDN. When you enroll over the internet the public DNS record has to have the same FQDN as you used for your internal DNS.
If you want your push to work over the internet you will have to create a public DNS record that coresponds to your FQDN.
If your server is called server.apps.net that will have to corespond to your OD Realm and your push certs you obtained from apple with the FQDN of everything that was used.
Since certs are bassed off of a FQDN..... Your DNS name will have to be able to resolve the FQDN. If this doesn't it will say your cert is invalid. The apple push certs use your FQDN of your OD realm. So in order to make everything happy depending on what your public DNS record is and your internal domain you may have to start over to make everything match up properly.
If you use internal DNS for testing purposes you can always create another DNS zone in Windows and and then the devices will be able to resolve that zone.
Ok i tried to enroll the mac mini that the profile manager is running off of and it fails to install. I can reach my server with same domain name from both local and Internet and it resolves correctly. What would you suggest i do? Wipe it all and start over? If I do start over I did read both post you guys made about it and I am confused to the correct way to start this over with fresh setup. Do I created the local self signed cert before I do the apple push certs etc. My head is starting to spin. I really do appreciate all your help.
Hey guys I would like to start over and do a fresh setup of the Profile manager and OD stuff. Seems my OD wasn't getting setup right. So I have read two post showing ways of performing but I am a bit confused! I just want to start fresh. I do not have a SSL cert from anyone so I guess I would use a self signed one? I am stopping now as I have worn myself out trying to get this going. I know its asking a lot but it would be nice if someone had a walk thru? Would it better if I bought a SSL cert? I would rather not. I am not using active directory either. It seems to me that there should be a plan to follow so we don't get our certs created wrong. As I stated I am new to all this and I am learning as we go along.
Thanks for all you guys help!
You can start by thanking apple for making a poor install / config guide. As 10.6 that had much better documentation for install / config guides :-)
Go back to page 3 and go toward the bottom, there is a guide i put together that tells you everything to do inorder to get it up and working properly, you can do this without wiping the unit.
If you do this I would just ignore this step below in quotes as it retains to having your OD master join your AD realm.
"3) I would suggest removing kerberos, and binding it to the AD realm."
If you decide to do a reformat / wipe then go for it. Only thing you have to worry about is DNS.
Make sure you have a proper forward / reverse zone and you can do lookups both forwards and backwards on the host. Once your DNS is configured properly, you can configure OD / Profile Manager as it will use your DNS for your FQDN that is already configured.
Once that is done you can sign up for the push certs through apple, you will notice the FQDN of your push certs will match up to what your FQDN is. Since everything apple does is bassed of your FQDN they all need to match.
If you want to go public, you will have to setup the DNS record to match the FQDN of your server so that way the server will have a proper CERT (the cert has the FQDN of your server).
If you want to have a different public DNS record like server.domain.com you will need to setup that forward / reverse zone on your DNS server and make sure the hostname / FQDN of the server matches this structure before creating your OD / Profile Manager settings and Apply Push Certificates.
If you create a public cert, that will work, although you still need to be in the correct format since the public cert uses your self signed cert in order to create the public cert. So if DNS / FQDN is not correct the public cert will be a waste and a new one will have to be created.
You are better off getting everything working and then setting up a public cert.
Just remember everything is bassed of DNS (Certs / OD / Apple Push Certs). If you dont have the proper DNS / FQDN then it wont work. If you have to create a DNS zone for this purpose then it wont hurt to do so.
Im more then happy to help, and help troubleshoot your issue, but there should be more then enough info just alone in this forum in the direction you need to go. As I have helped some users that apple couldn't even help. If you need step by step help you may want to consider opening a ticket with apple since they employee people to do that kind of work.
Apple did not make it easy this time trying to deploy things, they thought it would be best to strip out confiuration settings and steps in the GUI so that it would be more toned down for the "every day" user although it doesn't work that way in the end. I had alot of issues at first but in the end it all comes down to DNS, since the Self Signed certs are auto geneated from the FQDN.