This may help you out...

https://derflounder.wordpress.com/2018/08/15/the-t2-macs-the-end-of-netboot-and-deploying-from-macos-recovery/

That said, your time will be better spent acknowledging that imaging is dead. There's much reward to be had by investing in an enrollment program workflow. There isn't much to miss about imaging once you get over the hurdle.

https://www.youtube.com/watch?v=0j4AxqkwQG4

I realize that I have been banging this particular drum for years now, but 2018 saw many of imaging’s smartest and staunchest supporters finally concede the point in public.

Even if you love imaging, I’d recommend letting it go. Any success in keeping this process alive will be marginal and temporary.

Same from me I’m afraid. The new install workflows, combined with DEP are pretty good. I really wouldn’t spend time working out how to image T2 Macs.

use this and you can just wipe clean, do all updates including firmware and guarantee a nice clean OS. Then use DEP workflow to get what you need. Speaking as someone that only rolled out DEP a couple of months ago it was different and challenging to get set up to work with the business requirements but worth it in the end. Even we have older kit not in DEP that will still be imaged until replaced/dies but that's it. I also build a boot disk that allows imaging or wiping and that works OK for older non T2 devices to get them DEP ready quickly.

another good tool is https://bitbucket.org/prowarehouse-nl/erase-install/

You can create a self service policy scoped to your support staff that installs this app and another self service policy to cache an up to date macOS installer application that it can use.

only works for 10.13.4 and above though, you can use a bootable macOS installer for Macs below this version in the mean time - much quicker than internet recovery.

Yes, it would be great to get a solid process down...but I fear it's a waste of time as it's no longer going but gone..

Set up a DEP Provisioning Process, once the "heavy lifting" is completed and you have the process down. It is a much smoother process than imaging....

I may have figured it out.. all of you "don't image anymore" people will probably disown me, but I'm posting the answer for anybody else that won't let imaging go just yet.

After restoring the image I had to manually delete the (encrypted at rest) Preboot and Recovery Partitions using:
diskutil apfs deleteVolume disk1s2 (deletes Preboot)
diskutil apfsdeleteVolume disk1s3 (deletes Recovery)

Manually create those Volumes again using the "role" identifer:
diskutil apfs addVolume disk1 apfs Preboot -role B
diskutil apfs addVolume disk1 apfs Recovery -role R

Then I had to populate the preboot volume with the boot information.

Get UUID of disk1s1 to setup Preboot need to store that value into variable. the $4 indicates 4th column (spaces count as each column)

diskutil apfs list | grep "Volume disk1s1" | awk {'print $4'}

mount the preboot Volume

diskutil mount /dev/disk1s2

unizp the preboot files

tar -xvf /tmp/DSNetworkRepository/Masters/APFS/Mojave_10.14.2_18C54_v1.0.i386.preboot.zip -C /Volumes/Preboot

Rename the Folder under Preboot to the UDID of disk1s1 (Using variable from grep command)

mv /Volumes/Preboot/%foldername that was extracted% /Volumes/Preboot/%Variable from Grep%

Also Restore the Recovery Partition

mount the recovery volume

diskutil mount /dev/disk1s3

unizp the recovery files

tar -xvf /tmp/DSNetworkRepository/Masters/APFS/Mojave_10.14.2_18C54_v1.0.i386.recovery.zip -C /Volumes/Recovery

Rename the Folder under Recovery to the UDID of disk1s1 (Using variable from grep command)

mv /Volumes/Recovery/%foldername that was extracted% /Volumes/Recovery/%Variable from Grep%

make the drive bootable

sudo bless -mount "/Volumes/Macintosh HD" -setBoot

Verify Boot Info (if desired)

sudo bless -info -verbose /Volumes/Macintosh HD

@jerdill We won’t disown you. If you do what you’ve described, your firmware will. We’ll still be here though. :)

One of the many reasons that “imaging is dead” is that only the macOS installer has the appropriate entitlements to update firmware. When firmware cannot be updated, unexpected operations can occur, and ucertain expected but undesirable operations like potentially failing Secure Boot checks become likely.

You’ve put in some very clever work, but this path is one that will require frequent manual work without support from the vendor. On that basis, it fails a simple cost/benefit analysis in my view.

Until Apple allows orgs to add non-DEP macOS devices to DEP as can be done on the iOS side, people are going to keep this dead horse going.

Impressive necromancy!

@milesleacy - You make a good point about the firmware, At least for now that issue was one of the easier ones to get around. Just extract the firmware.pkg from the installer and run it as part of the imaging process. Some other people had done the work on that when High Sierra came out. It still is valid for Mojave.

Here are a few links for anybody interested in that part.
https://apple.stackexchange.com/questions/301454/applying-mac-firmware-updates-manually
https://www.amsys.co.uk/deploying-firmware-updates-imaging/

@jerdill After installing the extracted firmware package, check the firmware versions. Are they the expected updated versions? I strongly suspect not.

Per conversations with senior macOS technical authorities at Apple, only the macOS installer possesses the entitlements necessary to successfully install these packages. This exact workflow of extracting the package and attempting to install outside of the macOS installer was called out by the Apple authority as something that will not work due to entitlements (or lack thereof).

Yeap, confirming what @milesleacy said, we had a two day on site with Apple SEs who told us firmware will only ever be able to be applied using the macOS Installer. That Apple broke auth-reboot on Combo Updates was a blessing in disguise, forcing our hand in deploying the full macOS installer, which ensured any computers that lacked firmware updates are now up to date in that area.

IMO as others have said, the time is better spent creating new processes using new tools Apple gave us in 10.13.4+. We can leverage these tools along with scripts to build an erase/install policy or macOS upgrade in JamfPro, so that any working/enrolled Mac can get an OS upgrade or erase/install of macOS. Fairly simple to set up. DEP can be quite a bit of work up front, it was for me, but we're cutting about 10 minutes off of deployment time per Mac.

I'm a Mac-engineering-team-of-one at my org, and mange about 1000+ devices. This past spring/summer/fall wasn't much fun since I had to come up with new deployment, "re-image" and DEP procedures. Great journey, however.

I didn't create my policy exactly as described in this link but here it what many have used:
https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/

I used this one for in-place upgrades of macOS:
https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh

Tim Perfitt @ TwoCanoes has done some interesting work with a project called Mac Deploy Stick that might be worth checking out -
https://twocanoes.com/macdeploystick/

Can anyone tell me how they are dealing with automating naming / BINDING to Active Directory ? Right now I have a "General" prestage enrollment for any general machines aka labs, carts, etc.

I like DEP but what are you doing to automate that process?

@Chuey That really depends on what drives your naming process. For me, I use a script that runs at enrollment to set the name based on serial number with a prefix to indicate desktop or laptop, then after the name is set I have a Policy with a Directory Bindings payload that does the actual AD bind.

@sdagley So we have a lot of buildings, say 25, and each building has acronyms. We use the acronym, location, and asset tags to build a name.

For example:
Building = Test Building Name
Location = LAB1
Asset Tag = 12345

My name would be "TBN-LAB1-12345"

Reason we do this is because then we create smart groups based on building prefixes in certain instances to scope purchased software to certain locations, bind to AD using name and building prefixes match OU's in AD.

Just trying to think how I can automate this. I thought about having a large text file with serial number and name separated by comma and doing some type of lookup against that file and naming it accordingly but seems like a lot.

@Chuey That does seem like a workable approach. Host your serial number to name mapping file on a local web server, then use curl from your naming script to download it and parse for the name belonging to the machine the script is running on.

@Chuey it is possible to do what you want with app deployment without having to name devices. Dependant upon your network you could set up subnets and buildings. Subnets can be used to limit the scope of policies and buildings can be used to show the location.

@Chuey I am currently testing this approach to renaming after enrollment, it seems to work pretty good. It was easy to setup as well.

https://www.macblog.org/post/automatically-renaming-computers-from-a-google-sheet-with-jamf-pro/

@jkaigler Wow, this is exactly what I needed. I just wrote a bash script that curls a CSV and then re-names the computer but I can cut a lot of commands by using the -fromFile flag. Thanks so much!

@dba_nc suggested:

I used this one for in-place upgrades of macOS:
https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh

Josh Roskos deserves Jamf's highest award for that script...and a keg or three of beer!

FWIW the osinstallersetupd issue is an Apple issue, easy fix based off Apple/Jamf recommendations:

https://github.com/kc9wwh/macOSUpgrade/issues/56#issuecomment-448854217
https://github.com/kc9wwh/macOSUpgrade/issues/56#issuecomment-448854878

Re: Naming:

I am unaware of any technical reasons why adhering to a computer naming convention matters. There may be process reasons or human preferences that call for a particular naming convention, however I find in the cost-benefit analysis that process and human habit can be changed more easily than trying to manage a thing that isn't designed to be managed.

One area where many admins get concerned about computer names is when binding to Active Directory. If you are binding Macs to Active Directory. My advice is "don't do that". The concept of binding Macs to AD fails most cost-benefit analyses. The details would fill a separate long essay, so I'll leave them out here but will be glad to discuss separately.

If you need a stopgap for AD binding until you can convince your org and leadership of the above, then AD does not care what the computer name, or even hostname, is. AD binding needs an identifier for the AD computer object. This can be literally any string, so long as it conforms to Microsoft naming conventions (tl;dr 15 characters or less, avoid special characters and computer terminology).

It is helpful here to recall that Macs have three names:
1. Computer Name - The user-friendly name for the system.
2. Local Hostname - The local (Bonjour) host name.
3. Hostname - The name associated with hostname(1) and gethostname(3)
Descriptions sourced from the scutil man page.

Item 3 is the DNS hostname for the computer. It is generally easier for humans and some common networking practices if the identifier used for AD computer objects matches the computer's Hostname (item 3 above). Luckily, the hostname is easy for IT to set and both difficult and generally not desirable for users to change.

Since the main desirable attributes for an AD computer ID are, in addition to conformity with MS conventions mentioned above, uniqueness and consistency, I recommend using the computer's serial number as both the AD computer ID for binding and as the Mac's hostname, setting the hostname like so:

#!/bin/bash



# Get computer serial number

serial=$( ioreg -l | awk -F'"' '/IOPlatformSerialNumber/ { print $4;}' )



# Set hostname

scutil --set Hostname $serial



exit 0

@milesleacy

Did I just read you saying Do not bind to AD?

Seb

+1 @scerazy for not binding. We're moving away as fast as we can. Pilot users have had a much better experience. Just getting formal ducks-in-a-row with our very strict security.