Tiny Deathstars of Foulness

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.

April 6th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , ,

I have covered Apple Configurator in a couple of different articles already. But one question I’ve gotten a number of times is how to do automated enrollment of iOS devices into an MDM solution, such as Profile Manager. Each device that gets enrolled into Profile Manager will require a Trust Profile (installed under the Profiles tab of the MyDevices portal) and an Enrollment Profile (installed under the Devices tab of the MyDevices portal). The Trust Profile requires about 3 or 4 taps to install and the Enrollment Profile requires about the same. The best way I’ve seen for doing automated enrollment is actually to do semi-automated enrollment. Basically, each device gets the Trust Profile deployed in a profile, likely alongside an SSID that the wireless network users will use for actual enrollment. I usually advocate a temporary network according to how complicated the standard wireless network is (e.g. if you use certificates with 802.1x then during enrollment your device won’t necessarily be a supplicant).  Apple Configurator can very easily provide a Trust Profile and the SSID. Should take about 3 minutes worth of work if you have an existing Profile Manager deployment (if you don’t, see this article). Chances are, many will want their devices tied to a user account. For example, if you use Payload Variables at all, then you’ll need a user associated with a device at enrollment time in order to expand the Payload Variables into short names, email addresses, etc. Therefore, I would recommend deploying a web clip for the enrollment site, along with a Trust Profile and the SSID access to the enrollment network. This makes enrollment 4 taps, a username and a password. This will give users a customized ActiveSync environment, password policies, restrictions, VPN, web clips, as many SSIDs as you care to deploy, etc. To setup an enrollment environment for users, we’ll first need to download the Trust Profile. To do so, I usually just log into the MyDevices portal of Profile Manager from the computer running Apple Configurator, by first visiting the https://<nameofserver>/MyDevices URL. Here, click on the Profiles tab. Click on the Install button for the Trust Profile entry, which pulls the mobileconfig file from if the URL were This URL redirects to an administrative page. When the download is complete, Apple Configurator will open automatically as installing Apple Configurator changes the default application for .mobileconfig files from System Preferences to Apple Configurator. Once downloaded, close and then reopen Apple Configurator. Once re-opened, double-click on the Trust Profile that was just installed. The General screen shows information about the profile. This profile can easily act as a Trust profile. But we also need the device enrolled in a wireless network that can be used to access the Profile Manager server. Click on WiFi, click Configure and add the settings for your network. We’re also going to add a link to enroll the devices using the MyDevices portal. Click on Web Clips and then enter the name that you want the user to see in the Label field and the link to the MyDevices portal in the URL field. Finally, we don’t want users prompted with petty SSL errors. This server doesn’t have a publicly signed certificate. Click on Credentials and note that the Trust is already added. We will also grab the certificate for the server from Keychain and click the plus sign to add another certificate. Import the one exported from the Keychain.  Then click on Save and you’ll have a good Trust Profile. Next, we’ll need to export the Enrollment Profile as well. To do so, go to the Profile Manager portal again and click on the Enrollment Profile entry in the sidebar. Uncheck the box to restrict devices (unless you’ve imported all the devices for your environment into Profile Manager) and then click on Download and the Enrollment profile is downloaded to the client. Quit and re-open Apple Configurator. The Enrollment Profile is now listed in the Profiles field. Next, click on the checkbox for the Trust profile and then click on Prepare. On the iOS device you’ll then see the the enrollment process. Tap on the Install buttons until the profile is enrolled. One would think that the device would then be able to be enrolled automatically. You can Enroll manually by logging into the My Devices portal (using the Web Clip) and clicking on the Enroll button and following the default buttons presented to users. You can also email Enrollment Profiles, text them or install them via iPhone Configuration Utility. To also install the enrollment profile and complete the entire enrollment process, just click that other checkbox in Apple Configurator. Now, the concern in doing so would again be that you don’t know which user is associated with which device, taking Payload Variables out of the equation. Leaving the fields that you might otherwise place those into blank simply allows for user input when that part of the MDM profile is run.

April 2nd, 2012

Posted In: iPhone, Mac OS X Server

Tags: , , , , , , , , , ,

Profile Manager allows you to leave certain fields that are user-centric blank and it will prompt at the time that the profile is installed for the blank information. These are usually user-centric fields, such as short name and password. You can also create a profile in Profile Manager for each user you want to setup mail, Exchange, iCal, Address Book and other services that are tied to a specific user. You can enter the username for each and leave the password blank and the user will be prompted for the password but have the username filled in. And then there are payload variables. Note: Before we get started on Payload Variables, it’s worth noting that many did not work well prior to 10.7.3, most notably %email%. Profile Manager provides a number of ways to configure accounts and settings on iOS based devices. When a user logs in, the user’s name, email address, title, phone number and both the short name and GUID of the user’s account are able to be substituted using variables. These variables have a % in front of and behind the name of the variable, making them easy to identify when looking at accounts. These can easily be put into a profile’s payload. When a user logs in the contents of the payload variable are replaced with the information for the account that logged in using the /MyDevices page in the web enrollment interface. When the enrollment profile is downloaded to the device, the variable is substituted with the user’s information from directory services (for user payloads) or from the device itself (for device payloads). Using payload variables is a really straight forward process. First, create a profile by logging into the Profile Manager web interface (the name of the server followed by /ProfileManager. When prompted, provide the username and password for an administrative account. Click on a group or user who you would like to configure a profile for. From the profile screen, select the payload that you’d like to configure. Enter the variable into the field(s) you’d like the substitution to occur in. For example, here I’m using a variable everywhere currently possible. Note: You can wrap the variable with other text. For example, if you enter then for a user of cedge the variable would expand as, useful in doing Exchange configurations. Variables available for use include user and device variables. These user variables are as follows:
  • %email% – The email address (the EMailAddress attribute)
  • %first_name% – The first name (the FirstName attribute)
  • %full_name% – The full name (the RealName attribute)
  • %guid% The guid (the GeneratedID attribute)
  • %last_name% – The last name (the LastName attribute)
  • %job_title% The job title (the JobTitle attribute)
  • %mobile_phone% The mobile number (the MobileNumber attribute)
  • %short_name% The short name (the RecordName attribute, typically the name of the account )
The device variables are as follow:
  • %BuildVersion% – Full OS version on the device
  • %ICCID% – ICCID (from the SIM card)
  • %IMEI% – IMEI (International Mobile Equipment Identity)
  • %OSVersion% – Common version number of the device’s OS
  • %ProductName% – Product name
  • %SerialNumber% – Serial number
  • %WIFIMAC% – MAC address of the WiFi interface
There are also 802.1x variables, which include the following:  
  • %AD_ComputerID%
  • %AD_Domain%
  • %AD_DomainForestName%
  • %AD_DomainGuid%
  • %AD_DomainNameDNS%
  • %AD_KerberosID%
  • %ComputerName%
  • %HardwareUUID%
  • %HostName%
  • %LocalHostName%
  • %MACAddress%
  • %SerialNumber%

March 26th, 2012

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , , ,