Profile Manager Fails To Deploy

-- changing a "device" or "device group" setting will most likely knock the client workstation offline causing the profile deployment to fail if a "networking" profile is enabled. this is a side effect of changing the network settings while connected to the network. an additional reboot should be attempted (up to two times) to ensure the profile is properly deployed.

---- this is cumbersome... changing a device setting unrelated to networking will cause the deployment to fail

---- our work around is to create a device group called "networking" that only contains networking related items (and nothing else) to reduce having to change this profile. make the network profile rock solid so you don't have to change it.

---- create another device group called "workstations" (whatever)... and configure the bulk of your settings in the "workstations" group. that way a minor change to the login screen or whatever... won't trigger a network refresh... this will keep the client online to complete the profile deployment.

---- the downside to this work around... all comupters will need to be added to 2 "device groups" ... "networking" ... and your other "workstations/whatever group"

-- multiple short_name aliases appear to break group profile manager settings (and probably individual user profile settings. when in doubt remove any additional short_name logins assigned to the user. (Server App > Users > Highlight User > Right Click User > Advanced > remove all alias / additional short names

-- Remove the group from the User... save .. then add the group back as a simple test to try and dislodge profiles that won't deploy.

See https://discussions.apple.com/thread/4257714 for all the problems that went into the above two workarounds.

Update:

We have decided against using Profile Manager.

Simply put... it appears unstable... and unpredicatable.

Should you plan to implement OSX (Mountain Lion) Profile Manager in your enterprise, please be advised of the following possible consequences:

-- Group profiles are almost impossible to deploy consistently

-- There is a high probabilty of the "active task" being stuck indefinitely and/or simply failing to deploy altogether

---- Therefore... having a group "sales" or "support" that each have serparate and distinct users... and separate and distinct restrictions, dock settings, mail settings etc... just won't deploy consistently.

-- On the otherhand... Device profiles seemed to deploy with fair ... to good consistency.

-- Be advised that a bunk profile... may actually result in all of your group profile restrictions being removed and/or destroyed. This may pose a security risk depending on your organization.

-- We have found a number of "silent-ish" errors that are undocumented, but destroy the prescribed profile.

---- for example: calendars appear to destroy group profiles. multiple short name aliases. restrictions may allow you to block your own deployment.... etc etc

---- we honestly felt that adding any additional settings was the equivalent of playing undocumented minesweeper... maybe it works... maybe it breaks everything

-- heads up on mail settings... if you mess up the initial setting... and try and remove the profile... it will delete the imap settings... but leave the smtp settings behind.

-- this further complicates trying to correct a typo in a mail profile (because of the reminent smtp setting)

-- In our opinion... typos happen... if you spot the typo and correct it in a profile... it should deploy and fix the typo... not get stuck and break the profile manager.

---- similar experience with messenger

-- we experienced a major silent error with zero documentation and/or error log messages... in fact, profile manager on the server would report that a settings update deployed and succeeded... the client would receive the request to update the setting... it would acknowledge the update in syslog... but it just wouldn't take. this was ultimately what caused our decision to move away from profile manager. we don't know what caused the error... but after hours upon hours (weeks) of downtime trying to fix this... we decided it simply wasn't worth it.

-- For comparison sake... all the mystery errors that we were unable to solve in profile manager... were fixed with MCX profiles set in Workgroup Manager upon first deployment. The MCX profiles pretty much deploy consistently and as expected.

----- MCX glitch and workaround. The only real MCX problem we would find... is on computers that have been renamed. For example... repurposing a salesworkstation1... for salesconferenceroom... would leave behind a Computer MCX profile that may conflict. The solution was to delete it:

-------- dscl . list Computers

-------- # look for any bad computer names

-------- dscl . read Computers/badcomputername (just to check it out)

-------- dscl . delete Computers/badcomputername

-------- mcxrefresh -n username

---------------- if no errors ... you're good

---------------- if errors... repeat deleting more computer names (even the real workstation name)

--------------------- retry mcxrefresh -n username

--------------------- repeat until no errors

Long story short, we feel Profile Manager shows promise for the future... but it's simply not ready now.

We were able to complete massive settings deployments within 2 days of using MCX (that we couldn't achieve struggling for weeks with Profile Manager)

I'm happy to discuss feedback if you are reading this post... and feel like Profile Manager is behaving strange.

If you have successfully deployed settings using Profile Manager and disagree with the contents of this post, I'd be interested to hear about it. It seems as if Apple is moving away from MCX ... ... we would prefer to use "supported" platforms (ie Profile Manager) ... we fear that MCX is in the process of being deprecated... and that we are kicking the can down the road by hanging on to MCX. Unfortunately, the business impact has been brutal... hence the switch to MCX.

If you allow the user to control some of their own mobility settings (forget where this option is but I believe it is the default to allow users to adjust their sync rules)... then

merge with user's settings will take your rules and the users rules and apply them both.

For example:

Sysadmin says... sync Documents and Desktop, and explicity don't sync Mail and IMAP stuff

User says... sync Photos

The new sync rules will be:
sync Photos, Documents, and Desktop, and explicity don't sync Mail and IMAP stuff

>>> Payload for the workgroup set to use the %short name isn't working. It works for SOME users, but not all. If a user had anything in their preferences for messages before, could that interfere with the payload? IE, could deleting the user's messages prefs, or somehow refresh it help?

editing the profile payloads for mail ... (i.e. trying to perform a simple edit or change) would produce bizarre results. Some would work, some wouldn't. We experienced similar unpredictable behavior with profile settings for messenger. We were unable to consistently deployes these settings. Wish I had more positive news to report.

>>> Instead of trying to use the payload variable, would it be better to setup a user payload for messages settings?

If you have to create a custom payload per user (for every user) then I would argue it's just as easy to go configure the user's actual computer. IE, sysadmin's are not benefitting because they can't template profile settings. Add in the problem of "it just randomly stopped working, it's stuck, and won't deploy" makes it hard to proceed with profile manager.

>>> Will that information load on any computer they log into, regardless of whehter it is set to be their device? IE, if they login to imac5, which is my device, isntead of imac1 which is their device, will that user payload still show up for them?

Great question. I don't know the expected behavior for this and would love clarification from Apple on this. For us, this was slighlty mitigated by roaming profiles and mobile sync users. IE the user only needed the setting to be deployed once... and in theory, since they take their home folder and settings with them... it would not matter if they "received" the profile at a new computer... because their home folder should have already saved the deployed profile. So, although I don't know the answer... our theory was a portable home directory would receive the deployed profile settings and save them (making the update not needed?)

Again, we ultimately ditched profile manager in favor of the outdated but functional MCX Workgroup Manager settings.

This is no good... these types of problems makes the Profile Manager unreliable to use.

No... but I have not seen substantial updates to the product in the updates.

There was one update recently... but the description is so vague that I am not hopeful it solved these core problems entirely:

http://support.apple.com/kb/HT5583

Profile Manager

Adds the ability to use Active Directory groups with Profile Manager.

Adds the ability to delete apps uploaded to Profile Manager.

Includes performance and other general enhancements.

Again, I have not pursued it further... but based on recent feedback from others... i'm doubtful anything has improved.