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

Theoretically, but since you applied mcx to that account or computer or the combination of both it's probably not refreshed yet. Add a new account that in the group you have your test teachers in and see if you still get app restrictions. Check out this Apple KB article as well Managed Client: How to flush cached settings .

It worked great for me. Did it return this on all of the computers or just a select few? If you know the name of the printers on the clients you can run lpadmin -x printername and that will work the same as this script except that this script deletes all existing printers. What OS versions are you running? Hopefully no more than two and nothing below 10.6 otherwise you're setting yourself up for more headaches.

Use the unix toolbar button and paste this in: #!/bin/bash ## Reset Printer System lpstat -p | cut -d' ' -f2 | xargs -I{} lpadmin -x {} echo "Printer System Reset" exit 0 Tell it to ran as the user root rather than The current console user. Then save it in the "sidebar" and give it a catchy name like Reset Printing System and drag and drop clients into the entry on the sidebar and hit the play button. Since the script has an echo command each client should return back "Printing System Reset". I don't do this often and the script isn't my own doing so I can't guarantee it will work 100% so test, test, test before deploying it in the wild.

WGM and Profile Manager printers are big pita. Firstly using either results in the Nearby Printers menu item showing in the print dialog of an application. That pretty much is an open field day for printing. Like above it also causes zombie queues on clients i.e. the queues on the server were renamed or removed all together, but the client still thinks they're active up to the point when a user tries to send a print job to it. The only way around it is to create a script or send a terminal command using ARD that will delete all queues on a client then either refresh MCX or logout and log back into a client to retrieve the proper queues. At the moment because I'm still neck deep in deployment and smoothing out server and application issues, so printing is taking a lower priority. I'll have to at this point resort to using Profile Manager to deploy printers and deal with the consequences later on. What I'm planning on doing is delivering printers using Munki and tie them a mostly defunct open source quota system called Pykota. That way I can sufficiently lock down color queues and stop students from printing to other buildings or printing to their hearts content.

Workgroup Manager or Profile Manager will allow you to manage this. Scheduling can be done for what days and when to power off and power on. They do need to be bound with authentication for this to work i.e. a computer object needs to be present in Open Directory. Third Party MDM's might allow you to do this as well.

I see outwardly that all of my staff are adults, but inwardly in some instances I'd judge them on the same level as a first grader. Entitlement issues, bad attitude when the word no is breathed in their direction, etc, etc... Printing is an area we I would put major restrictions on staff. With the exception of one that has gone paperless the rest print like it's going out of style and if nothing comes out guess what I get to do?

In the other thread you have for Google Chrome I showed you how to type in rather than select a folder or application from a chooser. Any user be it student or staff should at the very least have launch permissions for /Applications , /Library and /System/Library . As far as Preference Panes goes for staff the only panes I would lock out are: Sharing, Network, Energy Saver (they like to stop ours from sleeping), Startup Disk, and maybe Time Machine. Locking out the Print & Scan preference pane is a bold move, teachers, especially mine go three shades of crazy if they can't print something or change a setting that involves that pane. We're a 1:1 district and we started off by giving staff a laptop and giving them full tilt local admin rights with nothing locked down. This year I've restricted some things, but they as local admins(OD Mobile Accounts) can still install applications, change settings or do whatever they want as long as the settings I set don't get modified. If they do change one of those settings they get to visit me, and I give them a polite yet blunt talk about their place in the scheme of things and what they should and should not be doing with school owned equipment. Since it appears your staff don't have local admin rights simply giving them access to the above directories isn't at all risky since the /Applications directory is permissioned as such so that only accounts with (local)admin rights can modify it's contents.

I do this with our students Google Drive accounts using Profile Manager. I use the Mail payload and I prefill everything from the account description to the email address. I use variables to dynamically fill in the email address, username, and the Display name. A list of usable variables is here . You can also use Workgroup Manager although it's a little more kludgy. You have to select the group or particular user you want to provide the preference to and switch from Overview to Details on the Preferences screen and locate Mail-10.6 then add the keys and variables using that. It's fairly straightforward, but if you need help I can walk you through it.

Yes and no. It's just like AD Users and Groups on Windows Servers you have to remove them from their current group completely then add them to the next consecutive group i.e. from 1st to 2nd. You can goto Groups and select all of the members of the group hit the minus button on the right hand side of the window hit save and move over to the next group and click on the plus button and add your students into the group. I get around this mess by lumping students into graduating years so for instance all of my 2013-2014 school year Sixth Graders would belong to the 2020 Students group then I'd nest that out further by buildings then finally nest all of my grad year groups into a group called All Students. I can apply all of my policies to this group, but I can always apply building level policies using my building groups. Then finally when my 2014 students leave at the end of this school I can just prune the students and the 2014 Students group. I can add comments or keywords to my individual users so that when it comes time to prune I can search by the keyword 2014 and highlight or select all and delete in bulk. One thing I might add as I've said in your other thread about the old tired WGM when you create a new user it mangles the Ker

Ensure you also have in your allow list: /Library /Applications /System/Library You can also try putting in the root of the user library folder as well, it's ~/Library .