Casper 9.7 Known Issues Section

ocla__09
Contributor

[D-006627]
When restarting a computer that has been imaged using Casper Imaging, the computer
fails to enroll if attempting to connect to the JSS via an Apple Thunderbolt to Ethernet Adapter.

If I am reading this right, this is a huge issue for this release. I don't know if anyone has ever tried to image over wireless before, but it is not really realistic for production use. When a machine in our environment finishes imaging over Ethernet, it normally reboots, enrolls, and gets the rest of the policies it needs as well as inventories. Sounds like this release requires an extra step of connecting to wireless to enroll the machine?

Once again, unless I am not reading this right...

16 REPLIES 16

stevewood
Honored Contributor II
Honored Contributor II

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

CasperSally
Valued Contributor II

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

ocla__09
Contributor

OK, thanks @stevewood

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

ocla__09
Contributor

Thanks @CasperSally !

tomt
Valued Contributor

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.

bentoms
Release Candidate Programs Tester

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

ocla__09
Contributor

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

bentoms
Release Candidate Programs Tester

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

bthomas
New Contributor II

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

Lotusshaney
Contributor II

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

dan-snelson
Valued Contributor II

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

Lotusshaney
Contributor II

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

nessts
Valued Contributor II

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.

Lotusshaney
Contributor II

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.

Lotusshaney
Contributor II

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

bpavlov
Honored Contributor

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.