What does your (working) NetInstall/Casper Imaging environment look like?

So with the planned deprecation in Server functionality, are you looking to move off of this?

@easyedc I don't know what my plan is... Does Jamf have an official response on how to use Casper Imaging without NetBoot? I suppose I could ask them myself...

As of now, it's still an option, and should still work. Going forward, they are deprecating the option in the Server.app IF you do not already have it configured.

3rd party options like NetSUS are available, but I don't want to have to set up a linux server just to run my NetBoot image. As I had it set up before, it was shared with my caching server.

Apple's offered up NetSUS as a replacement, however IMHO the writing is on the wall, and Apple is going to force you to reinstall the OS at every imaging (that ability to strip out that firmware package - I bet we lose that). We're quickly migrating to a DEP enrollment, teaching our frontline staff to use the OTA installer, and then having the systems bake on our network for a bit to catch all the policies for new workstations. It's going to add a few hours to our workflow, but there will be less overall buttons to click, so to speak. There are a lot of people that's not a viable option for, but for us it works.

@easyedc So you do all your software installs via policies? I could convert over to this method, it'll just take some work. The problem will be for the frontline staff troubleshooting when policies don't finish properly for some reason. Casper Imaging never "skipped" software... but my experience is that sometimes policies fail for no reason at all and the logs have to be flushed and reran. That kind of troubleshooting is a bit outside what I'd like my tech to have to get into.

Yes, we've had most software install via policy for more than 5 years. I used to create a base image with AutoDMG, bake in admin and other service account, some plug ins, and office suite. after that, everything else came down via policy.

We currently still do imaging with Casper Imaging using the Target Boot mode. This requires an analyst to help the user but we are a School District so we may be in a different situation then your company.

We are also moving toward DEP but in our case that will still require an analyst to lay down a base image to go through setup. Most of our users, mainly students and teacher, would not know how to boot into recovery and restore the OS.

It appears that Apple is moving towards a more iPad setup where a wipe leaves the OS but just removed the user data. You can see the first steps of this with the iMac Pros. That will be interesting for the future.

We went the route of creating a "NetInstall NBI" for our NetSUS appliances.

https://support.apple.com/en-us/HT202770

You can generate a localized version of Internet Recovery to allow for an internal network reset of a device.

In our testing, it took about 20 minutes to reset the device back to Factory Defaults.
1. Option Boot
2. Select NBI
3. Select Disk Utility
4. Wipe Disk (APFS)
5. Close Disk Utility
6. Reinstall macOS on device.

That's what we're forced to move to - and then trying to utilize DEP to provision the device from the start. It's a pain.

The main issue is that it's not just NetBoot/NetInstall that are deprecated. The process of "imaging", that is, block-copying a full disk's worth of operating system, software, settings, etc., onto a target Mac's internal storage is deprecated. Imaging is well and truly dead, going forward. Even @gregneagle couldn't make it happen for iMac Pro.

You could say that NetBoot and imaging is still doable today, and will be doable on older hardware for some time to come. But does it make sense to re-engineer a backward-looking process? Wouldn't it make more sense to spend that time and effort building processes that will work for all Macs, both those that you have on hand today and the ones that you'll need to buy in the future? Even if you stand up a NetSUS, iMac Pro, and presumably future Mac models, cannot NetBoot, so that NetSUS' usefulness will decrease with every Mac purchase going forward. That seems like a waste of time and effort to me.

I'd like to address a couple of the comments in this thread in the hopes of making it easier to embrace progress.

that ability to strip out that firmware package - I bet we lose that

We already have. If you check your results on recent hardware and operating system versions, you'll find that while you can copy the firmware package out of an OS installer, and tell Installer.app to install it, it will not actually get installed. This is because only the OS installer has the entitlements required to install firmware on current hardware with current OSes. The answer is to install the OS using Apple's OS installer.
My preferred process is that when a Mac is returned to the org by a user and that Mac is still within its usable lifespan, the person who receives the Mac back into stock boots to macOS recovery, wipes the internal storage and installs a clean OS. The computer is then returned to inventory for later reissue.

The short takeaway here is: If you image Macs, you're messing up/failing to update their firmware.
This can cause failures of additional management and update processes.

sometimes policies fail for no reason at all

There's always a reason. Perhaps Apple and Jamf can both get better at documentation to help us find these reasons. Perhaps we can retrain our IT teams to replace all of the knowledge they have on troubleshooting imaging, which is no longer useful, with knowledge of MDM, DEP, VPP, Jamf, etc.

The paradigm of Mac management has changed. If your org hasn't kept up with the changes over the past few years, then you and your organizations have a choice - you can either dig in your heels and bury your head in the sand, refusing to adapt to the changes; or you can start implementing changes to your internal processes, workflows, assumptions, and standards to bring them in line with the reality of the situation. The latter is the way to success and the former is the way to damage your end users' ability to do their work, and that's never good for anyone.

As I like to say, you have the choice between small and uncomfortable changes on a regular basis or periodic urgent panicked changes under catastrophic conditions. You have to choose one. Unfortunately, if your org has had its head in the sand long enough, the first option comes off the table, but you can help create a new environment where you rarely, if ever, need to deal with panic and catastrophe in future.

Dangit @milesleacy for bringing thought and reason to this!?!