Imaging new T2 Chip Machines

[jerdill]

I'm trying to get imaging working for the new T2 Chip machines. I know apple is trying to move away from imaging, but I don't see the sense in manually reinstalling the OS every time we want to start a machine over from scratch plus installing all the software/configurations etc. Anyway I feel like I'm close to finding a way to do this, but getting hung up in a few areas. I know this isn't specifc to Jamf, but with all the wealth of knowledge this group has out there I wanted to share here in case anyone had insight into this.

We have originally used DeployStudio to create and restore our images. I'm having a problem with the work flow currently on this new machine. I have it booted to an external drive with 10.14.2 installed on it. that drive has DeployStudio Runtime on it. If I restore our regular image its not bootable due to the "Encrypted at rest" flag on the preboot and the Recovery partitions. For example.

Out of the box the configuration of "diskutil apfs list" shows output with this. (not all information shown just the relevant part)

Volume disk1s1
name: macintosh HD
Filevault: No (Encrypted at rest)

Volume disk1s2
name: Preboot
Filevault: No

Volume disk1s3
name: Recovery
Filevault: No

If you notice the main drive shows Encrypted at Rest but the Preboot and the Recovery Partition do not show that.

If I use Deploystudio to lay down an image that I captured using the Capture task sequence in DeployStudio the layout changes to this:

Volume disk1s1
name: macintosh HD
Filevault: No (Encrypted at rest)

Volume disk1s2
name: Preboot
Filevault: No (Encrypted at rest)

Volume disk1s3
name: Recovery
Filevault: No (Encrypted at rest)

In this state the machine will not boot, it shows the flashing folder with a ?

I already mounted the Preboot volume to make sure the UUID folder is correct inside of that. The Bless -info also shows the correct information. I think the root issue is encrypted at rest component.

If I create an image with AutoDMG and restore that image it actually lays down the preboot and recovery partitions correctly without the encrypted at rest flag.

I can also use asr command line to restore the image I built but that only works if the preboot and recovery partitions are already there. If the drive gets formatted for some reason and I have to start from scratch the only workflow I have so far that works is to restore the AutoDMG image first, then asr restore my real image after that.

Couple things I looking for. Is there a way to make the AutoDMG image read/write so I can just edit that DMG to the correct image since that DMG file works as expected? I already tried hdiutil convert but it says the image is not recognized.

The other option would be a way to turn off encryption at rest for those partitions, or to delete them and create new ones without the encryption at rest enabled.

I'm totally open to other ideas on how to get this done. I can share more if needed, but this is already getting a little long. Please, if anybody has any insight into this, or if they figured out a way to do this in their environment please share! Thanks.

[cbrewer]

This may help you out...

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

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

[milesleacy]

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.

[davidacland]

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.

[marklamont]

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.

[ewinterbourne]

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.

[Hugonaut]

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....

[jerdill]

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

[milesleacy]

@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.

[kfjamf]

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!

[jerdill]

@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/

[milesleacy]

@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).

[donmontalvo]

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.

[dba_nc]

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

[wildfrog]

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/

[Chuey]

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?

[sdagley]

@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.

[Chuey]

@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.

[sdagley]

@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.

[marklamont]

@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.

[jkaigler]

@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/

[Chuey]

@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!

[donmontalvo]

@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

[milesleacy]

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

[scerazy]

@milesleacy

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

Seb

[easyedc]

+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.

[jonmacguru]

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.

[scerazy]

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)

[scerazy]

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

[howie_isaacks]

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.

[scerazy]

Where is the "fun" then...

[mschroder]

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

[howie_isaacks]

@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.

[djtaylor]

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?

[dgreening]

@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.

[tlarkin]

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

[scerazy]

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

[sdagley]

@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.

[scerazy]

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

[scerazy]

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