Delivering Profile Manager Policies/Enrolling via Workgroup Manager MCX?

Does anyone know if it is possible, and what strategy one would use for enrolling clients in an existing WGM/MCX infrastructure into a Profile Manager managed scenario?
Basically, what we are talking about doing is automating the run of the .mobileconfig profiles/Enrollment profiles on each system.
Assuming one can deploy WGM settings to these systems, is there a zero-touch way to enroll them?
Thanks.

You can create many different workflows in Deploystudio and these can do all sorts of things, such as partition a hard disk, image a computer and enroll them in configuration profiles, bind to active directory, set open firmware password. Of course you can also create a single step workflow that just enrolls them and reboots. Enrollment is one of the build in templates.
If you have ARD, you use the GUI to copy the profiles to a certain directory and reboot (there are instructions on the net).
If it doesn't work, there is also a UNIX command you can run in the GUI.
http://www.afp548.com/2012/06/01/automating-enrollment-of-lion-into-profile-mana ger-on-os-x-server/

Similar Messages

Profile Manager - Why create Enrollment Profiles?

So a similar question was asked previously:
Why use an enrollment profile?
I've read through it and I don't think the answers provided tell the whole story, so I'd like to ask again adding some of my own thought and clarifications on the previous thread. This may be considered a "primer" by some - though I am certainly not the expert on Profile Manager. I'm laying it out there to explain my understanding and off of that, ask a question. If you are an expert, and understand how all this works, please just skip to my question below!
First, my experience and understanding. (I urge others to correct/clarify where they see fit):
The previous thread attempted to make a distinction between the 3 different types of profiles: Trust, Enrollment.and Remote Management Profiles.
I believe the proper 3 distinctions should be: Trust, Remote Management/Enrollment, and Configuration Profiles.
- The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles. It's a fancy way of packaging up the Root certificates.
- The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection". It registers the device with the Profile Manager server and facilitates the ability to use PM/APNS to push various Configuration Profiles as well as commands (wipe/lock/etc). It is *only* called an Enrollment Profile when you explicitly create one (more on that below). Because an Enrollment Profile does not need to exist to enroll (or rather it will use the implicit "unseen" enrollment), this is the most confusing of the 3 Profile types. It is further confusing because the term "Profile" is used almost elusively on the device and not within Profile Manager. In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!
IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices. This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.
- The Configuration Profile is a Profile (.mobileconfig file) that delivers specific settings. These Profiles are applied to either Users, Groups, Devices, or Device Groups. They can be automatically pushed to an enrolled device, or they can be manually downloaded from the MyDevices page (seems to apply to User configuration only) for devices even if they are not enrolled (this would allow the end user the 'choice' to pull down settings).
Having outlined that, the simplest steps to enrollment...:
When you setup Profile Manager, you can go right to the MyDevices page on your device, login, and choose "Enroll." (sample device is let's say an iPad)
Doing so will prompt you to install the "Remote Management" profile.
Note that when enrolling in this way it does not appear necessary to install the "Trust Profile" for your server, even when using a Self-signed Cert. It would appear that this "Remote Management" profile contains not only the SCEP Enrollment Request and the Device Management payload, but also the Certificates that would be installed with the "Trust profile"
So we have seen here that one can enroll a device without explicitly creating any "Enrollment Profile."
So why use an Enrollment Profile?
Well according to https://help.apple.com/profilemanager/mac/3.1/#apd6DD5E89E-2466-4D3C-987E-A4FF05 676EB7, the answer is pretty straightforward:
"The user does not need to authenticate or log in to Profile Manager’s user portal"
This is a great feature. For one, you can create an Enrollment Profile and send it via e-mail and the user doesn't need to visit a web page and login to enroll a device. In fact, based on my experience Enrollment Profiles can't even be accessed via the MyDevices page unless you are a Server Admin.
However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server. Several docs/tutorials you can google explain how to set up your deployment systems (specifically OSX machines) to deploy systems with both the Trust and Enrollment profiles to facilitate automatic enrollment when a new system is deployed so it can instantly be managed.
However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile. Because of that it seems that from a distribution approach (as opposed to a deployment scenario) there is not much advantage of using an explicit Enrollment Profile anyway since we already need to visit the MyDevices page to get the Trust Profile, we might as well just use the standard MyDevices implicit Enrollment.
All devices that have enrolled themselves via a defined/explicit Enrollment Profile will be listed under that Profile in Profile Manager. Devices that have enrolled via MyDevices will not be listed under any Profile, but rather just under Devices (where *all* devices will be shown regardless of how they enrolled).
So, now the questions:
So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.
What I don't get is WHY is there the ability to create multiple Enrollment Profiles rather than simply providing a default exportable profile?
The reason it makes no sense to me is there is absolutely no correlation (that I can deduce) between an Enrollment Profile and the devices that used it to enroll. While I can see a (non-exportable) list of each device enrolled via each Enrollment Profile, it ends there. I can't, for instance, create Configuration Settings that I link to an Enrollment Profile. Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile. If I could do these things, it might make sense to me and I have spent much time looking at the interface and scouring documentation to see where the connection is. I have simply determined that there isn't one.
I can go ahead and create several Enrollment Profiles such as:
iPads
Lab Systems
Main Office Systems
High Security Systems
And I can deploy these Profiles (either via mail/file or via initial deployment) to the respective devices. I can then see under each Profile which devices enrolled. But, since I can't actually do anything to correlate those systems to a configuration, why would I want to do this segregation? Sure it gives me a listing of iPads apart from OSX machines, but I can't do anything with this listing!
Now, of course, I can still pre-stage devices and add them into particular device groups so that as soon as they are enrolled (via any Enrollment Profile) they will get the Configuration Profile(s) attached to them. This makes the inclusion of multiple Enrollment Profiles even more suspect.
Am I missing something? Can someone enlighten me as to what the purpose of creating more than one Enrollment Profile would be?
We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is. Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.
Thoughts?

So a similar question was asked previously:
Why use an enrollment profile?
I've read through it and I don't think the answers provided tell the whole story, so I'd like to ask again adding some of my own thought and clarifications on the previous thread. This may be considered a "primer" by some - though I am certainly not the expert on Profile Manager. I'm laying it out there to explain my understanding and off of that, ask a question. If you are an expert, and understand how all this works, please just skip to my question below!
First, my experience and understanding. (I urge others to correct/clarify where they see fit):
The previous thread attempted to make a distinction between the 3 different types of profiles: Trust, Enrollment.and Remote Management Profiles.
I believe the proper 3 distinctions should be: Trust, Remote Management/Enrollment, and Configuration Profiles.
- The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles. It's a fancy way of packaging up the Root certificates.
- The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection". It registers the device with the Profile Manager server and facilitates the ability to use PM/APNS to push various Configuration Profiles as well as commands (wipe/lock/etc). It is *only* called an Enrollment Profile when you explicitly create one (more on that below). Because an Enrollment Profile does not need to exist to enroll (or rather it will use the implicit "unseen" enrollment), this is the most confusing of the 3 Profile types. It is further confusing because the term "Profile" is used almost elusively on the device and not within Profile Manager. In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!
IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices. This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.
- The Configuration Profile is a Profile (.mobileconfig file) that delivers specific settings. These Profiles are applied to either Users, Groups, Devices, or Device Groups. They can be automatically pushed to an enrolled device, or they can be manually downloaded from the MyDevices page (seems to apply to User configuration only) for devices even if they are not enrolled (this would allow the end user the 'choice' to pull down settings).
Having outlined that, the simplest steps to enrollment...:
When you setup Profile Manager, you can go right to the MyDevices page on your device, login, and choose "Enroll." (sample device is let's say an iPad)
Doing so will prompt you to install the "Remote Management" profile.
Note that when enrolling in this way it does not appear necessary to install the "Trust Profile" for your server, even when using a Self-signed Cert. It would appear that this "Remote Management" profile contains not only the SCEP Enrollment Request and the Device Management payload, but also the Certificates that would be installed with the "Trust profile"
So we have seen here that one can enroll a device without explicitly creating any "Enrollment Profile."
So why use an Enrollment Profile?
Well according to https://help.apple.com/profilemanager/mac/3.1/#apd6DD5E89E-2466-4D3C-987E-A4FF05 676EB7, the answer is pretty straightforward:
"The user does not need to authenticate or log in to Profile Manager’s user portal"
This is a great feature. For one, you can create an Enrollment Profile and send it via e-mail and the user doesn't need to visit a web page and login to enroll a device. In fact, based on my experience Enrollment Profiles can't even be accessed via the MyDevices page unless you are a Server Admin.
However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server. Several docs/tutorials you can google explain how to set up your deployment systems (specifically OSX machines) to deploy systems with both the Trust and Enrollment profiles to facilitate automatic enrollment when a new system is deployed so it can instantly be managed.
However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile. Because of that it seems that from a distribution approach (as opposed to a deployment scenario) there is not much advantage of using an explicit Enrollment Profile anyway since we already need to visit the MyDevices page to get the Trust Profile, we might as well just use the standard MyDevices implicit Enrollment.
All devices that have enrolled themselves via a defined/explicit Enrollment Profile will be listed under that Profile in Profile Manager. Devices that have enrolled via MyDevices will not be listed under any Profile, but rather just under Devices (where *all* devices will be shown regardless of how they enrolled).
So, now the questions:
So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.
What I don't get is WHY is there the ability to create multiple Enrollment Profiles rather than simply providing a default exportable profile?
The reason it makes no sense to me is there is absolutely no correlation (that I can deduce) between an Enrollment Profile and the devices that used it to enroll. While I can see a (non-exportable) list of each device enrolled via each Enrollment Profile, it ends there. I can't, for instance, create Configuration Settings that I link to an Enrollment Profile. Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile. If I could do these things, it might make sense to me and I have spent much time looking at the interface and scouring documentation to see where the connection is. I have simply determined that there isn't one.
I can go ahead and create several Enrollment Profiles such as:
iPads
Lab Systems
Main Office Systems
High Security Systems
And I can deploy these Profiles (either via mail/file or via initial deployment) to the respective devices. I can then see under each Profile which devices enrolled. But, since I can't actually do anything to correlate those systems to a configuration, why would I want to do this segregation? Sure it gives me a listing of iPads apart from OSX machines, but I can't do anything with this listing!
Now, of course, I can still pre-stage devices and add them into particular device groups so that as soon as they are enrolled (via any Enrollment Profile) they will get the Configuration Profile(s) attached to them. This makes the inclusion of multiple Enrollment Profiles even more suspect.
Am I missing something? Can someone enlighten me as to what the purpose of creating more than one Enrollment Profile would be?
We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is. Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.
Thoughts?

Do I need internet access on my iOS devices to enroll with Profile Manager?

Hi, I'm trying to configure Profile Manager on a closed network. The Mac Server does have Internet access, but the network for the iOS devices can only have communication with the server, but not to the internet because of company policies. Is there a way around to make it work or do I need internet access on the iOS devices as well?
I've made the enrollment process in another network with internet access for every device and everything works well, but on the other network(no internet for iOS devices) everything seems ok (from conection to the server, profile certifiacation and stuf) but the devices can't send or receive anything else, like pushed configurations and device info. Ports and everything is ok, I even read that they need to be on an open network so I know it all comes down to having internet access, but just wanted to ask if there's another way around?? Suggestions?
Thanks!

You can share internet connection with your XP-PC using a router(as I do with XP-old MAC's,connected via cable).You may look for more info at:
http://homepage.mac.com/car1son/mylinksyssetup.html
and
http://homepage.mac.com/car1son/os9xnet_nfilesharing.html
Did you ever use a MAC before? Have you got Airport at your PC?Which?
Good luck

IOS 8.1.1 devices "pending" after enrollment in Profile Manager

Setup:
OS X Yosemite with server 4.0
After installing the trust certificate and enrolling an iOS 8.1.1 client, I can see the specific device in Profile Manager. However the status of the device stays "Pending". It seems that the enrollment proces can't proceed.
When I enroll a device with iOS 7.1.1 there are no issues. Everything works fine!
Any suggestions?
Thx

The devices had been running ios 8.1 for a number of days.
We've had two more do this since my last post. In each occasion, the devices are running iOS 8.1, have been turned off and turned back on again to boot to the Apple logo and remain there indefinitely.
Hard resets don't solve the issue, the only remedy is a full restore via iTunes resulting in complete data loss.
Surely others are seeing this issue if we've had 6-7 devices in the past few days?
iOS 8.1 + reboot = brick?

Email profile uses Device Enrollment Manager user?

Hello,
I have an iOS device that was enrolled via the Apple Device Enrollment Program, using a Device Enrollment Manager account, and I have since deployed an email profile configuration policy to it. After it received the policy now the account
of the Device Enrollment Manager is locked in as the user in the email profile. Is that normal behavior? I thought that enrolling a device using a user who is a member of the Device Enrollment Management group would leave the device open for another
user?
Thanks!

Hello, I was looking through TechNet a little more about this and unless I'm reading this wrong, which is certainly possible, it seems to suggest that you should be able to access company data as the end user using CYOD enrollment or a device enrollment
manager enrollment scenario:
User affiliation – Specifies how devices are enrolled.
Prompt for user affinity – The device can be affiliated with a user during initial setup and could then be permitted to access company data and email as that user. This mode supports a number of scenarios:
Corporate-owned personal device – “Choose Your Own Device” (CYOD) Similar to privately owned or personal devices but the administrator has certain privileges including permission to wipe, reset, administer, and unenroll the device. The
device’s user can install apps and has most other permissions for device use where not blocked by management policy.
Device enrollment manager account – The device is enrolled using a special Intune administrator account. It can be managed as a private account, but only a user who knows the enrollment manager credentials can install apps, wipe, reset,
administer, and unenroll the device. For information about enrolling a device shared by many users through a common account, see
Enroll corporate-owned devices with the Device Enrollment Manager in Microsoft Intune.
No user affinity – The device is user-less. Use this affiliation for devices that perform tasks without accessing local user data. Apps requiring user affiliation are disabled or won’t work.
With this in mind, since accessing corporate data as the user is supported with CYOD and device enrollment manager, I can't imagine that the intention of the device enrollment managers (DEM) group was designed so when a device is enrolled with a DEM
user that only data for that DEM user is available, right? That just wouldn't make sense. Also, if enrolling a device using a DEM user account is only for devices that don't need access to corporate data, then what's the difference between enrolling
a device using a DEM user, or enrolling a device with "No user affinity"? Also, when I've enrolled a device using a DEM account, I was later easily able to install apps with no prompt for DEM credentials, TechNet seems to imply that credentials
are needed for functions like that. Shouldn't something have asked me for permission to install an app?

Disable USB drive write access via Profile Manager

Is there a way to disable users from plugging in a USB flash drive and copying files to it via the Profile Manager?
We are trying to configure this on a Mac network running 10.10.x with Server 4.0.3.
I understand that this can be done by deleting the IOUSBMassStorageClass.kext as a solution in older versions of OS X and that this was apparently possible in Workgroup Manager (now legacy and not supported). I would like to learn how to do this using the latest methods in 10.10.1 or 10.9.
Any tips would be greatly appreciated.
Cheers,
MC

I post on both to try to raise awareness. All previous topics have been to delete the usb drivers, put hot glue in the ports and to use the now non-supported Workgroup Manager. Thanks for checking though!

Pushing Paid apps via 10.8 Profile Manager (working solution!)

Hello,
It seems the profile manager solution leaves a lot to be desired. I am quite disappointed there are several limitations that make the software a real deal breaker for it's price. The number one issue other than black/white listing non productive apps is of course, the PAID app Deployment. One would think they would totally OWN this process, but as they have done so many times before, left it up to a 3rd party solution. THANKS @pPl3! only no thanks.
Well I have created a solution that I believe works and would like to share it with everyone.
The model is simple, use Apple configurator to image and deploy the devices, and then manage them via Profile manager with 1 shared apple ID
1. The Master iPad we used was configured with 1 apple id:[email protected]. We set up all the Free applications we liked with our settings inputted. We then deleted any unique information such as usernames, wifi networks, etc. so it's a clean image with some custom configuration. We then connected to Apple configurator and created a back up.
2. We loaded any Free apps we wanted preinstalled into the Apple Configurator software and then when prompted used the same apple id as the ipad:[email protected]. These free apps were downloaded through itunes on the server using the same apple id. We also added one profile to be loaded, the trust profile and also have a web clip taking us to the "Enroll Device" page on
3. We then connected a brand new ipad, choose to wipe and restore from back up along with updating to the newest IOS. After that configured Wifi and Enrolled the device to the Profile manager server. Then added the device to the proper groups to get policy information downloaded.
4. Now the paid app Test, we purchased one application on the OSX Server's itunes. In order to be compliant with the test, we only purchased one licence, therefore we could only push it out to one device. We uploaded the App into the profile manager and deployed OTA to one of the iPads.
5. We accepted the install and then the App loaded and was able to launch. We removed it and the pushed it to another device freshly configured by profile manager, it worked as well.
6. For future purchases we use the VPP, buy as many apps as we want but only redeem ONE of the codes on the osx server, using the same apple ID as before. We then upload it to profile manager and deploy it to as many devices as we are licensed to.
The only problems I can imagine:
1. If apple doesn't like it, I am under the opinion we are not breaking any licensing compliance. We still have the apps paid for and legally have the licensing for auditing purposes.
2. IF after 10 devices the apple id starts giving us issues. I read there is a limit but it appears the options to manage your devices has been removed from itunes which makes me think, No this will never happen.

Wonder what went wrong...
Also do you find another solution?
Right I am looking at three companies that run on the OSX server.
Absolute Manage
nuVizz enterprise MDM
FileWave

Can't enroll devices with Profile Manager - invalid key

n my case I can install profiles on devices from Profile Manager page but I cannot enroll devices.
The certificate I download to enroll is reject by my MacBook Pro Lion: Says Invalid blablabla at the end:
Now I have done log research and I now exactly and understand why it doesn't work:
the scep_helper daemon is supposed to listen to port 1640 TCP (which you should forward to your server by the way, if you want to be able to enroll devices) and provide the requsting client the root CA that signed the certificate. In my case, it can't find the root CAT to provide the client with so it can finalize the cert validation process.
In my case, that's what I see in the log:
Jul 29 02:12:44 teknologism scep_helper[1638]: SCEP_HELPER: /SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-701.70/scep_helper/m ain.m:727 'status = SCEPGetCACert(session, NULL, 0)' = -25300
Jul 29 02:12:44 teknologism scep_helper[1638]: SCEP_HELPER: /SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-701.70/scep_helper/m ain.m:513 'SCEPGetCACert(session, NULL, 0)' = -25300
Jul 29 02:12:44 teknologism scep_helper[1638]: SCEP_HELPER: /SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-701.70/scep_helper/m ain.m:819 'challenge = GetChallengeFromSCEP(password, guid, hostURL)' is NULL
Jul 29 02:12:44 teknologism ProfileManager[516]: Could not retrieve root certificate from open directory server.
No , as for the bad news: I have no idea on how to fix. Have dug into scep_helper, googled etc. Not a single clue on how to check it's configuration or even why it can't find the root CA. By the way everyhting else (I really mean everything, ical,cardav,web,wiki etc.) work great. And profile manager too, it's just the enroll thingy that doesn't work. And the root CA cert is in /etc/certificates. My server a legit Class 1 SSL cert signed by a system trsuted CA (Startfiel to name it)
I have tried with other certs etc... It's a no go.
Can anyone help ??
How can I add that missing CA Cert in opendirectory ?

Here is some more infos...
teknologism:root root# serveradmin settings devicemgr
devicemgr:SSLAuthorityChain = "/etc/certificates/trinity.teknologism.org.C1D19D55699B48C94A18787E4F53B4C3230E 91FE.chain.pem"
devicemgr:od_active = yes
devicemgr:ssl_active = yes
devicemgr:enableCodeSigning = yes
devicemgr:updated_at = 2011-07-28 16:04:52 +0000
devicemgr:email_delivery_method = ""
devicemgr:CodeSigningPrivateKey = "/etc/certificates/teknologism.org Code Signing Certificate.ED29CE4BD9D2926D64E60EF7A117EFDB2213F0CC.key.pem"
devicemgr:apns_active = yes
devicemgr:CodeSigningAuthorityChain = "/etc/certificates/teknologism.org Code Signing Certificate.ED29CE4BD9D2926D64E60EF7A117EFDB2213F0CC.chain.pem"
devicemgr:default_profile_created_at_least_once = yes
devicemgr:knob_sets_enabled:com.apple.mail.managed = yes
devicemgr:knob_sets_enabled:com.apple.vpn.managed = yes
devicemgr:knob_sets_enabled:com.apple.carddav.account = yes
devicemgr:knob_sets_enabled:com.apple.jabber.account = yes
devicemgr:knob_sets_enabled:com.apple.caldav.account = yes
devicemgr:email_authentication = ""
devicemgr:email_port = 25
devicemgr:email_username = ""
devicemgr:id = 1
devicemgr:last_modified_guid = ""
devicemgr:SSLPrivateKey = "/etc/certificates/trinity.teknologism.org.C1D19D55699B48C94A18787E4F53B4C3230E 91FE.key.pem"
devicemgr:od_master = "127.0.0.1"
devicemgr:apns_topic = ""
devicemgr:email_password = ""
devicemgr:mdm_acl = 2047
devicemgr:user_timeout = 43200
devicemgr:server_organization = ""
devicemgr:SSLCertificate = "/etc/certificates/trinity.teknologism.org.C1D19D55699B48C94A18787E4F53B4C3230E 91FE.cert.pem"
devicemgr:created_at = 2011-07-24 11:47:33 +0000
devicemgr:email_address = ""
devicemgr:email_domain = ""
devicemgr:CodeSigningCertificate = "/etc/certificates/teknologism.org Code Signing Certificate.ED29CE4BD9D2926D64E60EF7A117EFDB2213F0CC.cert.pem"
devicemgr:email_server_address = ""
devicemgr:admin_session = ""
The 3 CodeSigning certs/keys are in /etc/certificates and their permissions are correct.
Also, don't ask me why but my ProfileManager pane in Server.app is working again. It shows all the config...but can't modify anything....as soon as I try to modify it spins the waiting whell forever... I guess it's the same error as command line serveradmin...

Can't enroll new clients in Profile Manager 3.0.3

I just upgraded a server from 10.8.5 to 10.9.2 and updated the Server app to v3.0.3. Almost everything seems to have gone smoothly, except that I can no longer enroll clients in Profile Manager, and the user under which all devices were originally enrolled disappeared.
I manually re-added the user through the Server app, and used the same short name and password for the account.
All of the old clients (OS X systems running 10.8.5) are still there. I can search within the device list, create profiles, edit profiles, and remove profiles. But none of them show up when I log into the My Devices web page with the re-created user.
This user does not have admin privileges, but even when I try to enroll a device using an admin account I still get a "500 Internal Server Error".
I can't seem to find any other threads covering this exact problem, although there seem to have been others with various PostgreSQL database migration issues during the upgrade. For examples, see this thread: Managed Settings missing in Profile Manager after upgrade to Server 3
Looking for some ideas...

Well, that is one idea that I've already had, Linc, but I'm reluctant to use the "nuclear option" for obvious reasons. I'm actually wondering now if the Secure Cert / OD problem is affecting Profile Manager. See this thread: https://discussions.apple.com/message/23686348#23686348

OS X Server 3 - Profile manager - I can't enroll any iOS devices

OS X Server 3 - Profile manager - I can't enroll any iOS devices
I have OS X Server setup on a Mac Mini and an Airport Extreme.
Airport is 10.0.1.1 and server is 10.0.1.3.
Server is setup to use DNS itself by server.mydomain.com
Airport is setup to use the server as DNS and the server then routes DNS queries onward to the internet.
Essentially anyone on my internal network thinks server.mydomain.com is the server itself. This is what I want.
From the outside, anyone searching for server.mydomain.com get's some page on a free hosting site with "Server is not accessible from the internet"
I also use a self-signed certificate to secure communications. It's valid.
Now this configuration has worked for the past two years. Out of curiosity in Server 3.1.1 I decided to give Profile manager a shot. Set it up, no worries.
Installed the Trust Profile first and then the Enroll profile. Done.
I can enroll and wipe, lock any mac in my firm remotely. Everything works, except iOS devices.
Any iOS device I try it fails at "Installing profile", I tried friend's phones, my own iPad... every iPad in my firm. It fails consistently at the same step, with no error code what so ever.
Is there a checklist I need to go through? Do I need some kind of weird certificate setup?
PS. Is it a problem if my devices are enrolled as development devices, thei UUID is in Apple's device list for beta software and iOS development?

The Problem is your DNS is being pushed locally to the iOS Device from your Airport Extreme and the DNS on your Airport extreme is undoubtedly a public form of DNS that does not recognize your private server's ip address or HQDN, in Airport Utility point the DNS at your server and let your Server provide the public DNS mapping and allow your Router to provide your Server's DNS. This should resolve your issue and allow you to enroll your iOS Devices by logging into the Profile Manager Web Portal from the iOS Device.

Can an IOS device be enrolled through profile manager when the server is set as .private? If so what steps?

I have my server set as server.xxxxxx.private, and need to know if it is possible to enroll it using profile manager. I assume this would have to be done when the IOS device is on the same network, and subsequently the DNS server would have to be added to the WiFi configuration. When I do this it tells me that Safari can't open the page. I manually installed the self signed certificate.

Same issues here.
Buggy as ****..
Also after some time, the Profile Manager PAne doesn't even fill in Server.app.....stays at Loading...
Nevertheless, the service itself works with the bug you outlined, plus enroll is impossible for me (check my post here: Can't enroll devices with Profile Manager - invalid key )
I hope all these get fixed in 10.7.1 !!!

Profile Manager Enrollment - iOS - Server Certificate Invalid

I have been getting an error trying to enroll iOS devices into profile manager. My MacBook and iMac enroll just fine. However my iPhone and iPad do not.
When I enroll my MacBook Pro, I first log into https://(FQDN)/mydevices, select profiles, Install Trusted Profile. I then go back to devices, and click 'Enroll now'. When I check the Profiles section of System Preferences, I see that the 'Trusted Profile' has added two certificates refering to my server. I can only assume one matches the Self Signed I generated shortly after making my hostname public, and the other Apple Push generated for me.
However when I do this exact same process on my iPad/iPhone, when I attempt the 'Enroll Now' step, I get the error "The server certificate for "https://(FQDN)/devicesmanagement/api/device/ota_service" is invalid.
My searches for this issue have turned up issues close to this, but never exactly this, and the solutions don't seem to work for me. Here are some key points to note:
1. Tried demoting to standalone, re-promote to OD Master, then deleted all certificates, and regenerated all (including the Push cert from Apple)
2. Ran sudo changeip -checkhostname
3. DNS routes forward and reverse correctly in my local LAN
4. I had been getting "Remote Verification failed: (os/kern) failure" / "TEAVerifyCert() returned NULL" in my logs every 3 seconds until I did the steps listed in '1'
Looking forward to 10.7.1

@hombre7777
Thanks for the info. That makes sence what you are telling me. Their instuctions are kind of bland and dont make sence as much as they should.
The only thing that scares me on this one is now we need to put a device in the dmz....
So now upgrading our xserv to 10.7 when it becomes stable would now be using the magic triangle, and trying to only have 1 to manage osx machines / and now ios devices. Edit our wiki's thats already in place, and have important databases on filemaker is now going to reside in the dmz....
So someone wasn't thinking on this one!!! haha
It looks like we will have to seperate things now, so ios devices are managed on their own machine in the dmz with now a hole leaked in the firewall for AD to authenticate so we can pull users down to associate profiles with them.
Our osx machine will then contain a seperate spot to manage osx devices bound to user accounts, as well as manage filemaker and wiki's that are in use already.
It would be nice if they had figured out a way to do this a little different so we wern't opening holes in the firewall.
The funny thing is I was able to get the ipad to bind and enroll the very first time when i was on a vpn tunnel from my house trying things out.
So I know you can do it, without having to go public, although the push service wasn't working properly and I was not able to bind osx and enroll. So i stared over.
Ill play around to see what I can figure out later. Thanks for the help. If you find out the port numbers please let me know as well! Im not able to move the box to an outside firewall right now. I have to much to do. I can probably do that next week.

Error enrolling devices in profile manager!!

I have enrolling my macbook to the profile manager.
When I go to the https://(FQDN)/mydevices/ , and I hit the enroll buttom after logining in, and download the config file, try to install.. I get an error that says:
"The profile is either missing some required information, or contains information in an invalid format."
The problem is that I managed to enroll my iPhone with no problems.. only my mac (which is running the server OS) is not enrolling.
the certificate is valid from a trusted commercial thing..
Can someone please help?

only my mac (which is running the server OS) is not enrolling.
Why are you trying to enroll your device management server in it's own device management?
I've never tested anything like that, but I bet you can't do that...

Profile manager enrolled device names

I have been playing around with profile manger on 10.7.3 enrolling and iPhone and a couple of iPads.
The iPhone enrolls correctly and the name in the devices tab shows the device name "xxx's iphone" and I can see the information about the device including encryption, apps installed etc.
Both iPads appear to enroll correctly however instead of showing "xxx's iPad" they show the device name of "New Device". I even tried pre-enrolling the device using the serial number and UUID and gave the device a meaningful name, however when then enrolling the device it accepts the enrollment and promptly chnages the name from the meaningful name back to "New Device".
I have tried this on both and iPad 2 and iPAd 3 running the latest IOS.
I also notice that the jobs that communicate with the device to collect the device informantion never complete, where they do for the iPhone.
I am sure this was working before the IOS 5.1 update.

I would try demoting your Open Directory server from Master to Standalone in the Server Admin app - there's an assistant in Server Admin > Open Directory > Settings > General > click the change button.
Once it's demoted to a standalone, restart.
From there, don't create an OD Master again - go to Profile Manager in Server.app and run through the wizard again. In the process, it will create an OD Master for you.
Hope that helps,
Chris

Devices enroll but do not appear in the Devices section in Profile Manager

Hi,
I am able to download and install the enrollment file, and when I check the devices enrolled by a user I can see the device attached to that users name, but when I click the link arrow next to the device name or go into the devices page, the device doesn't appear. Anyone have a solution for this? It's preventing me from managing any devices as it appears as if they are not there. I also notice that the Enroll button is still there in "my devices" after successful enrollment.
Thanks,
David.

Just in case anyone else get's this issue I managed to fix it by first enrolling the device then entering a place holder for the device in profile manager using that devices serial number. Then it seems to recognise the device

Delivering Profile Manager Policies/Enrolling via Workgroup Manager MCX?

Similar Messages

Maybe you are looking for