If you’ve been following my postings for the past few weeks you may have noticed that I’m putting the pieces together for a strategy to transition existing managed preferences in environments to profiles, most notably those managed using Lion Server’s Profile Manager as more than just a mobile device management tool, but also as a computer management tool. To put the articles into a bit more order, let’s look at the order that you’d likely use them to actually do an integration:
Not all of these will be applicable to every deployment, but the tasks covered are worth knowing how to do. Using Profile Manager and migrating the actual managed preferences from existing tools into Profile Manager I saved for last (after all, you need your infrastructure in place to do this). Here, I’m just going to look at Workgroup Manager and manually move each preference from Workgroup Manager into Profile Manager. To get started, I usually like to open a screen with Profile Manager and another with Workgroup Manager, lining them up side by side. This allows me to quickly and easily cut-copy-paste between the two. I also like to be very orderly, choosing to step through the Workgroup Manager list in order, moving each option I have selected in Workgroup Manager over to Profile Manager.
I usually start with user groups, then do computer groups, then look for specific computers I may have applied policies to and finally specific users that might have policies attached to them. The screens, by default, for my initial user groups, would look as follows (where there are some managed preferences in Workgroup Manager but not yet in Profile Manager):
Right off the bat, if you’re going in order of those displayed in the Workgroup Manager GUI, you’ll notice that there aren’t any listed for Applications in Profile Manager. This is because Applications, Media Access and System Preferences are located in the Restrictions payload for Mac OS X in Profile Manager. Click on it and click on Configure to enable the payload. Rather than go through each preference and each setting of each preference, suffice it to say that most are there. In some cases, you won’t see one, such as disabling Front Row, but you’ll have a cool new one, such as disabling AirDrop in its place.
The workflow is a little different in some places. For example, in Workgroup Manager, you can run the Workgroup Manager application on a computer that is not the server and easily add applications and printers to the preference that are not actually installed on the server. Annoyingly, because Profile Manager is a web application, you need to put the .app bundles and install the printers on the server in order to push them out through Profile Manager. While this caused some initial heartache, I just ended up taking the app bundle, copying it to the server temporarily and then adding it, whether the application was installed or not. Printers are easy enough to install on servers as well.
The Classic managed preference is pretty much no longer needed, so it has been removed. Finder and Universal Access are also gone in Profile Manager. But this doesn’t mean you can’t manage them. Just as you could manage custom preferences using the Details tab, you can manage custom preferences using the Custom Settings option as well. Simply open the Custom Settings payload and then use the plus sign to create each preference domain that you would like to manually configure. Click on the Upload File… button to import a property list manually and then delete the items that you don’t want getting pushed to clients (seems similar to how you did things in Managed Preferences, right?). Another managed setting that is missing from Profile Manager is Software Update. Here, we’ll add it by looking at the details in Workgroup Manager and then duplicating the settings in Profile Manager.
You can do this for any of the missing objects as well as any third party software. For example, we’ll click the plus sign (“+”) to add a preference and then enter com.microsoft.autoupdate2 into the Preference Domain field and HowToCheck as a key (String) with a value of Manual. This would disable Microsoft’s automatic updates so we can manage them through our patch management solution.
The biggest change in moving to profiles and Profile Manager is the fact that you no longer have the option to manage settings using the Once Often and Always settings we grew to love in Managed Preferences. There are trade-offs. Such as the fact that you can have many of the settings instantly updated on clients, wipe devices, etc. The way you remove an Always profile is to remove the payload. For those still needing Once and Often, you can stick with Managed Preferences for a bit longer, but you might want to start considering ways of not accessing those manifests. In exchange you can centrally push out SSIDs for wireless networks, automatically configure clients for Exchange (not the password) if you’re using Mail, iCal and Address Book, deploy certificates, configure password policies and even perform some fairly delicate 802.1x foo, without touching a script.
There’s definitely going to be some stir over the fact that, as with iOS, centralized management via Profile Manager is an opt-in experience. Users can remove their enrollment profile as they wish. Of course, if you’ve hidden the Profiles System Preference pane then they might have a problem getting rid of it, but get rid of it they may. Therefore, it’s worth considering a few strategies for dealing with that. One I like is automatically unbinding clients that are not listed in the devices table of the Profile Manager database. Another is to send ninjas to their house so they may be pelted with shurikens (1d6 of damage each, btw, so don’t throw too many). It’s also worth noting that data doesn’t always disappear with profiles in Mac OS X the same way it does with iOS and that profiles are a Lion and above experience, not working with Snow Leopard and older operating systems.
Whichever strategy you take with migrating to profiles, it’s worth starting to think about and test this new type of user experience now. Of course, if you have a 3rd party patch management tool, such as the Casper Suite, that allows for local managed preferences, you’re likely better off deploying policies through there. If not, then don’t feel rushed, as Managed Preferences are still how Profiles deploy their payloads to clients. However, the means with which you have been deploying Managed Preferences may be changing over the next few years, so it’s a good idea to start looking at this now in order to be prepared for future releases.
krypted April 6th, 2012
When planning to migrate from managed preferences to profiles, one of the important aspects to consider is automated enrollment. One of the more important aspects of automating a traditional managed preferences environment is to automate the binding to directory services. You do not bind to Profile Manager; however, you do enroll devices. Much like binding computers to Lion Server’s Open Directory (by default), certificates and host names are important aspects of the enrollment process.
Much as with local managed preferences, management via profiles can be done through the command line and without any involvement from a centralized source. I had written an article awhile back on using profiles from the command line.
You can also instead enroll devices into Profile Manager. Previously, I had looked at configuring Profile Manager. Manual enrollment in Profile Manager is the same as enrollment from iOS. But instead of using Apple Configurator to automate enrollment, you’ll use your existing imaging solution for automated enrollment of Mac OS X based clients. Therefore, we’ll use DeployStudio as an example for automating enrollment at imaging time.
To get started, you’ll need a functional DeployStudio configuration. You’ll also need a functional Profile Manager configuration. From within Profile Manager, click on the plus sign (“+”) in the lower left corner of DeployStudio and click on Enrollment Profile. Then click on the New Enrollment Profile entry that was created and click on the Download button to download the profile onto the server (when it attempts to install, simply click cancel to cache it to your ~/Downloads directory).
Click in the drop-down menu in the upper right hand corner of the screen and then click on Download Trust Profile. This will download the Trust Profile for the MDM solution to the client (when it attempts to install, simply click cancel to cache it to your ~/Downloads directory).
Next, drag the cached profiles into the ConfigurationProfiles directory of the DeployStudio repository. Now that you have the profiles that will be required for automated enrollment, open DeployStudio Admin (if it was open before, close it and then re-open it once you have copied the profiles to the DeployStudio repository). From within DeployStudio, we will create a new workflow, here called “Deploy Lion with Enrollment”. We will then choose to restore a target volume and automate the task.
Next, click on the plus sign (“+”) to add a new workflow item, sliding the task selection screen out automatically.
Next, drag the Automatic Enrollment Task item into the workflow. Once present, choose Previous task target from the Target Volume field. Next, choose the enrollment profile in the Enrollment profile field. Also choose the Trust profile that you just downloaded from the Trust profile field. Finally, check the Automate box and save your workflow.
Finally, we’ll add a Configure task to set the hostname (note that your workflows may already be far more flushed out than mine here. Click on Save and then test the workflow.
Once booted, if you are automatically enrolled then the process was a success. You should be able to see the device in Profile Manager.
krypted April 4th, 2012
Tags: Command line, Deploy Studio, Enrollment, Lion, lion server, local MCX, Mac OS X, Mac OS X Server, Managed Preferences, mdm, mobile device management, move from MCX to profiles, profile manager, profiles
The Mac OS X App Store was released earlier this month as a part of the Mac OS X 10.6.6 update. The App Store, with over 1,000 applications (including a couple of server tools), allowing people to download and install applications on Mac OS X computers without needing to understand how to click through the screens of a standard package installer, drag applications from disk images into the /Applications folder or basically how to do practically anything except for click and provide a valid credit card number. As with the App Store that debuted with the iPhone, the App Store for Mac OS X is clearly aimed at residential customers, but being that these computers are used in enterprises around the world, the impact to managed environments cannot be discounted. I decided to do plenty of testing and reading before I wrote this up, so hopefully you’ll find it helpful, if not very timely.
The first and probably most important aspect of the App Store to most who are charged with managing large numbers of Mac OS X computers is that only administrative users can install software from the App Store. This little fact makes the App Store itself a non-issue for most enterprises, who do not make typical users administrative users. Because only administrative accounts can download and install applications, there is little risk created from leaving the App Store on client computers.
Applications installed from the App Store can only be deployed into the /Applications directory. These applications are owned by System, with read-only access given to the wheel group and everyone else. No ACLs are used, so while a single user purchases the software any user on the system can open it. If you copy the software to another computer then you will be prompted to authorize it using the same Apple ID that was used to purchase it.
When an administrative user purchases an application, they are not prompted for a system password, only an App Store password, which uses the same Apple ID used for the iTunes Store and the iOS App Store. Application updates are handled using the familiar Updates screen borrowed from the iOS App Store, which includes the nifty Update All option.
As far as controlling the user’s experience with the App Store, there are a few options. Administrators can remove the App Store application bundle (which can be replaced any time) from /Applications. Administrators can also black list the application using managed preferences/parental controls. A Dock item is added by default and can be removed as well. Removing both the Dock item and the Application bundle will then remove the App Store menu item from the Apple menu. You can also block the hosts at apple.com, which includes itunes.apple.com, ax.itunes.apple.com, ax.init.itunes.apple.com, albert.apple.com, metrics.sky.com and possibly gs.apple.com. These will communicate over ports 80 and 443, according to the operation being used. There is also a launch daemon at /System/Library/LaunchAgents/com.apple.storeagent.plist that should be unloaded and likely removed if you’re going to outright disable the App Store. However, the only real way I would personally disable is using a managed preference.
There is also a property list file for the App Store that can be used to manage the application in Workgroup Manager in ~/Library/Preferences/com.apple.storeagent.plist. However, there isn’t much that can be done here at this time.
Because applications are tied to users, when a user moves computers you will want to backup and restore the applications for the user. To do so, here’s the captain obvious article for ya’: http://support.apple.com/kb/HT4482.
The App Store is not a replacement for a good patch management system. Software distribution cannot be managed centrally using the App Store and Software Update Server in Mac OS X Server does not currently cache applications from the App Store. Trying to think of a way to shoehorn the App Store into a software distribution system such as JAMF’s Casper Suite, Absolute Manage or FileWave is just asking for a world of pain, so let’s pretend that we never brought it up. If your organization isn’t able to license one of the aforementioned products, check out Star Deploy from http://www.stardeploy.com/StarDeploy/Home.html or munki from http://code.google.com/p/munki. Finally, I think that Apple’s done a great job with the App Store for a version 1 release. I think that my wife loves it and that over time if Apple chooses to do more with it then great; otherwise, all of the options we’ve been using, from the installer command on, are still at our disposal.
krypted January 18th, 2011
Deleting the contents of the /Library/Managed Preferences directory is definitely one way to refresh your managed preferences cache in Mac OS X, but there have been commands specifically designed to clear the cache for each version of Mac OS X. By OS, these include the following:
There are a number of other ways to go about this. If you have some that you use that I did not mention please feel free to add a comment.
krypted December 17th, 2010
Posted In: Mass Deployment
A short contribution I made to afp548 on the new mcxrefresh command in Snow Leopard. Check it out here.
krypted September 12th, 2009
krypted August 4th, 2009
krypted July 31st, 2009
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):
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
krypted May 22nd, 2009
Yes, you can apply an MCX against a local account easily using the -mcximport and -mcxexport dscl extensions. Simply setup the MCX like you want it for a managed account using Workgroup Manager and then from the interactive dscl environment do a -mcxexport <Path to account> -o <filename> and then copy the file to a target system. Then, on the target system, do a -mcximport <path to account> -o <path to same filename>.
Then test! Happy policy making!
krypted September 16th, 2008
Posted In: Mac OS X Server