Computers not enrolling after imaging from 10.10 to 10.11

Sara, you're not alone here. I've observed some of this behavior. We're currently working through imaging ~270 lab computers, using a similar setup: Netboot > Casper Pre-Stage Imaging w/ Pre-Defined Configuration (set to erase a 10.10 partition, then clone a 10.11 image) > Reboot to enroll and create its management account. So far we've put 244 through this process (various models, and vintage). Out of that, 221 arrived on the other end managed and successfully running their respective policies. For the other 23, they all got through imaging successfully, then failed to enroll on the other end. We have observed a handful move from that state into getting managed/enrolled overnight (or a similarly lengthy timeframe). I've only had enough time to sample a few logs from computers in that category, and so far it appears to be networking issues in our environment:

There was an error. Connection failure: "The host jss.companyname.com is not accessible."

Recourse for those systems has been either troubleshooting the network connectivity issues (sometimes even a reboot will do) until it can reach our JSS to continue enrollment, or deleting the inventory placeholder for that computer created by Casper Imaging then retrying the whole imaging sequence. Either way, that seems to do the trick for us.

Besides these current issues, I know we encountered similar, but different, challenges while crafting one of our 10.11.4 images. That image needed to come from a surrogate computer used to install OS X 10.11.4, some peripheral hardware support drivers, and the whole Adobe Creative Suite (these installs unfortunately can't be accomplished through AutoDMG, they either need to be provided in a trigger-based policy, or through a traditional monolithic image)—Note, we previously attempted a thin-image scheme with that software installed through various policies, but found auditing Adobe (and a few other) policy failures to be far too time consuming, which is why monolithic image was appealing.

In that test, it turns out that SIP appears to restrict Apple's own Kernel Extensions from loading on some (newer) hardware which differs from the staging Mac used to compose the image, or something like that. SIP was identified as the culprit by disabling it on the newer computers having issues with networking or bluetooth connectivity problems. Once disabled, it appeared those clients had no issues loading the appropriate kernel extensions for their respective hardware. Then after re-enabling SIP, they went right back to having the same issues. I avoided disabling SIP as it can easily be undone (NVRAM reset) and it's a manual, non-trivial process, to redo.

Ultimately I chose a newer staging iMac to compose the same image. Luckily, the image wasn't problematic for the rest of our older install base when composed on the newest hardware. I think of this as yet another 'nail in the coffin' for monolithic OS X imaging, and another argument to continue using thin-imaging. I'd also like to say, this was something I encountered only while testing. And that while I've attributed the behavior to a relationship between SIP and kernel extensions, that is more of a logical leap than something I'm 100% positive about. So take these findings with a grain of salt.

I'd recommend first checking /var/logs/jamf.log to see what those problem-macs are doing after imaging completes — Heads up, casper imaging appears to preserve historical logging from the previous system, so read carefully. That threw me for a loop at first. I'd also think about how you've composed your 10.11 images and if you're running into something like what we encountered in testing, try disabling SIP on a few to see if that is at play. I've found single user mode to be handy for evaluating the jamf.log and troubleshooting connectivity on these problem-macs.