stevehp

As you've found out you need to run the devices through the prepare tab with just a wireless settings profile then switch over to the Supervised Tab and apply the MDM profile. When the MDM profile doesn't apply it's 99.9% the fact that it doesn't have a network connection to the MDM server. About 2% of the time you might need to wake it up before the wireless connection grabs an IP from DHCP. Brimstone is also correct that if you're MDM solution doesn't have a commercial trusted cert assigned to it you also need to push out the Trust Profile at the same as the MDM Profile as it contains the self signed certificate for the server. With DEP FYI students and or faculty will need to be privy of the schools wireless password(s). For most that shouldn't be an issue, but for groups that guard that password with there life that's another issue. For us at least that will probably just mean an open ssid during our "enrollment period" at the start of the school year. However if these are shared devices and you are not in a 1:1 then DEP isn't the workflow you should be utilizing, for that you need to stick with Configurator. Also keep in mind that once you're in DEP the devices cannot be managed or and or used at all with iTunes or Configurator due to the activation changes made to the device.

I would suggest the same as MicrodigitUK and check that push notifications can be received in our environment. This link >> Push Diagnostics will help you easily confirm that. Hopefully it's available on the UK Mac App Store. I wish you luck Profile Manager for me is a bear to keep running smoothly. It's very cranky most days. The last several weeks we've been having internet issues and it's not been fun, active tasks that pile up into the thousands, no pushes and it takes several refreshes to actually load the administration portal. I'm dumping it for Puppet or localmcx or another MDM provider.

If you haven't already you need to create Open Directory groups in Profile Manager then nest Active Directory groups within that. Beware of Profile Manager though it's resource hungry and it does not scale well. Don't deploy more then 50-100 clients with or you'll be in my shoes with nearly 1700 macs and it takes ages to load or even push settings on a Mac Mini Server with 16gb of ram. You need something more robust like Puppet, Casper or plain old MCX if you want better scalability.

Here are some Apple KB articles about the issue OS X: Improving login times for clients joined to Active Directory domains ending in ".local" and Login and directory binding delays on systems joined to an Active Directory domain ending in ".local" Essentially having a .local domain conflicts with Apple's Bonjour protocol which uses .local . Other things that cause problems in integrated environments are DNS issues and network glitches. Before going 1:1 we tried a golden triangle setup with a .local domain and ran into issue after issue. Wasn't worth my time to keep supporting that so it was abandoned in favor of separating our Windows and Apple networks in two. Thinking about blowing out both setups and combining them again next year we'll see though.

Upgrade servers first then clients. If you push out mcx settings from an older version of server you might have some mismatched settings that work and others that don't because they have been deprecated. Like the others have said only computer level mcx preferences are pushing out of 10.9 server. An MDM server should be investigated for the future. The other thing to consider is that if you use the Software Update server 10.6.8 server or even 10.8 server can't serve updates to 10.9 clients. 10.9 will remain free i.e. not a limited time offer. Just make sure your Macs are supported.

Drivers, they're a b*tch. Even if the hardware supported Mountain Lion and you have an already built Mountain Lion image it wouldn't boot because the OS gets forked with new hardware until the next point release comes out. We aren't upgrading until the next school year. Our printer drivers, servers, and a host of other things would need to fall into line before we upgraded. This sped up OS release schedule might just do me in. At least there is a good chance future releases won't cost us thousands of dollars in licenses. Hardware will be the money sink then. I have upgraded on my personal Macs and a couple of my "off-network" work computers. They all seem to be coping with it. Need to watch it with MCX if the server or client has a minor timeout or the network is slow you'll get a dialog box telling you that the machine is fetching Managed Preferences. According to Apple it's by design, but if my users see it they might think they did something to the computer and will send it my way.

In some instances a pram reset might help. Sounds a bit left field but pram resets often cure the oddest of problems. As far as going straight into the local admin account that sounds like someone changed the automatic login setting under Login Options. You can restrict that FYI from Workgroup Manager.

If you aren't copying anything manually to the User Template or allowing Deploy Studio to do it then it's most likely the System keychain in /Library/Keychains/ that's giving you problems. I won't get into which one is better argument. The internet is filled with mac sysadmins that go back and forth with each other about it. The work up front to package software so that activation and setup procedures don't bug users seemed daunting to me, but in the end I can just plug those packages into Munki or if need be into my image workflow. It works great for me, but I won't crusade for it since sysadmins need to make there own minds up about this particular subject. Profile Manager was a major pita in Lion, got better in Mountain Lion and much better in Mavericks. You need to have a machine with plenty of ram and the highest spec processor you can get. It's a major resource hog, and it's not exceptionally great to contend with in large deployments. I have right around 1200 devices enrolled into your Profile Manager instance and it crawls some days.

How are you creating client images? If they are of the golden master variety (i.e. booted image with software preinstalled) then your user template has been poisoned and contains the login keychain from your booted image. If you were to use a tool like instaDMG or AutoDMG or Apple's own System Image Utility they create non-booted images that don't contain poisoned user templates. If you are primarily a Windows shop then SCCM would be a good choice, but if your Mac PC to Windows PC ratio leans toward the shiny variety then an MDM like Casper or Meraki (free!) would be a better choice. I personally use a myriad of pay and FOSS tools. For user and group management I use the OSX Server.app. For computer level client settings I use Profile Manager. For user and group level settings I use Profile Manager, Munki, and for any remaining MCX settings I use Workgroup Manager. To deploy software I use Munki. Imaging is a mixture of an instaDMG image and Deploy Studio to image the clients. I'm on the other side of the pond so unless you want to come out to the American Midwest that's the best I can do to describe our current mac environment.

While it was updated for use on 10.9, Workgroup Manager uses managed client or MCX to push out computer or user level preferences. Since 10.8 MCX has been deprecated i.e. being disassembled and no longer updated as mdm's such as Profile Manager are more flexible for sysadmins since the settings are "pushed" to the client rather than the client pulling them from the server (which involves logout/login, or restarts to refresh). FYI computer level policies using MCX still work. User / Group level settings are broken because of the deprecation I mentioned above. So in short WGM was updated simply so that a 10.9 client could manage 10.8 or 10.7 servers. User / Group management should be done in Server.app, WGM has a tendency to corrupt the kerberos database. It's either you start working with Profile Manager or another mdm or you use foss tools such as Munki, mcxtoprofile, Puppet, etc.. for osx client management. We have been coming down on staff hard if they upgrade to 10.9. I've blocked the upgrade through the app store so the link they click goes nowhere.

FYI just saying you purchased the OS still isn't kosher in the eyes of Apple. In Apple's legal eyes OSX can only be installed on Apple hardware and OSX can be virtualized only on Apple hardware. If by just bought meaning less than 4-5 days then you probably ended up with Mavericks and not Mountain Lion of which those instructions were for. You sure you have the correct OS?

From a gui perspective you only have two choices a standard user and the full bones administrator. There are some options though. Mac OS X 10.7 / Lion – First look at /etc/authorization usage | mattsmacblog mattsmacblog | Notes of a Mac Sys Admin The two links above are for a blog written by a mac sys admin that has taken upon himself to use the /etc/authorization file and tweak it so standard users can still be so, but have unfettered access to certain System Preference panes and Software Update. iTunes is a tricky one though, it can both be updated through software update as well as within the app itself so I don't know if issues might arise if he were to attempt the update through iTunes. Or... if you have some spare time you can setup and run Munki. The server doesn't need to be a Mac just an ordinary web server, but you will need a Mac to administer the other aspects of it besides the serving of the software. The user will be presented with a GUI (Managed Software Update) that is intuitive enough for a newbie to operate. The best part is the user doesn't need administrative rights to install the software you pushed out as it runs the installers at the root level. It can also be configured to dish out Apple Software Updates from either Apple themselves or from an internal SUS and those can be installed by a standard user.

Correct. System settings such as login window banners, time server, software update, etc. should be set for computer groups. Settings such as of course app restrictions, dock, system preference panes should be in the user group realm. Some can cross over as well such as printing which in a lab setting can be set on the computer level and in other instances at the user group level. If you set your users login shell to none instead of /bin/bash it wouldn't matter much if terminal.app was still allowed through your mcx app restrictions. They can open the app but the prompt to run commands won't display.

Where they logged in to the user accounts in question when the command was sent? Application access mcx settings should be set on the user level not the computer level. What you should do is remove the cached user account from a machine. If it has locally stored files just choose the second option when you delete the user from System Preferences. Then delete the users cached mcx folder in /Library/Managed Preferences/"user.here". Then login to the account again and see if your app access settings get applied properly.

I use it for our 1:1 program at my district. It's a love hate relationship. The biggest problem I have with it is it's such a resource hog. It eats ram and swap like a kid eats candy on Halloween. Aside from that it works just fine settings get pushed, the service has never gone down, and it's been trouble free aside from the beach balls I get when it's running slowly. I intended to drop it for next year though. We have over 1200 devices enrolled in it currently and while it will hold much more I think I need to look at purchasing more licenses for Casper or delve into Puppet for management. Not sure how you had your virtual machines configured but open directory and profile manager require two cpus to function and not break into a million pieces. Open Directory Requires 2 CPUs | Krypted