Image won't block level on netboot

Did you click erase target drive?

What versions of OS and JSS are you using? I had this issue trying to image from a 10.10 Mac with Casper Imaging 9.63.

I'm using 9.82 and 10.11.2

Which type for share is? sharing connection?
JDS or Distribution Point?

There's a bunch of things it could be.

First check that the version of JSS is 10.11 compatible (not likely but worth excluding anyway), that the version of JSS matches the version of Casper Imaging you're using, the image priority is 1 and that erase target drive is definitely checked.

Then I would troubleshoot it step by step:

• Test deploying the image with Disk Utility, to confirm that the image is ok.
• Try Netbooting and using Casper imaging, but pulling the image from a direct attached disk rather than a distribution point.
• Try excluding NetBoot by creating a second partition on your target Mac and running Casper imaging locally.

If it's none of those, I'd probably escalate to JAMF support.

I apologize if I'm asking something that's been answered somewhere else. However, if we're talking about using Casper Imaging to push a configuration down to a NetBooted machine, file level copy is the default method used. In order to get a full block copy you will need to compile the image first. Perhaps you are and I'm missing something or perhaps we're just talking about a simple OS only install. Mind helping me understand what you mean by "the install won't block copy."?

The base OS should still block copy, followed by standard installs for the rest of the packages.

@bazcurtis is that what you meant?

The OS I made was from a proper disk partition. I have now done it with an AutoDMG made OS image and that has block copied fine.

I haven't compiled it. Is this worth doing as well? This is just a AutoDMG El Capitan OS that I then uploaded to the Netboot server. I believed that once you ticked erase disk it would always block copy.

Thanks for the feedback.

@davidacland Thanks for that clarification regarding the OS.

@bazcurtis The primary benefit of compiling a configuration is: speed of imaging. When you compile a configuration the entire configuration (software, scripts, etc) will be wrapped up into a .dmg for block copy restore. At least until you modify the configuration in any way (i.e. new software, script, etc). Then it will (should) revert to a non-compiled image. In the end, it depends on what you want to accomplish. I compile my configurations before any mass imaging project but skip it during normal operations. The difference can be pretty amazing though if speed of imaging is important.

CAVEAT: If you've built an OS.dmg via Composer it will NOT install the captured recovery partition. You MUST use a non-compiled configuration if you wish for that to work. I'm not sure if AutoDMG OSs installs can still do that within a compiled configuration but I kind of doubt it. Someone here will be able to clarify that shortly.