Imaging new T2 Chip Machines

I am using a combo of AutoDMG to create an apfs disk image of the latest macOS, and a script to wipe and recreate a fresh apfs structure on the internal SSD, then ASR in that script to image the Mac with the AutoDMG image. All of this runs while the Mac is booted from an external Samsung X5 Thunderbolt SSD, which is incredible fast. The script is totally destructive, but it does ask for confirmation before running. We run it as a .command file, launched from the Dock while booted from the external drive.

For T2 Macs, to use this process, I have to first boot up, create an admin account, then reboot to Recovery Partition to disable Secure Boot and allow booting from the external drive.

On the first startup after the re-image, the T2 Bridge OS will need to update before a fresh DEP enrollment can happen.
We reimage about 15-20 Macs a week and it works perfectly.

#!/bin/sh
#
##  This script is intended to be saved as a .command file and run from a macOS 10.14 or later external drive.
##  It's purpose is to find the internal SSD APFS structure, tear it down and create a new APFS Container
##  then restore latest macOS to the primary partition in that container.

#### Define Latest macOS image file name - This path is set based on where you place the dmg to be used.
diskimage="/10.14.3-18D42.apfs.dmg"


##  Find the current internal APFS disk and container, then delete it and restore latest macOS.  You will be prompted to continue as a safety check.
apfsdisk=`diskutil list | grep -A5 "internal" | grep -m 1 "Apple_APFS" | awk '{print $7}'`
apfscontainer=`diskutil list | grep -A5 "internal" | grep -m 1 "Apple_APFS" | awk '{print $4}'`
if [[ -z "$apfsdisk" ]]; then
        echo "I found no current internal APFS Disk. You will need to use Disk Utility to format the internal disk."
        exit 0
    else
    while true; do
    echo "An Internal APFS disk $apfsdisk was found. Its APFS Container is $apfscontainer"
        read -p "Do you really want to DESTROY this APFS drive? Type Yes or No then hit Return. " yn
        case $yn in
            [Yy]* ) echo "We will now destroy the APFS disk and container at $apfscontainer."
            diskutil apfs deleteContainer $apfsdisk
            sleep 2
            diskutil apfs createContainer $apfsdisk
            sleep 2
            #newdisk=`diskutil list | grep -m1 synthesized | awk '{print $1}' | cut -c 6-11`
            newdisk=`diskutil list | grep -B2 "Physical Store ${apfsdisk}" | grep "APFS Container Scheme" | awk '{print $8}'`
            diskutil apfs addVolume $newdisk APFS macOS SSD
            sleep 2
            sudo asr restore --source $diskimage --target /Volumes/macOS SSD --erase
            echo "APFS Disk macOS SSD Restored to latest macOS"; break;;
            [Nn]* ) echo "You selected No, so I'm quiting now. " exit;;
            * ) echo "Please answer Yes or No.";;
        esac
    done
fi

# Open Startup Disk to select re-imaged drive before restart.

open -b com.apple.systempreferences /System/Library/PreferencePanes/StartupDisk.prefPane
exit 0

##  Created by Jon Taylor on 2018-05-30.

Works a treat

As to OP, with Catalina one can just capture & restore APFS Container with all volumes in it (no need for .zips)
I am using it mainly for non-T2 devices, I can boot from hand created EFI Recovery Partition USB boot stick (with Refind ) and do the all whole process with a single .sh
USB is HFS+ formatted:
EFI partition has:
EFI --> BOOT --> refind_x64.efi renamed to bootx64.efi and rest of the x64 files from refind folder,
HFS+ partition has: UUID named folder copied from Preboot volume (plus the .sh itself & captured .dmg)

#!/bin/sh

hdiutil attach /Volumes/Image Volume/Catalina-10.15.6.dmg -noverify -nomount

diskutil eraseDisk HFS+ %noformat% gpt /dev/disk0

diskutil apfs createcontainer /dev/disk0s2

asr restore --source /dev/disk26 --target /dev/disk0s2 --erase --noprompt --useInverter

# http://blog.tempel.org/2019/05/cloning-apfs-volumes-containers-apfs.html
/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -s /dev/disk1

diskutil mount /dev/disk1s3
diskutil mount /dev/disk1s4

newuuid=`diskutil apfs list | grep -B0 "Volume disk1s1" | awk '{print $4}'`

mv /Volumes/Preboot/* /Volumes/Preboot/$newuuid
mv /Volumes/Recovery/* /Volumes/Recovery/$newuuid

I did not make variable for --source, because booting from this USB with 1 internal SSD, attached image is always disk26 (synthesized)

While it works perfectly fine for non-T2 older hardware, I wanted to see what happens with T2 MBP 2019
Same image (captured on non-T2 hardware) 10.15.6 Supplemental Update
Applies fine with same above script from USB Recovery boot.
But then I am given output:

|
+-- Container disk1 AC3AA5BF-580C-488F-B2CA-06EE7AFEAAA4
    ====================================================
    APFS Container Reference:     disk1
    Size (Capacity Ceiling):      121018208256 B (121.0 GB)
    Capacity In Use By Volumes:   27882680320 B (27.9 GB) (23.0% used)
    Capacity Not Allocated:       93135527936 B (93.1 GB) (77.0% free)
    |
    +-< Physical Store disk0s2 C0215E72-9265-44D0-8B01-01C6DF4EE5F2
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk0s2
    |   Size:                       121018208256 B (121.0 GB)
    |
    +-> Volume disk1s1 47CE903C-053E-41AB-8F64-196CFC3D5A05
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s1 (System)
    |   Name:                      Catalina (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         11373838336 B (11.4 GB)
    |   Encrypted:                 ERROR -69461
    |
    +-> Volume disk1s2 C3EA63AE-7E9D-4709-A334-715B196B089F
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s2 (Data)
    |   Name:                      Catalina - Data (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         15764234240 B (15.8 GB)
    |   Encrypted:                 ERROR -69461
    |
    +-> Volume disk1s3 2E5A392F-0A5F-4744-BC22-64C16C8B7895
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s3 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               /Volumes/Preboot
    |   Capacity Consumed:         85487616 B (85.5 MB)
    |   FileVault:                 No
    |
    +-> Volume disk1s4 A3D68D5F-909C-458F-BC81-9E6DB904856E
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk1s4 (Recovery)
        Name:                      Recovery (Case-insensitive)
        Mount Point:               /Volumes/Recovery
        Capacity Consumed:         532713472 B (532.7 MB)
        FileVault:                 No
-bash-3.2# diskutil mount /dev/disk1s1
Volume on disk1s1 failed to mount
This appears to be an APFS Volume; note that locked APFS volumes
will not mount unless unlocked (e.g. "diskutil apfs unlockVolume")
-bash-3.2#

Can reboot machine (and it boots ok-ish, login screen presents user icons (even hidden user) instead of username/password field as configured, so something gets reset, but NONE of the local users can actually login because password is not accepted)

So reboot to recovery & run resetpassword, which then gives unrelated error (this file simply does not exists in Recover boot (to me just a bug):

-bash-3.2# resetpassword
-bash-3.2# 2020-08-18 13:54:49.593 KeyRecoveryAssistant[655:3134] NSDisabledCharacterPaletteMenuItem=YES
2020-08-18 13:54:49.601 KeyRecoveryAssistant[655:3134] Use NVRAM prev-lang:kbd value (2) as default ASCII input source: British
2020-08-18 13:54:49.714 KeyRecoveryAssistant[655:3134] unable to obtain configuration from file:///Library/Preferences/com.apple.ViewBridge.plist due to Error Domain=NSCocoaErrorDomain Code=260 "The file “com.apple.ViewBridge.plist” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/Library/Preferences/com.apple.ViewBridge.plist, NSUnderlyingError=0x7fb44683dcd0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}
2020-08-18 13:54:51.544 KeyRecoveryAssistant[655:3143] Connected to daemon. Language set to: en_GB
Connected to daemon. Language set to: en_GB
2020-08-18 13:54:51.544 KeyRecoveryAssistant[655:3143] Connected to daemon. Language set to: en_GB

But main issue is that Volumes (Catalina & its Data) do not get mounted.

I know it is all not supported, I am not supposed to do it etc, but anybody has any idea why it behaves that way?
Learning is interesting! But these errors are also reported on real installs ie here

Even if a Mac is not in Apple Business Manager, the DEP Notify workflow still works well. We just erase and reinstall macOS, enroll the system into Jamf Pro, and let DEP Notify do its job. No issues with firmware, and the install process is reasonably fast. I understand the desire to use images, but I would prefer to just follow Apple's lead and stop doing imaging.

Where is the "fun" then...

The "fun" is in getting the configurations right with the MDM ;)

@scerazy The "fun" comes from the satisfaction that my configurations are working properly without a lot of trouble on my part. I have 8 Jamf Pro servers (soon to be 10) to manage. I don't have time to jack around with imaging when I know it's beating a dead horse.

We have some loaner machines that get re-imaged after use. We use ASM and Jamf and all has been working fine until 10.15. Now when we image a machine via Jamf - and add two local admin accounts, turn on encryption - the accounts do not show up in the Recovery partition when we go to try and erase the machines. So we have to choose "Erase this Mac" option and start all over.

Also noted that when we setup end user machines (end user is first to create an account) only end user shows up in Recovery as being able to unlock Recovery - not local admin which was added after the fact and enabled for FV with sysadminctl SecureToken script.

Would love to figure this out. Anyone?

@djtaylor We are seeing similar. We are using a prestage curated local user created for the user who auths to the ABM management setup assistant pane. Initially this account is admin, and has secureToken, but we demote it to non-admin after we grant other users secureToken (local admin accounts). Once this is done, the user account no longer shows up in recovery as a user who can unlock encryption. Annoying, yes, but we get around it by leveraging the FileVault key that is escrowed into Jamf. Sorry, Apple, but we aren't giving all users admin rights.

I would abandon imaging as soon as you can and use recovery + restore as Apple has made significant changes in breaking all imaging workflows.

@ mschroder & @howie_isaacks We obviously differ in definition of "fun". Do it by the book, step by step is not my kind of fun

@scerazy Do you define "fun" as the constant danger any workaround you've discovered to continue imaging will potentially fail with even a minor macOS update? And when, not if, it fails will your management be happy to hear because you wanted to have "fun" you're now scrambling to change your Mac setup workflow? At least the combo of DEPNotify and DEPNotify Starter are very simple to adopt, and as @howie_isaacks points out, will work whether or not you use ABM/ASM.

Believe me, on non-T2 chips, for me, image is STILL the way to go. My time is not dedicated to manage few Macs, yet I need to make them work, I can't "outsource" it to a technician. All I need is a single USB stick (actually SD micro card in USB reader), not even Jamf is needed
But ofcourse everybody has a right to they own opinion... and whatever workflow you feel like doing

Still now, against all advice, one can "image" or rather Replicate APFS Container in Big Sur on non-T2 machines without much of an issue, as explained here