Casper 9.7 Known Issues Section

@Oclassen that defect has been around for awhile now, and it is not technically a JAMF defect. It has something to do with Apple and is not something that JAMF can fix. At least that is what I have been told by folks at JAMF.

And for me, as of late, I haven't been having the issue as much as we did before. I still see it occasionally, but very rarely.

it's hard to believe the at-reboot script posted here by @golbiga couldn't somehow be implemented into their workflow somehow. I sent it to JAMF as a way to get around this months (a year?) ago

link to script

OK, thanks @stevewood

We have not run into this much in our environment, so it's probably less of an issue.

Thanks @CasperSally !

In my environment I've gotten around this by booting from an external drive instead of my netboot server to image with either my thin configuration (out of the box machine) or my full wipe and reimage configuration.

@Oclassen I've not seen this issue, because of the way I image.

Basically, as packages etc are installed once the Mac has rebooted from the NetBoot.. It takes time for me to login to it.

This allows for the network interfaces to be created & the Mac enrolled.

So it's a bullet dodged here.

Which is probably why I have not seen this issue much.

After a machine reboots in our environment it sits an average of 10 minutes to install extra software, bind create the AD User account etc

@Oclassen yep, so for us. Nothing to see here. :)

For what its worth, I had not experienced this bug in production or testing with ~15 different MacBook Air's using AutoDMG to create my OS image but as soon as I captured the OS image from a never-booted 2015 MacBook Air the issue was reproducible 100% of the time on the new model with the new image. To address the issue a very nice person on the forums here created a script which will create a Thunderbolt ethernet interface and I have the script set to run at first reboot. With this method I no longer have issues with imaging the new Macbook Air's.

For reference, our imaging process closely follows @bentoms instructions. A huge thank you to Ben for the work he puts into helping the community!

Link to the script: https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/enable_external_network_adapter/enable_external_network_adapter.sh

Fixed this by adding a "networksetup -detectnewhardware" as the first line in my first run scrit

Since we're now NetRestoring 10.10.3, we're going with @Lotusshaney's fix, too.

In case you're interested, here's a response from AppleCare:

AppleCare: We’re working with JAMF Software’s technical support on an issue with Thunderbolt Ethernet Adapters and Casper Imaging. Our current understanding is that there is an existing bug report (16523401) for this issue. Please advise any known workarounds / anticipated resolutions. Thanks.

AppleCare's response:

Thanks for reaching out to AppleCare for this issue. My understanding is that you’re seeking information about any workarounds related to bug report 16523401. That report has been closed for quite some time. The reported issue was that Thunderbolt Ethernet adapters were not recognized as a valid network interface at startup on machines that had a system restore image applied to them. The determination was that this was expected, as new network interfaces are detected a) on the very first system boot and b) at user login. A couple of workarounds were indicated: 1) Add a Thunderbolt to Ethernet adapter interface to the source machine prior to creating a system restore image. Attaching the adapter and ethernet cable prior to the source machine’s very first boot would likely be the easiest way to accomplish this. or 2) Attach a Thunderbolt to Ethernet adapter to an affected client, then log in to the client through the GUI. The adapter should be recognized as a valid interface after GUI login. Based on my own research, I believe running ‘networksetup -detectnewhardware’ should also allow the Thunderbolt to Ethernet adapter to be recognized as valid. Please let me know if you have any further questions about this topic. If this information satisfies your needs, you may simply reply to this email with approval to close the case. Thanks, AppleCare Enterprise Customer Support Engineering

I advised JAMF of this fix months ago, I even recommend that they write it into the fist run script generated by Casper Imagaing as the first line.

There response was it might break something else and why bother as a quickadd package might fix it.

Why fix it indeed JAMF, it's not IOS or a new feature so why bother !?!?

seems like you should just make your base images with many of the myriad of ways that are discussed on this forum, if you use a never booted image its not a problem. If you need a monolithic image that you had to boot for some reason, and you are doing a bunch of custom stuff, then use network setup to solve the problem. It just does not seem like this is JAMF's fault. but then again I tend to be on the wrong side of a lot of issues lately, and tend to think that we as users have some responsibility to use the tools properly, and I know how hard it can be to make a tool completely fool proof for every user, because only God above understands how so many of us can look at one problem and come up with so many different ways to do it.

I use clean, never booted images and using networksetup works great for my 5000 large Mac estate.

I understand that it's not JAMF's fault, but when there is a simple fix and they refuse to add it then who is to blame ?

This is not a cheap product and a defect that major with a simple solution should be fixed.

I understand too that Apple keeps moving the goal posts, but in the twenty years I've been supporting Apple computers that's never changed.

I do think JAMF do a good job but with Casper 9 I feel the push is on new features and not fixing the basics when they break, which seams to be something new with each point release.

This happens with clean never booted AutoDMG images and the networksetup fixes that too.

Have to agree with @nessts. If you are creating a monolithic image this becomes a problem. If you are creating a never booted image, it isn't a problem. It can be a somewhat steep learning curve to get to a modular or thin-imaging process down. There's packaging involved. Learning how OS X works if you're completely new to it. Some scripting. Learning preferences/profiles. And other things that I'm probably forgetting that just come with experience as you run into issues. And if you're completely new to OS X then it can be daunting to get all that done while also carrying out other regular job responsibilities. Some folks just have to get the job done and whatever is easiest can be very attractive as an option.

In this case, JAMF is right, there's nothing to fix per se. However, I do believe in creating and giving user's options. Similar to how there's an option to fix byhost, perhaps they can create an option to do a network detect on first boot. That's probably a feature request though and someone who perhaps has more of a vested interest should put it in and maybe it gets implemented. Definitely not hard to implement.