For many iOS deployment projects, iTunes is used as the primary deployment vehicle for the devices. iTunes can be used to “Backup” and “Restore” an iPad, similar to how you image desktop and laptop computers.
The actual deployment process is straight forward. First we’ll create a backup in iTunes. Then we can deploy the backup using the Restore option within iTunes. Provided the backup is encrypted, the Restore option will maintain the maximum amount of data available. For example, if a device has been activated then the fact that it has been activated is maintained across a restore. As are the applications that are installed on the device.
Create iTunes Backup
To Create an iTunes Backup:
Restoring with iTunes
To Restore an iTunes Backup:
krypted August 9th, 2012
Over the years, the terms Magic, Golden, Triangle, Augments, Directory, Domains and Active have given the administrators of Mac OS X environments fits. So when you think about using Active Directory to manage iOS devices through the Profile Manager service, built into Lion Server, you may think that it’s a complicated thing to piece together. You may remember those days when you had to manually craft service principals because xgrid wouldn’t play nice with Acive Directory, or you might think of twisting augmented records to support CalDAV. But you’re gonna’ have to forget all that, ’cause getting Profile Manager to talk to Active Directory is one of the easiest things you’ll do.
Before we get started, architecture. Every Profile Manager instance is an Open Directory Master. Apple has included a local group in Mac OS X Server called Profile Manager ACL. Users and groups from any directory domain that can be viewed in dscl can be added to this group. Adding objects to this group enables them to authenticate to the MyDevices portal but not administrate. Kerberos isn’t really used here, nor are nested groups. You’ll apply policies directly to Active Directory groups in Profile Manager. For many long-term Apple administrators, this paragraph is all you need to read. If not, please continue on.
To get started, first set Profile Manager up, as shown in a previous article I did. Once configured, verify that Open Directory or local clients can authenticate, bind to Active Directory.
Bind to Active Directory
From within System Preferences, click on the Users & Groups System Preference pane and click on Login Options. Then click on the Edit… button for the Network Account Server. From here, click on the plus sign (“+”) and enter the domain name into the Server field.
Once bound, you will see the server listed. At this point, if you try to authenticate to the MyDevices portal as an Active Directory user, you will be able to authenticate, but you will not have permission to enroll devices. To log in, access the web service at the address of the server followed by /MyDevices (e.g. https://mdm.pretendco.com/MyDevices).
Provide the user name and password to the service. The Active Directory users are unable to access the MyDevices service.
Click on Logout and we’ll fix this. There is no further configuration required for the Active Directory groups to function properly in regards to how they work with the server. However, we will need to open Workgroup Manager and nest some groups. You might think that you’d be doing something all kinds of complicated, but notsomuch. You also might think that you would be nesting the Active Directory users and groups inside Open Directory groups, given that you have to enable Open Directory in order to use Profile Manager. Again, notsomuch. To nest the groups, browse to the local directory and then then click on the com.apple.access_devicemanagement group.
Drag the user or group from the menu into the list of members and then click on the Save button.
Now log in again using the MyDevices portal and you’ll be able to Enroll. From within Profile Manager (log in here as a local administrator), you’ll see all of the users and groups and be able to apply policies directly to them by clicking on the Edit button for each (the information isn’t saved in the directory service on the server, but is cached into the directory service client on the client when using Mac OS X 10.7, Lion based clients).
Moving Mac OS X Management From MCX
You keep hearing that you need to move some of your managed preferences to profiles (or Profile Manager in most cases), but you can’t really think about that until you get Profile Manager integrated with Active Directory, can you? And getting those pesky iOS devices working with Active Directory style policies has been on your radar, but really, who has time?
Profiles then have a few distinct benefits over Managed Preferences (MCX) for some, which we’ll look at through the lens of Profile Manager. The first is that they’re instant. You can make a change to a profile on a device enrolled in an MDM service and you instantly see the changes on the client (most profile settings that is, not all), rather than having to log the client out and then back in. You can also wipe and lock devices and the interface is easier (I mean, no nesting thankyouverymuch).
But there are a few drawbacks as well. You can’t cluster Profile Manager, so there are some benefits to using 3rd party services in a move to profile based management. You also manage settings using the Always option, rather than being able to use the Once or Often settings. You can use custom property lists, though and importantly, MCX is used to actually implement most of these profiles on client systems, so those skills you’ve been honing for managing Managed Client workflows will not be totally lost in the transition. Overall, I had initially thought that management by profile would be much less granular than management via managed preferences, but I’ve found ways around any issues and have found it’s actually much easier and works as reliably as dual directory or Active Directory based managed preferences worked.
krypted April 3rd, 2012
Tags: Active Directory integration, Contact your system administrator., directory services, Groups, integration, Lion, Logout, Mac OS X Server, Magic Triangle, MyDevices, Open Directory, profile manager, You do not have permission to access the page you were looking for.
The Enterprise iPhone and iPad Administrator’s Guide is now shipping (and rapidly moving up in Amazon’s rankings)! There have also been a couple of sightings in Border’s.
Apress also sent out a press release and an email blast regarding the book in the past week. So, feel free to buy it using the link below! 🙂
krypted December 9th, 2010
When it comes to system imaging, the most important aspect is to be methodical. If there is an error, the last thing you want to do is try 3-4 different things to see if one fixes the problem. Bust out the scientific method and find out exactly what the problem is. Because you’re about to make a change, en masse, that is going to have a resounding impact on the ecosystem that is your environment. And the smaller the change, or the light the touch, that you make then the less likely you will be to introduce a support nightmare in some other part of the enterprise.
Many environments have long since moved into a change controlled environment. Post imaging, when desktops are deployed to users, any changes often need to be approved. Then those changes often need to move through stages, such as change management, release management, etc. The lighter the touch of these changes then the quicker it should be able to progress through stages because the impact that the change will have is typically easier to quantify.
So then you might ask what constitutes whether a touch is “light.” Look at it this way: one of the lightest touches is to not introduce change anywhere. Assuming that you have mobile homes, network redirects or roaming profiles, simply test logging into a different machine as the same user. Isolate whether the problem is with a user profile. Then check managed preferences, or GPOs. Verify that the problem is not with a policy. Remove policies from the equation (keeping in mind that there are policies for users, groups, computers, various groupings of computers, OUs, etc. Assuming that an issue (incident) is not policy nor profile, only then look to introduce change, or maybe instead of introducing change, consider simply re-imaging a host. That can, at times, be the lightest touch of all, because you are just reverting to a known good state.
But if you want to be more scientific, and isolate the issue down to exactly what the problem might be, then you might just be kinda’ like me. You need your users to have maximum uptime, which means you need to strike a balance here. Maybe swap machines so that you can isolate the error while allowing the user to continue working… If the issue persists after re-imaging then you have a fun one. At this point don’t do more than one thing at a time, and consider rebooting between tasks. Once you isolate your error down to a specific task that resulted in a fix then find a way to complete that task programatically. If you can complete a task using WMI, PowerShell, shell scripting, python, whatever then you can wrap it into an installer and easily push it out to other systems on either an as-needed basis or en masse.
But the lighter touch philosophy isn’t just for imaging and mass deployment/integration. It is a resounding philosophy across all things that need troubleshooting: isolate the problem by being methodical, down to the exact file, registry key, property list or whatever (thus and then find a way to accomplish the task that resolved the issue programatically). That will enable you to make the lightest touches possible and especially when troubleshooting en masse, result in the least amount of labor to be spent on problem management.
krypted August 21st, 2009
Posted In: Consulting
Mac OS X clients can be integrated with Novell’s eDirectory out of the box for the purposes of authentication. Beyond that, I often see questions about other integration options with eDirectory and Mac OS X online and I almost always point people to this article, by Randall Saeks, which is a great document to get you started. Given that the article was written in 2006, a little more work may be needed to get specific features of Leopard working (to be specific, schema extensions), but it’s a great starting point overall. But Novell isn’t targeting just Mac OS X clients. They also provide a document on getting started with Linux integration (obviously SUSE but also RHEL).
krypted May 9th, 2009