DeployStudio 1.7.3 updated from build 160401 to build 160404 to address Active Directory binding issue
Following the release of DeployStudio 1.7.3, I discovered and reported a problem with the Active Directory binding to the DeployStudio folks.
To address the issue, they released a new version of DeployStudio but didn’t change the version number from 1.7.3. Instead, the new DeployStudio 1.7.3 has a different build number:
- DeployStudio 1.7.3 build 160401 – released April 1st, 2016
- DeployStudio 1.7.3 build 160404 – released April 4th, 2016
If you have already installed DeployStudio 1.7.3, I recommend checking to see which build you have installed. If needed, upgrade both your DeployStudio server and DeployStudio boot sets to DeployStudio 1.7.3 build 160404.
For more details on identifying the different builds of DeployStudio 1.7.3, see below the jump.
As part of the release of DeployStudio 1.7.3, DeployStudio is now using an unsigned configuration profile to manage binding to an Active Directory domain for Macs running OS X 10.11.x.
This undocumented change currently appears to apply only to Macs running OS X El Capitan. Earlier versions of OS X are still being bound to AD using Apple’s dsconfigad tool. For more details, see below the jump.
As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:
- Unbind the Mac from the old AD domain
- Bind the Mac to the new AD domain
- Migrate the user’s data from the old AD domain to the new AD domain
Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.
I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.
With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:
- Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
- Potential for human error was minimized
- Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.
For details, see below the jump.
From time to time, Apple will release a custom build of Mac OS X to support a new Mac model. A current example is the Mid 2013 MacBook Airs, which were released after 10.8.4, but before 10.8.5. Since they have hardware that wasn’t accounted for in the standard 10.8.4 software, they’re running a custom build of 10.8.4.
Mac App Store 10.8.4 build number: OS X 10.8.4, build 12E55
Mid 2013 MacBook Air 10.8.4 build number: OS X 10.8.4, build 12E3067
While the Air’s custom build should run fine on older 10.8-compatible Macs, the Mid 2013 MacBook Airs aren’t able to run from the 10.8.4 build currently available from the Mac App Store.
In the event that you need to reinstall OS X on a Mac that needs a custom build, Apple’s solution is to use Recovery HD or Internet Recovery to download and install the correct version of OS X for that Mac. However, if your network connection is behind a proxy server, you may not be able to connect back to Apple while booted from Recovery HD, or be able to boot from Internet Recovery.
To help address this, you can use DeployStudio and OS install packages created by createOSXinstallPkg to help address situations where you can’t use Apple’s Recovery, but still need the ability to install custom builds of Mac OS X. See below the jump for the procedure.
When new software appears, Mac admins need test boxes that match their standard configuration in order to verify that the new software doesn’t adversely affect anything in their environment. In the past, this has usually meant that admins needed to either have an available test box, or go find one when they needed to test something.
The advent of good virtualization solutions meant it was easier to build test boxes without needing additional hardware, but getting the VM to match your standard could take some time and effort.
In VMWare Fusion 5.x, VMWare added NetBoot support for virtual machines running Mac OS X. This proved to be an enormous boon to Mac admins who used NetBoot to help set up their machines: They could now build VMs using the exact same processes that were used to build their users’ Macs. They could also leverage tools like createOSXinstallPkg to set up template VMs with either the latest available OS X installer from the Mac App Store or custom builds of OS X that ship with new hardware.
See below the jump for an example of how you can leverage VMWare’s NetBoot support, createOSXinstallPkg and DeployStudio to set up a new Mac VM with a factory-fresh install of OS X Mountain Lion.
As a follow-up to Greg Neagle’s unveiling of createOSXinstallPkg, a installer package-based tool for deploying Mac OS X 10.7.x and 10.8.x, I wanted to do a sequel to my earlier post on installing OS X using DeployStudio. Using packages created by createOSXinstallPkg, you can use DeployStudio to do an automatic clean install of Mac OS X 10.7.x or 10.8.x and correctly create the Recovery HD partition. See below the jump for the procedure.
As previously described, you can use DeployStudio and InstallLion.pkg to clean install Mac OS X 10.7.x on a Mac. For those who need the same capabilities to install Mac OS X Server 10.7.x, you can use the same methodology to build a workflow that installs Mac OS X Server, assuming that you have access to a Mac Mini Server.
If you do have access to a Mini Server, you can download an InstallESD disk image using Apple Internet Recovery using the procedure described here at AFP548.com. The downloaded InstallESD.dmg will include all of the needed packages to install Mac OS X Server. Once you have that all-important disk image, see below the jump for the procedure.