Export data from Open Directory for migrating users and groups

Before we have this conversation, I want to give you some bad news. Your passwords aren’t going to migrate. The good news is that you only do directory services migrations every decade or two. The better news is that I’m not actually sure you need a directory service in the traditional sense that you’ve built directory services. With Apple’s Enterprise Connect and Nomad, we no longer need to bind in order to get Kerberos functionality. With MCX long-dead(ish) you’re now better off doing policies through configuration profiles. 

So where does that leave us? There are some options.
  • On Prem Active Directory. I can setup Active Directory in about 10 minutes. And I can be binding Mac clients to it. They’ll get their Kerberos TGTs and authenticate into services and the 90s will be as alive on your server as they are in Portland. Here’s the thing, and I kinda’ hate to say it, but no one ever got fired for doing things the old reliable way. 
  • OpenLDAP. There are some easy builds of OpenLDAP to deploy. You can build a new instance from scratch on a Mac (probably a bad idea) or on a very small Linux box. This is pretty easy, but to get all the cool stuff working, you might need some tweaking.
  • Appliances. I’m already working on an article for installing OpenLDAP on a Synology.
  • Microsoft Azure Active Directory. If you’re a primarily Microsoft shop, and one that is trying to go server-less, then this is probably for you. Problem is, I can’t guide you through binding a client to Active Directory in Azure just yet. 
  • Okta/Ping/other IAMs. Some of these can act as a directory service of sorts ( https://help.okta.com/en/prod/Content/Topics/Directory/About_Universal_Directory.htm ). As with Azure, you’re likely not going to bind to them (although Nomad has some interesting stuff if you feel like digging into that).
  • A hosted directory service provider (Directory as a Service) like Jumpcloud.
There are probably dozens of other options as well (please feel free to add them in the comments section of this article). No matter what you do, if you have more than a dozen or two users and groups, you’re going to want to export them. So let’s check out what that process looks like. The easy way to export data is to dump all of the services out with one quick command:

sudo slapconfig -backupdb ~/Desktop/slapexport/

This process produces the exact same results as exporting Open Directory from the Server App. To do so, open the Server app and click on the Open Directory entry. From there, click on the cog-wheel icon and choose the option to Archive Open Directory Master. 

When prompted, enter your directory administrator (e.g. diradmin) credentials.

Once you have authenticated, provide a path and a password to export the data.

Now you’ll see a sparse image in your export path. Open it to see the backup.ldif file.

That’s the main thing you’re looking for. The ldif file can be imported into another openldap system, or once you have an ldif file, you can also get that over into csv. To help with this, I wrote a little ldif to csv converter and posted it here.

Finally, you could export just users or groups, or specific objects from the Server App.

That option is more built for importing into other macOS servers, but if you’d like to try, click on Users in the left sidebar and then click on Export Users from the cog wheel icon towards the bottom of the screen.

Then select what to export and where to export the file to. 

You can also repeat this process for Groups, if needed.

Is Imaging Dead In OS X?

I love answering a question with a question. Is asr still in OS X? Is NetInstall still in OS X Server? Can OS X still NetBoot? Does System Image Utility still work? The answer to all of these is yes. Therefore, the answer to “Is imaging dead” is clearly no. Is it on its way out, maybe. Debatable. Is it changing? Of course. When does Apple not evolve? What have we seen recently? Well, the rhetoric would point to the fact that imaging is dying. That seems clear. And this is slowly coming out of people at Apple. The word imaging is becoming a bad thing. But, as a customer recently asked me, “what do you do when a hard drive fails and you need to get a system back up”? My answer, which of course was another question was “what do you do when that happens with an iPad?” The answer is that you Restore. What is the difference between an Image and a Restore? Yes, I meant to capitalize both. Yes, I realize that’s not grammatically correct. No, I don’t care. It’s my prose, back off. But back to the point. What is the difference between the two? Am Image can have things inserted into /Applications, /Library, and even /System (since it’s not booted, it’s not yet protected by SIP). An Image can have binaries and scripts automatically fire, that Apple didn’t bake into the factory OS. On an iPad, when you Restore, you explode an .ipsw file onto disk that can’t be altered and acts as an operating system. The difference here is that one is altered, the other isn’t. Additionally, iOS ripsaw files only contain drivers for the specific hardware for a given device (e.g. one for iPad Mini and another for iPhone 6). But, you have pre-flight and post-flight tasks you need to perform. Everyone understands that. Think about automation via profiles. You can run a script with a profile. You can apply a profile at first boot. You can install a package (the future of packages is IMHO more debatable than the future of images) and a .app with a profile. These might take a little more work than it does with a NetInstall and System Image Utility. But then, it might not. You’d be surprised what’s easier and what’s actually harder (for now) with this new workflow. Complexities are more logistical than technical. So, Imaging is dead, long live Restoring? Arguably, any older workflows you have will be fine for some time. So any good article has a call to action somewhere. The call to action here is to try to subtly shift your deployment techniques. This involves implementing a DEP strategy where possible. This involves putting the final nails in the coffin of monolithic imaging. This involves moving to as thin an image as possible. This involves (I can’t believe I’m saying this) de-emphasizing scripting in your deployment process. This also involves completing the move that you’ve hopefully started already, from MCX to profile or mdm-based management. What else do you think this involves? Insert running commentary below!

Using The Profiles Command In Yosemite

You can export profiles from Apple Configurator or Profile Manager (or some of the 3rd party MDM tools). You can then install profiles by just opening them and installing. Once profiles are installed on a Mac, mdmclient, a binary located in /usr/libexec will process changes such as wiping a system that has been FileVaulted (note you need to FileVault if you want to wipe an OS X Lion client computer). /System/Library/LaunchDaemons and /System/Library/LaunchAgents has a mdmclient daemon and agent respectively that start it up automatically. To script profile deployment, administrators can add and remove configuration profiles using the new /usr/bin/profiles command. To see all profiles, aggregated, use the profiles command with just the -P option: /usr/bin/profiles -P As with managed preferences (and piggy backing on managed preferences for that matter), configuration profiles can be assigned to users or computers. To see just user profiles, use the -L option: /usr/bin/profiles -L You can remove all profiles using -D: /usr/bin/profiles -D The -I option installs profiles and the -R removes profiles. Use -p to indicate the profile is from a server or -F to indicate it’s source is a file. To remove a profile: /usr/bin/profiles -R -F /tmp/HawkeyesTrickshot.mobileconfig To remove one from a server: /usr/bin/profiles -R -p com.WestCoastAvengers.HawkeyesTrickshot The following installs HawkeyesTrickshot.mobileconfig from /tmp: /usr/bin/profiles -I -F /tmp/HawkeyesTrickshot.mobileconfig If created in Profile Manager: /usr/bin/profiles -I -p com.WestCoastAvengers.HawkeyesTrickshot There is a nifty new feature in the profiles command in Yosemite where you can configure profiles to install at the next boot, rather than immediately. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure): profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up. As of OS X Yosemite, the dscl command has extensions for dealing with profiles as well. These include the available MCX Profile Extensions: -profileimport -profiledelete -profilelist [optArgs]
-profileexport -profilehelp To list all profiles from an Open Directory object, use 
-profilelist. To run, follow the dscl command with -u to specify a user, -P to specify the password for the user, then the IP address of the OD server (or name of the AD object), then the profilelist verb, then the relative path. Assuming a username of diradmin for the directory, a password of moonknight and then cedge user: dscl -u diradmin -P moonknight profilelist /LDAPv3/ To delete that information for the given user, swap the profilelist extension with profiledelete: dscl -u diradmin -P apple profilelist /LDAPv3/ If you would rather export all information to a directory called ProfileExports on the root of the drive: dscl -u diradmin -P moonknight profileexport . all -o /ProfileExports Note: Provisioning profiles can also be managed, frequently using the lower-case variant of installation and removal (e.g. -i to install, -r to remove, -c to list and -d to delete all provisioning profiles). Provisioning profiles can also come with a -u option to show the uuid. Finally, the -V option verifies a provisioning profile. In Yosemite we have a few new options, such as -H which shows whether a profile was installed, -z to define a removal password and -o to output a file path for removal information. Also, in Yosemite it seems as though if a configuration profile was pushed to you from MDM, you can’t remove it (fyi, I love having the word fail as a standalone in verbose output):
bash-3.2# profiles -P _computerlevel[1] attribute: profileIdentifier: 772BED54-5EDF-4987-94B9-654456CF0B9A _computerlevel[2] attribute: profileIdentifier: 00000000-0000-0000-A000-4A414D460003 _computerlevel[3] attribute: profileIdentifier: C11672D9-9AE2-4F09-B789-70D5678CB397 charlesedge[4] attribute: profileIdentifier: com.krypted.office365.a5f0e328-ea86-11e3-a26c-6476bab5f328 charlesedge[5] attribute: profileIdentifier: odr.krypted.com.ADD7E5A6-8EED-4B11-8470-C56C8DC1E2E6 _computerlevel[6] attribute: profileIdentifier: EE08ABE9-5CB8-48E3-8E02-E46AD0A03783 _computerlevel[7] attribute: profileIdentifier: F3C87B6E-185C-4F28-9BA7-6E02EACA37B1 _computerlevel[8] attribute: profileIdentifier: 24DA416D-093A-4E2E-9E6A-FEAD74B8B0F0 There are 8 configuration profiles installed bash-3.2# profiles -r 772BED54-5EDF-4987-94B9-654456CF0B9A bash-3.2# profiles -P _computerlevel[1] attribute: profileIdentifier: F3C87B6E-185C-4F28-9BA7-6E02EACA37B1 _computerlevel[2] attribute: profileIdentifier: EE08ABE9-5CB8-48E3-8E02-E46AD0A03783 _computerlevel[3] attribute: profileIdentifier: 24DA416D-093A-4E2E-9E6A-FEAD74B8B0F0 _computerlevel[4] attribute: profileIdentifier: 00000000-0000-0000-A000-4A414D460003 _computerlevel[5] attribute: profileIdentifier: 772BED54-5EDF-4987-94B9-654456CF0B9A _computerlevel[6] attribute: profileIdentifier: C11672D9-9AE2-4F09-B789-70D5678CB397 charlesedge[7] attribute: profileIdentifier: odr.krypted.com.ADD7E5A6-8EED-4B11-8470-C56C8DC1E2E6 charlesedge[8] attribute: profileIdentifier: com.krypted.office365.a5f0e328-ea86-11e3-a26c-6476bab5f328 There are 8 configuration profiles installed bash-3.2# profiles -rv 772BED54-5EDF-4987-94B9-654456CF0B9A profiles: verbose mode ON profiles: returned error: -204 fail

Deploying and Managing Google Chrome: The Rough Guide

The following is a post from the most excellent Nick McSpadden. It is very well written and I am proud that it is the first article published on this site using the new submissions page. Looks like it’s time to change the banner from my Notes from the Underground, er, I mean, Field, to just Notes from the Field!
Greetings! This is a sort of follow-up to my guide on managing Firefox, this time focusing on managing Google Chrome. I’m working on current Chrome version 18 (which just today got updated to 19), and I don’t know for sure how far back this will work, but I think anything higher than v16 properly supports the MCX policies. The good news about Google Chrome is that it supports MCX! Unlike Firefox, which requires specific and somewhat obtuse procedures for managing it (including depending upon an add-on that is independently maintained by a hard working individual), the most important parts of Chrome management can be done with already-existing MCX controls. First let me start off with a link to a very helpful set of information: http://www.chromium.org/administrators That link covers just about everything you’ll need to know about Chrome policies and management, though some of it is buried. I discovered (much to my chagrin) that the Chromium site is much more thoroughly documented that Google’s official “Chrome for Administrators” site. Some important notes about Chrome MCX: all Chrome policies are required to be set to “Always.” They’re like Profiles from Profile Managers – there’s no middle ground. Even if you set it to “Once” or “Often,” Chrome will treat the policy as permanent and prevent the user from changing it. Any policy being managed by MCX in Chrome will be grayed out to user interaction (and there will be a message in the “Options” window about how some settings are being managed by the administrator). So you’re going to have to “Always” manage these settings whether you like it or not. The good news is, there’s an alternative, the Master Preferences. The downside is that the Master Preferences is a “once” option, and doesn’t prevent the user from changing it. It’s a good way to provide default settings without restricting the users’ ability to personalize it later on. More on that later. So, following the Mac Quick Start Guide: (http://www.chromium.org/administrators/mac-quick-start) 1. Inside a fresh copy of Google Chrome is a nice fresh copy of the manifest. Access it here: /Applications/Google Chrome.app/Contents/Resources/com.google.Chrome.manifest/Contents/Resources/com.google.Chrome.manifest 2. Load this manifest into WGM 3. Here’s the full description of all policies in the Chrome manifest: http://www.chromium.org/administrators/policy-list-3 4. There are some particularly important settings that will be relevant to most. Here’s what my plist looks like for a lab computer (no individual users):
  • AutoFillEnabled – False (disables the ability to store autofill information)
  • BookmarkBarEnabled – True (forces the bookmark bar to show up on all tabs, all the time)
  • HideWebStorePromo – True (prevents the web store from trying to sell you things, but does not disable the web store)
  • HomePageIsNewTabPage – False (if you don’t disable this, the homepage will be set to the default Chrome tab page, which opens up the “Most Visited/Apps” switcher)
  • HomepageLocation – URL (even if you set this, if HomePageIsNewTabPage is set to true, this URL gets ignored)
  • PasswordManagerEnabled – False (for lab machines, I don’t want them saving passwords, intentionally or accidentally)
  • RestoreOnStartup – 0 (0 forces it to open the homepage URL on startup)
  • SyncDisabled – True (same reason as Password Manager – I don’t want these personalized at any time).
That gives you a basic setup for most things you’ll need to worry about. If you deploy this, you’ll notice a few problems, though. The first time you launch Chrome, it gives you an undismissable dialogue box asking you if you want to make Chrome the default or submit other info. That’s bad. The above manifest also provides no way to control the auto update mechanism, if that’s something you want to do. This is where the Master Preferences file comes in – http://www.chromium.org/administrators/configuring-other-preferences. By specifying a Master Preferences file, we can load up default preferences for user accounts *when they are created.* Note that the Master Preferences file has absolutely no effect on already existing Chrome profiles – only upon new-user generation does Chrome load this file. It literally copies and pastes the settings in here into the appropriate places in ~/Library/Application Support/Google/Chrome/Default/Preferences. On Mac OS X, the Master Preferences file must be located at: /Library/Google/Google Chrome Master Preferences (yes, really – the file must be named “Google Chrome Master Preferences” with no extension), and must obviously be readable by any user who can launch Chrome (i.e. use 644 permissions). The Master Preferences file is a JSON file that can contain any of the preferences normally used by Chrome. If you want the full list of all possible preferences, load up a default Chrome profile and take a look at the Preferences file I mentioned at the path above. It has everything you’d ever want (and a lot of stuff you probably don’t). To save you some time, here are some important ones you’ll want to use specifically for deploying Chrome: { "homepage_is_newtabpage" : false, "browser" : { "show_home_button" : true, "check_default_browser" : false }, "bookmark_bar" : { "show_on_all_tabs" : true }, "distribution" : { "skip_first_run_ui" : true, "show_welcome_page" : false, "import_bookmarks" : false, "import_bookmarks_from_file" : "/Library/Google/chrome_bookmarks.html", "make_chrome_default" : false }, "sync_promo" : { "user_skipped" : true } } The chromium.org page I linked above goes into a bit more detail about this, but I want to give a quick note about the interaction between preferences and MCX. MCX always wins. Any policy managed by the MCX and also specified in the Master Prefs will always go the MCX policy. In the example above, if I had set “homepage_is_newtabpage” to true, it would still be false because MCX sets it to false, and that policy is always enforced. The really import part is the “distribution” section. “skip_first_run_ui” will get rid of that annoying dialog box that comes up when you first launch Chrome. The “import_bookmarks” option asks the user through a UI dialog box if the user wishes to import bookmarks from another browser. Obviously, we want to suppress that. There’s an option instead to silently import bookmarks from an HTML file. You can create this bookmarks HTML file by setting up the bookmarks the way you want, and then Exporting them in the Bookmark Manager. I place that bookmarks file in /Library/Google/ because it’s already used, but you can put it anywhere. There is, however, a known bug that has now been assigned a milestone and a solver in Chromium’s bug list – the “import_bookmarks_from_file” is actually ignored if the “skip_first_run_ui” is set to true. So right now, you can’t silently import your bookmarks in. The “sync_promo” item doesn’t seem to be necessary if you disable Sync in the MCX settings above, but since MCX policy always wins over Master Prefs, there’s no penalty or downside to including it. Note that your JSON syntax has to be perfect for this to work. Any incorrect comma placements, and it simply ignores your master prefs file. If you find that your Master Prefs isn’t loading up as expected, run Chrome from the Terminal with the debug log turned on to see what’s happening: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome –enable-logging –v=1 This places a file called “chrome_debug.log” in ~/Library/Application Support/Google/Chrome/Default/ (i.e. default user data directory). The first line will tell you exactly what went wrong with your Master Prefs file. Now, there’s still one more problem here: new tabs open up to the default Chrome “New Apps / Most Visited” switcher page (called the newtab page). Unfortunately for us, there’s no way to change this behavior present in the UI. The good news is, this behavior annoys plenty of other users, and there are a million extensions you can use to get rid of it. More good news, is that you can silently include extensions in your MCX manifest! So simply add this to your MCX settings above (forgive the pseudo XML here, just to indicate type of key): <array> <string>lcncmkcnkcdbbanbjakcencbaoegdjlp;https://clients2.google.com/service/update2/crx</string> </array> This silently forces the install of an extension called “Empty New Tab Page,” and specifies an update URL for it (required, since Chrome autoupdates its extensions too if they come from the Chrome Web Store / Extensions pages). The extension does what you think it does – you get a blank page. There are other extensions for customizing the new tab pages, or anything else, so as long as you get the extension ID (it’s the long block of letters in the beginning), you can load whatever you want in here. There you go! I’ve tested this using Local MCX on my 10.6 and 10.7 machines, and it works perfectly (deployed through Munki as well). On the whole, Chrome is a bit easier to manage and deploy than Firefox, just because it doesn’t require modifying the app itself to do this. Also, the Master Preferences file works for any instance of Google Chrome – even if the users install a copy somewhere other than /Applications. This also does work for Chromium, the open-source version of Chrome. Hope this helps someone.

Deploying and Managing Firefox: The Rough Guide

Another Great Article Submitted From Nick McSpadden:
After working with this for a bit, I’ve come up with a step by step installation process for Firefox 10 ESR + CCK deployment on Mac OS. Firefox CCK Guide – Part I Most of the information about add-ons that you’ll need is in Mike Kaply’s blog: http://mike.kaply.com/2012/02/09/integrating-add-ons-into-firefox/ 1) Install CCK Wizard in Firefox 10 ESR 2) Run and configure CCK Wizard the way you want 3) Save the CCK data into a “CCK” folder anywhere you’d like.  This folder will contain:
  • cck.config
  • cck.xpi
  • xpi/ directory
4) When done, open up CCK/xpi.config 5) Copy the contents of the id=<name> key – this is the name you provided when configuring the CCK addon.  In my example, it is “test-sacredsf-cck@extensions.sacredsf.org”. 6) Rename “xpi” folder into the ID key from Step 5 7) Inside Firefox, create: Firefox.app/Contents/MacOS/distribution/bundles/ 8) Move renamed xpi folder from Step 6 into Firefox.app/Contents/MacOS/distribution/bundles/ 9) Launch Firefox, enjoy CCK! Now, this is means that Firefox needs to be specially packaged and distributed during deployment. While this is easy for first-time deployment, it does mean that future versions of Firefox will also require repackaging. If you want to avoid this, it means you’ll have to change Firefox’s addon scopes. If you’re already repackaging Firefox for the CCK as above, then it isn’t a big deal, use the instructions in Mike Kaply’s blog: http://mike.kaply.com/2012/02/21/understanding-add-on-scopes/ Firefox Changing Add-On Scopes – Part II 1) Make a text file named whatever you want as long as it ends in .js, such as “scopes.js” 2) Add these two lines to the file:
pref("extensions.autoDisableScopes", 0);
pref("extensions.enableScopes", 15);
3) This file needs to be saved in Firefox.app/Contents/MacOS/defaults/pref/ (the blog suggests it should be defaults/preferences/, but for me /prefs/ was already created) 4) Now user scopes are changed to the settings above. However, if you want to avoid repackaging Firefox completely every time an update or a change to your CCK configuration comes out, or you want to have different CCK settings for each user on the system, you’ll need to change things up a bit. One way or the other, you’ll need to change the Addon Scopes, because FF10’s defaults lock out the extra directories. If you don’t want to rebundle/repackage Firefox 10, you can use any script to add in the preferences you need into Firefox.app. You can do it simply with echo:
$ echo -e "pref("extensions.autoDisableScopes", 0);npref("extensions.enableScopes", 15);" > /Applications/Firefox.app/Contents/MacOS/defaults/pref/scopes.js
(obviously double check to make sure the .js file can be read by Firefox, although I didn’t have to do anything for it to work) Doing this allows Firefox to use any of its valid locations for extensions, listed here: https://developer.mozilla.org/en/Installing_extensions In other words, you’ll want to move and rename the “xpi” folder from the CCK Guide Step 6 into this location if you want it to affect all users: /Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/test-sacredsf-cck@extensions.sacredsf.org This unpacked folder (from CCK Guide Step 4) contains the xpi contents:
  • plugins/
  • modules/
  • install.rdf
  • defaults/
  • components/
  • chrome.manifest
  • chrome
  • cck.config
…and so forth. Use this location if you want it to affect individual users only: ~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ (i.e. /Users/…/Library/…) To summarize: I. For an individual user, I’d need to change Firefox’s addon scopes, and I’d need the unpacked xpi contents located here: ~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ II. For all users, but not packaged within the application itself, I’d need to change Firefox’s addon scopes, and put the unpacked xpi contents here: /Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ III. For all users, who will be unable to disable or even see the add-on, inside the Firefox.app bundle itself, I don’t need to change addon scopes. I just need to put the unpacked xpi contents here: /Applications/Firefox.app/Contents/MacOS/distribution/bundles/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ That’s how you get the CCK configured and installed in its various permutations on Mac OS X. I hope that helps anyone who was struggling or thinking about adopting the Firefox 10 Extended release into their deployment strategy, as the CCK is a great tool for preconfiguring Firefox to suit your enterprise’s needs. “But wait!” you might say.  “How do I perform an enterprise-level deployment with this method?”  See my post here for details on incorporating this into Munki: http://krypted.com/mass-deployment/deploying-and-managing-firefox-part-2-working-with-munki/.

Dealing With Profile Manager Conflicts in Lion

Changing OS X Settings for Profiles bound to clients results in Managed Client changes (mcxread shows them) and inserts the info into Managed Client in this order:
  1. User
  2. Computer
  3. Computer Group
  4. Everyone
  5. User Group
The data in the managed client attributes is replaced completely and not per-key. Installing profiles from the command line provides more information as to what is going on behind the scenes. Having said this, in some cases I can get a Provisioning Profile Validation: failed to read CMS (-25257) error when attempting to install the same profile a second time. In other cases it just fails if I try to run verbosely (in those cases it doesn’t ever install at all). For example, if I run a user group profile twice, the command completes. You should be able to use -CP or L to validate whether it ran and to validate whether it was already run. Keeping a good naming convention on the ProfileIdentifier should keep from too many weird conflicts and you can always read MCX to see if it got pushed out, since it’s all just MCX anyway. Troubleshooting conflicts can be a bit tricky. The -v operator should return an exit code that indicates that there is overlapping namespace in the Organization but can cause a null return (in fact -v fails with some combinations outright when it shouldn’t). The “profiles -L” command does show that the profile is installed, so you could check that before running, escaping out the generated ID and .alacarte. Running with a -C shows the profiles for the computer, -P for everyone (btw, running profiles -CPL returns inconsistent results so I’ve been scripting them to run separately). Installing profiles from the command line seems to usually require a log out and log in in order to see the changes. killall dock or killall finder don’t result in the changes, unless they’re coming from MDM, at which point they are instant. Installing profiles from the GUI usually means instant changes though. The above information includes installing profiles. When you have policies being overlaid from Exchange, the most restrictive settings will win and be read granularly. For example, if you have a passcode minimum in a profile and a complexity requirement in Exchange then both would be applied to clients.

Managing iTunes en Masse

iTunes is cool.  But there are some features that many organizations want to limit as when they are used by a large number of people they can become problematic.  Apple allows you to manage iTunes for Windows and Mac OS X clients.  For Windows, there are a number of registry keys that can be used and for Mac OS X there is the ~/Library/Preferences/com.apple.iTunes.plist file, or more importantly the ability to Add the aforementioned file into the Workgroup Manager Managed Preferences.  Once added you will be able to set a number of options to manage, including the following (which are self explanatory for the most part):
  • allowiTunesUAccess
  • disableAppleTV
  • disableAutomaticDeviceSync
  • disableCheckForUpdates
  • disableDeviceRegistration
  • disableGeniusSidebar
  • disableGetAlbumArtwork
  • disableMusicStore
  • disableOpenStream
  • disablePlugins
  • disablePodcasts
  • disableRadio
  • disableSharedMusic
  • gamesLimit
  • moviesLimit
  • ratingSystemID
  • restrictExplicit
  • restrictGames
  • restrictMovies
  • restrictTVshows
  • tvShowsLimit
If you have not been allowing your users to access iTunes because of a specific feature having been abused (ie – Radio) then you can now limit the features of iTunes and therefore allow users to still have access to other features, such as iTunesU and Podcasts.  Considering pushing out a new com.apple.iTunes.plist file?  That could be a little tricky if you want to make sure to preserve any paired devices.  Information about iPhones and AppleTVs can be found in this file, so be careful before you perform a file drop.  If you do wish to push a preference into the file directly, rather than use mcx then consider instead using defaults.  For example, to disable iTunesRadio you could use the following:
defaults write ~/Library/Preferences/com.apple.iTunes disableRadio -bool true

Disabling Dashboard

The other day I saw someone remove the Dashboard icon from the Dock as a way of disabling it entirely.  Probably not the best route.  It’s pretty easy though.  The command to disable:
defaults write com.apple.dashboard mcx-disabled -boolean yes
And of course if you’ve disabled, you might want to turn it back on using this handy-dandy double-negative:
defaults write com.apple.dashboard mcx-disabled -boolean no

Mac OS X Server: Using Open Directory to Control SideBar

Recently I had a scenario where I wanted to disable all of the menu items using an MCX for some NetBoot clients.  To do so, I ended up building a custom MCX.  To do so, first open Workgroup Manager and click on the group in question.  Then click on Preferences and then the Details tab.  Next, click on the + sign and browse to /System/Library/CoreServices.  Next click on Menu Extras and click on the pencil.  Here drop down the Always disclosure triangle and click on the New Key button.  From here, name the key with menu item in question (or create multiple keys) and set the Type to Boolean and the Value to False.  Keys that you can do this with include: