-- 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/message/19441034 for all the problems that went into the above two workarounds.
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.
What you are describing about failed or partially completed profiles deployment to clients is very similar to my own experience. I've been trying to use Profile Manager for the last few weeks (during the start of the school year deploying in an active school environment!) and it has been a real pain -- esp. the inconsistency. I did upgrade all of my systems (server and about 60 clients) to Mountain Lion, hoping for fixes to profile manager, but so far the results are not encouraging.
This weekend I'll probably try going back to Workgroup Manager for policy deployment. I imagine that's why Apple left WGM alive in 10.8 --- they know PM is problematic. Which ***** and is a bit despicable if you think about it.
I've long bemoaned how Apple can be a great hardware maker, but a lousy lousy lousy software developer. With more money than god, you'd think someone would take Apple (and let's throw Google in there too) and shake them by the shoulders and say "DUDES! Get your act together on the software!" But instead they use their customers as never-ending beta (and often alpha) testers, jeopardizing the enterprise and education environments that trust them. Sheesh. Needed to vent.
Please post any additional findings you may come across re: profile management. Have you found useful discussions elsewhere? Forget about finding anything official from Apple in the way of help. That's another thing... oh, well, I'll stop here.
Added note: Before going back to WGM, I'll issue via ARD a Unix command to the clients to delete all profiles. sudo profiles -D from this thread: https://discussions.apple.com/message/19515980#19515980
Thanks for the workaround. I was having this same problem but with the user profiles. My users name was their first and last name and I had applied an alias of just their first name. it worked fine with Lion but always failed with mountain lion. As soon as I removed the alias the user profiles started to work.
Thanks for the help
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.
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
Still strugging with deploying settings for messages
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?
Instead of trying to use the payload variable, would it be better to setup a user payload for messages settings? 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?
>>> 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.
I've noticed strange behavior with pushed smtp setting as well
deleting manual or pushed mail settings doesn't seem to remove the smtp settings
especially if your moving from manually configured mail smtp setting to pushed
were the setting are unchanged
eg delete manually configured mail - settings, mail contacts delete mail account
push out same mail account via PM
check mail settings - old manually configured smtp is still there along with pushed smtp setting
sometimes the pushed smtp setting is mixed in with the manual smtp settings
sometimes smtp is disabled yet everything still functions
sometimes no smtp settings at all yet mail still fuctions
I've tried deleting the smtp setting then deleting the profile and pushing the profile out again
resulted in no smtp setting at all, mail still functions
same behavior with ios 6.01
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:
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.