What I Do At Work

Today I finally had the time to begin experimenting with Profile Manager built into Mac OS X Lion Server. Apple's documentation is extremely poor to say the least, so that has forced me to make some assumptions based solely on discoveries of my own throughout the day. If any of them are wrong, please leave a comment and let me know otherwise.

Here's what I found.

Setup

The setup process for Profile Manager and the MDM server bundled into it is extremely easy.

1. Ensure proper DNS and then setup the server to be an Open Directory Master. 
2. Create a new self-signed certificate and use that to generate a CSR for a real CA. We use Entrust here at RMU. 
3. Submit your CSR, get a real, valid, SSL certificate and then replace the self-signed cert with the one signed by your CA of choice. 
4. Install any intermediate certificates and then select the new cert to be the primary one for the server. 
5. Click the "Edit" button next to "Device Management" on the Profile Manager pane of Server.app and go through the steps, one of which being the process of acquiring an Apple Push Notification Sevice (APNS) certificate. 
6. Check the box for "Sign configuration profiles" and use the self-signed OD CA Code Signing Certificate, or purchase a real code-signing certificate from a CA (not really necessary). 
7. If you want to change the name of the global settings for everyone profile, do that.
8. Turn on Profile Manager.

Initial "Oooh Ahh" factor

After Profile Manager lets you know it's fully ready for use, you can access it as an admin at https://server.example.com/profilemanager

After logging in, you're presented with an "oh wow this is pretty" website. But imemdiately after the "wow" factor wears off is when you're left hoping for more detailed documentation. Similarly to Workgroup Manager, it's clear that you can assign profiles at the User, Group, Computer, or Computer Group level. Clicking around the various groups and users shows it's not very difficult to build different profiles for respectively different groups. However, there's no documentation on levels of precidence nor on how conflicting settings will interact. Initial testing by Arek Dreyer shows that Device profiles tend to take precedince over User or User Group profiles. Also gone is the concept of "Always", "Often", "Once", and "Never". Things applied through the use of Profiles essentially are always at the "Always" level of persistency. 

Things that should be documented

1. By default, everyone is in the "Everyone" group. The "Everyone" group has the option checked to allow members of the group to "Enable Remote Management" under "Portal Access." This means that by default, everyone can enroll their devices into Profile Manager; probably not what you want to have enabled. It also means that trying to turn off the ability to enroll devices is greyed out at the user level. Disabling the option at the group level then of course unlocks the ability to set it per-user.
2. Only admins can see Enrollment profiles when logged in to the user portal.
3. You cannot pre-associate a user with a device. Therefore profiles configured for devices and device groups will never show as available for download in the user portal. Only user and user group profiles will show.
4. Along with number 3, if you set a profile's distribution type to "Manual Download," it will only show in the list in the user portal if it is a user or user group profile, not a device or device group profile.
5. Along with number 3 and 4, if a device or device group profile distribution method is set to "Manual Download", the only way to get access to these is to download them as an admin through the admin portal and distribute them via some other means. They will never be shown in the user portal.
6. There is currently no way to lock trust profiles or device management profiles. Only configuration profiles. This means an admin user can easily remove their device from device management.
7. Why anyone would ever need more than two, a "Restricted" and and an "Unrestricted", enrollment profiles. The only option for enrollment profiles is whether or not the computer is required to be in the devices list prior to enrolling. Maybe I'm not understanding these properly, but here at RMU I imagine I'd only ever use a Restricted Enrollment Profile? Perhaps I'd want more if I want a more granular view of the "Usage" of the particular enrollment profile?

Bugs I found

1. My trust profile didn't immediately show in the user portal as available for download. In Server.app, even though it was already selected, I had to select the code-signing OD CA self-signed certificate again and profile manager rewrote the settings.  It then became available for download. This happens after every restart of the Profile Manager service.
2. My trust profile is named "Trust profile for" but is missing the domain or name of the server. Running "sudo serveradmin settings devicemgr:server_organization = fqdn.example.com has no effect.
3. Using Firefox 7 with the admin web interface presented some problems. Active tasks wouldn't change to completed unless I reloaded manually. Safari also had some issues with this, but less often.
4. When manually importing a plist to the "Custom Settings" section of a profile, you're unable to delete more than one key out of that plist at a time. Pressing shift or command to select multiple items does not work. For example, if you import the Safari plist but only need the HomePage key, you'll be there for quite awhile clicking "delete" on the unneeded keys. As a workaround, write a plist to your desktop with the same name only containing the keys you need. Then upload that.
5. There is no way to resize the columns in the "Activity" panes in the admin portal. There is a lot of available screen space but the web app keeps the columns super tiny.

Overall first day experiences

A lot of bugs. A lot of confusion. Shit poor documentation. The best third-party resource I currently know of is Arek Dreyer's presentation at MacSysAdmin 2011. Listen to his presentation; it has a lot of good sidenotes.

Remote wipe and remote lock are both cool. Note that remote lock immediately reboots the machine; there is no prompt and no opportunity to save.

If this is the tool that Apple wants us to use to replace MCX and Workgroup Manager, it's got a long way to go. MCX is well understood and has extremely detailed documentation. We sys admins don't just want to know how to do something, we want to know WHY it works the way it does and what to do when it doesn't. This was my favorite line from the Apple Profile Manager documentation:

To send the URL of the Profile Manager server to a user so they can log in and download the configuration profiles you assigned to them, click the arrow next to Visit User Portal, then copy the URL from the browser window that opens.

Thank you, Apple, for that extremely helpful lesson on copying and pasting. I could have never figured that out by myself!

I'll leave off with this. Profile Manager's logging isn't so bad. But often it says this:

Oct 19 16:19:54 server.example.com ProfileManager[13678] <Info>: Processing MagicController#do_magic (for ip.ad.dr.ess at 2011-10-19 16:19:54) [POST]

Do Magic through the MagicController, huh? I'd really like to know what that is.

Friends in cupertino...

Profile Manager | Editing a custom imported plist | Deleting Multiple Keys
rdar://problem/10317006

Profile Manager | Activity Panes | Unable to resize/wrongly sized columns
rdar://problem/10317034

Profile Manager | Trust profile unavailable for download after service restart
rdar://problem/10317052

Profile Manager | Trust profile missing organization name
rdar://problem/10317107

Profile Manager | Add ability to lock trust and enrollment profiles
rdar://problem/10317143

Profile Manager | Updates to documentation
rdar://problem/10317170