Moving Managed Preferences to Profiles

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 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.

MacTech InDepth In New York

I have been added as a speaker at MacTech InDepth in New York. If you haven’t signed up yet, and you work with Mac OS X Server then you should really check out the sessions that have been planned:
  • The Elephant in the Room: The New Lion OS X is out, now what? There are a lot of differences to contend with between Lion and Snow Leopard. Now with the new Mountain Lion update, what changes can we expect to see? We discuss the differences in advanced services, GUI simplicity, and Apache management GUI’s. We help you understand the updates in the new OS and make the transition easier. We go over the new updates of Lion over the Snow Leopard server.
  • Setting solid foundations: To truly grasp the power of Lion, you need to set up solid foundations. We go over minimum requirements for internet DNS, and tackle router tricks. We discuss open directory and what it was used for.
  • Mobile Device Management 101: Apple’s IPCU/Apple Configurator: Mobile Device Management is vital to businesses, large or small. We have an extensive overview of profile manager and how you can use mobile device management on OS X. For those still using Snow Leopard, we go over your options and discuss the possibility of using third parties as a solution.
  • DNS, Ahh, run away, run away: In this session, we tackle DNS and break it down and show how simple it is to work with. We go over how DNS works and cover different components such as internet DNS and internal DNS.
  • Administering a Server with just We show you how to use and control administrative programs. For the services, we go over Address Book, iCal, iChat, and Mail.
  • Web Administration of OS X Server : Web Admin on Lion Server versus Snow Leopard is covered, dealing with the differences and how to use each system effectively. On Lion server, we cover using FTP without a GUI.
  • Going old school, using the old tools: After getting used to Snow Leopard we go over the major differences between Snow and Lion and how you can handle the transition. We go over server admin and what is still left in the program and why it has been left.
  • Deployment Part I: Tools & Concepts: In tools and concepts we learn that there aren’t stark differences between Lion server and Snow Leopard. NetBoot, NetRestore and third party tools are covered; we talk about how NetBoot works and what the differences between NetBoot and NetRestore are. Along with this we cover Network configuration requirements and using software update server.
  • Deployment Part II: DeployStudio: DeployStudio is covered in-depth; we cover creation techniques and management techniques.
Overall, this represents a nice, fast way to update your skills to allow for managing Lion Server and to get up to speed with those new to the platform. One thing I like about the session list is that it goes beyond the stock server implementation and looks at DeployStudio, MDM and other important topics not purely server oriented. I hope to see you all there!
These vagabond shoes, are longing to stray Right through the very heart of it – New York, New York

2012 Penn State MacAdmins Conference

Don’t let the theft of the Paternoville sign fool ya’, State College is as safe as ever. That is, until a bunch of Mac guys descend on the Nittany Lion Shrine. Yes, it’s that time of the year again when Mac guys from around the world (and yes, all of the speakers are male) descend upon Pennsylvania State University from throughout the Big 10 and beyond to discuss the Penn State mascot, the Nittany Lion. Actually, it’s a mountain lion, so we can’t discuss it quite yet at that point, but we can talk about a slightly bigger cat: Lion.

Lion deployment, scripted tools, Munki, InstaDMG, Puppet, migrations, “postPC,” PSU Blast, Dual Boot, NetBoot, reboot (just threw that in there because it sounded like it fit, but I’m sure much rebooting will be done anyway) and even iOS. Oh, and don’t forget lecture capture, launchd, monitoring, scripting, Boot Camp via BitTorrent (wait, what?), Damn Logs, Subversion (long live git), IPv6 (long live IPv4), DeployStudio (long live the French), Reposado (long live the mouse), Luggage, Casper (long live Minnesota!), ARD (long live the friggin’ App Store), troubleshooting, FileVault (long live Howard Hughes’ legacy), Tivoli (long live that 1984 video), Munki (crap, I already said that) and even iPad (which runs iOS I think). Overall, the lineup is superb and looking at it, I am honored to be giving a session on Lion Server amidst all the cool stuff going on around me. I’m very impressed with the number and level of speakers and very excited to be a part of it. I’m also excited to be participating with Allister Banks, a cohort from 318, who will be giving talks on InstaDMG and Munki. Overall, it is sure to be a great conference and I look forward to hopefully seeing you all there if I don’t get arrested at the airport for wearing University of Minnesota socks. Speaking of the Big 10. Did you know there are 12 teams in the Big 10? Did you know the Big East now has teams in Idaho and California? Did you know that the Big 12 has 10 teams? Did you know that the Pac 12 has 4 teams in 3 states that don’t touch the Pacific ocean? What does all this mean? No, it does not mean that we will discuss basic arithmetic and geography at the conference; however, we might show off some apps that can help the math professors at the member institutions of these higher education conferences teach these basic subjects a bit better. Disclaimer: I went to the University of Georgia and am required by having done so to poke fun at other conferences whenever it is possible. Having said that: how many Georgia programmers does it take to change a light bulb? … … They can’t, it’s a hardware problem! OK, terrible joke. So here’s a picture of the Georgia mascot chomping down on an opposing (Auburn) player. Seems like I’m going through football season withdrawals all of a sudden… Point of all this, go to the conference. It’s sure to be a hoot, and I’m sure there will be plenty of talk about football, er, I mean Mountain Lions, er, wait, I mean Mac OS X and iOS!

DeployStudio From the Command Line

Recently I did a little article on importing computers into DeployStudio lists. I got an overwhelming number of email requests to go a step further and look at importing computers into DeployStudio from the command line. I’m guessing lots of people want to bolt some middleware onto their mass deployment tools (can’t say I blame ’em). The first thing to know is that DeployStudio stores most everything in standard property lists. This includes workflows, computer groups and computers. When you install DeployStudio you selected a location to place your database. For the purpose of this example, we’re going to use /DSDatabase as our location. Within this directory is a folder called Databases. In this folder you’ll see ByHost, which stores each computer in a property list that is the computers MAC address followed by .plist. For example, if my computer has a MAC address of 00254bcc76fa then 00254bcc76fa.plist would be the file that houses information about my computer in DeployStudio. In the ByHost folder is an additional property list called group.settings.plist. In here is the information about the computer groups that you have created. In the Databases folder there is also a directory called Workflows, which houses all of your workflows. These can be seen in the example folder structure here. When DeployStudio is started, it dynamically loads the items from the property lists to compile its database. You can add additional property lists easily, but when you do you will need to restart DeployStudio each time (or each batch). There are a number of keys in the property lists, with many of which mirroring data that can be imported using the DSImporter.csv template in my previous article. These include:
  • dstudio-auto-disable: Used to disable the DeployStudio Runtime following the initial imaging
  • dstudio-auto-reset-workflow: Used to disable the automate checkbox for the workflow
  • dstudio-auto-started-workflow: Used to assign a workflow. When populating this via the command line you will need to specify the ID of the workflow (remember that the Workflows are in property lists in the Workflows directory. Each has a key for ID, which is what would be used here
  • dstudio-group: Adds the client to a computer group
  • dstudio-host-ard-field-1: Fills in the Info 1 Computer Information field from ARD
  • dstudio-host-ard-field-2: Fills in the Info 2 Computer Information field from ARD
  • dstudio-host-ard-field-3: Fills in the Info 3 Computer Information field from ARD
  • dstudio-host-ard-field-4: Fills in the Info 4 Computer Information field from ARD
  • dstudio-host-interfaces: Arrays to configure static IP addresses for each NIC
  • dstudio-host-new-network-location: Sets up a Location in the Network System Preferences pane
  • dstudio-hostname: Sets the HostName
  • dstudio-mac-addr: The MAC address of the client
To add a computer, you can use plistbuddy or just the defaults command. In the following example, we’ll continue to house our DeployStudio Repository in the /DSDatabase directory and write in only the computer MAC address and whether it will receive a network location, which from what I can tell are the only required keys:
defaults write /DSDatabase/Databases/ByHost/00254bcc76f2 ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:76:f2″;}’
Next, we’re going to add another key to set the first ARD field for a different computer when it is imaged. Your database (ERP, SIS, etc) kicks off the following script, which also puts the intended user’s Active Directory user name in the first ARD field:
defaults write /DSDatabase/Databases/ByHost/00254bcc53ab ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:53:ab”;”dstudio-host-ard-field-1″=”cedge882″;}’
Once you have done so, open System Preferences and then click on the DeployStudio preference to restart the DeployStudio Server. You can also restart the DeployStudio Server using launchctl with the com.deploystudio.server daemon. Once restarted, your new computer (or computers if you ran both examples) should be listed in DeployStudio. Happy scripting!

Importing Computers Into DeployStudio

DeployStudio has the ability to import a csv file that is populated with the MAC address and a few specific settings. This allows you to prepopulate the database with the names that you want each machine to have. If you purchase a lot of machines from Apple then you can get a list of MAC addresses, or, you can use a bar code scanner to scan them as you’re unboxing. If you have a list of MAC addresses (en0), then you will need to format them in a very specific manner. Here, I have included a sample csv file with the data that goes into each field, which I have name DSImporter.csv. Once you paste the data that you’d like into the csv, provide the computer names (these can be pasted or compiled using formulas). Once done, save and then open Deploy Studio Admin. From here, click on Computers and then (as you would with iTunes) click on the plus sign (+) and create a new computer list (this step is optional, but I prefer to always import into computer lists, just in case something goes wrong, especially with my first import). Once you have created the computer list, you should see a screen similar to the following. Next, click on the Server menu and select Import. Now browse to your csv file and then click on the Import button. When the import is complete you will see a screen informing you as such. Click on the Done button to complete the process. You will then see your computers listed in the database and should see the names that you assigned them listed as well. You can now set a workflow item in DeployStudio for Reconfigure system with computers database content (shown below). This will set the name (and any other fields you decided to use) from the spreadsheet that you imported into the computer list. Once you have your computers in a group, you can also set a default workflow for them for their first time imaging, by clicking on the name of the group and then clicking on the Automation tab at the bottom as you can see below. Here, you will set the workflow to run and optionally set the computer to not have a default workflow moving forward or just be disabled so users can’t accidentally reimage their computers later. If you don’t have the MAC addresses for your computers ahead of time, you can use the Hostname option instead. This will enable you to enter the computer name that you would like to use moving forward into the DeployStudio Runtime at imaging and then have it stored in the DeployStudio database, where it can be used to build future workflows or even be exported and imported into the Open Directory computers. Overall, the computers and groups in DeployStudio Admin can be used to design more and more complex imaging sequences and to provide much of the scripting logic that a number of organizations need. Beyond that, JAMF, FileWave and a few other solutions offer even more logic and even more features or a little shell scripting can take you a really long way.

DeployStudio: Rename a Volume with Host Name

DeployStudio has the ability to rename volumes as part of a standard workflow. These are typically set to something like “Macintosh HD” (the default) or “Computer Lab” or something like that. But what if you wanted to name the volume something unique to a given computer, which makes it easier to keep track with what you are doing across a number of servers? You could create a workflow for each computer and change the hard drive name for each to something unique; but that would be tedious and pollute your list of workflows, likely resulting in accidentally running the wrong workflow at times. Instead, you could look at a really simple script in most cases (according to how complicated your logic for assigning names would be). To rename a volume, you can use the diskutil command along with the rename option. You would then list the existing name followed by the new name that you’d like that volume to have. In the case of DeployStudio the initial name of your boot volume might be “Macintosh HD” and to change the name to something like “Computer Lab” you would then use a command like:
diskutil rename Macintosh HD Computer Lab
It might then be logical to use a host name to rename a computer. Therefore, we could replace Computer Lab with the hostname command like so:
diskutil rename Macintosh HD `hostname`
However, this ends up showing the fully qualified name. Therefore, we could replace hostname with an scutil query for the ComputerName:
diskutil rename Macintosh HD `scutil –get ComputerName`
This would result in the name without all the .local, etc. But if you ran this as part of a DeployStudio workflow, you would end up calling the hard drive for all of your machines localhost. This is because the hostname or ComputerName will be queried from the DeployStudio set that you are booted to for running the DeployStudio Runtime. Luckily, DeployStudio has a number of variables that it can use in scripts. One of them is DS_HOSTNAME, which pulls the ComputerName being applied to the system at imaging. This means that if we were to rename the hard drive of the computer from Macintosh HD to the DS_HOSTNAME, you could use the following script:
diskutil rename /Volumes/Macintosh HD $DS_HOSTNAME
Now, one might think to oneself, couldn’t I just put $DS_HOSTNAME in the field for renaming the hard drive (part of a workflow). I tried it a number of different ways and couldn’t get it to work (in parenthesis, quoted out different kinds of ways, in different types of brackets and combinations of the above). If anyone knows of a way to use a variable in a GUI field within DeployStudio, let me know (I am guessing it can be done).

Changing the Background for DeployStudio

DeployStudio has a very nice background image that it uses by default for the NetBoot set. But you can customize the image that’s used if you wish to have something more, well, customized. Simply mount the DeployStudioRuntime sparseimage file from the DeployStudioRuntime nbi file that was created when you elected to generate the NetBoot set. You can do so by simply opening the nib file and then double-clicking on the sparse image. From here, browse into the System and then the Library and then the CoreServices directory in the NetBoot set. From here find the DefaultDesktop.jpg file. Replacing that file will replace the background that is used when you boot to the NetBoot set. The higher resolution the better!

DeployStudio: Creating a New Master Image

Once you have been using DeployStudio for a time, you’ll invariably end up creating a new master image.  This is a hot topic this summer, given that Apple will be releasing Mac OS X 10.6 later this year and many people integrating DeployStudio want to make sure that they can manage the solution themselves during the subsequent updates.  Provided you have been leveraging all of the best in package based imaging this might be a relatively small file, or if you are using a monolithic image for distribution it might be a fairly large file.  Either way, DeployStudio makes it fairly straight forward to create a new master image.  To do so, first get your imaging station ready using similar techniques to how you have created your master images (known in DeployStudio as Masters) in the past.  Then follow these straight forward instructions:
Creating a Master Image from an Imaging Station Using DeployStudio
Creating a Master Image from an Imaging Station Using DeployStudio

Creating a Master DeployStudio Image

Once you’ve completed the setup of a DeployStudio server you’re going to want to use it to start imaging systems. In most cases you’ll want to start off with DeployStudio Admin, found with it’s brethren in /Applications/Utilities. When you first open DeployStudio Admin, you’ll be asked for a server address, username and password. Go ahead and log in as one of the (or the) user that you setup as an administrative account during installation, enter the address of the server (followed by the port you used with the DeployStudio Assistant – you can always rerun the assistant if you need to). By default the connection information should be available in the drop down menu to make this process a little easier. Now you should see the following options:
  • Activity – View DeployStudio events
  • Computers – Lists computers by MAC Address to be imaged and import information
  • Masters – Images currently located in the repository, where all of the images are stored.  In order to populate the Masters list use the DeployStudio Runtime.
  • Scripts – Central repository for scripts to be run during workflows
  • Workflows – Configure the steps required to perform an installation
    If you are migrating to DeployStudio from NetRestore you’ll be happy to learn that DeployStudio stores data in the same format that NetRestore stored data. The format of the .csv file should be (per line with no colons present in the MAC address):
    The DeployStudio Runtime is used to play workflows. The workflows that can be played could include a workflow to capture an image or one to put one onto your desktops, as would be typical for mass deployment. You can run the DeployStudio Runtime manually from Mac OS X as well, which allows you to test the workflows that you have built to restore (play) images onto a local Firewire or USB drive. Let’s look at using the runtime to create a master (base image) from a source volume. Open the DeployStudio Runtime and authenticate into your server. Then click on the Create a master from a volume button and click on the Play button. Next, provide the specifics for creating the image. Select a source hard drive to base our image on. Place a name for the image in the Image Name: field.  Set your image Type to Read Only for now and then enter the format for the file system of the image (for OS X machines, this will pretty much always be HFS+).  Once you’re ready, click on the Play button to begin building an image of the hard drive.  DeployStudio will automatically clean out the unique information for the machine (ie – LocalKDC) and build the image when played.