Best way to ensure use of compiled?

Block copies are done at the volume level and affect the entire volume in one go, which is why they're so much faster. They'll only work for the initial package, which should be the OS package. After the initial package is installed via block copy everything else must work at the file system level.

You're not going to achieve block copy speeds when installing software unless you build a monolithic image to include the OS and software. If you can't do that for some reason then you're stuck with the speed of installing the software after reboot.

Hi Mbentley777,

Compiling a configuration (See the Casper Suite 8.5 Administrator's Guide, pages 248-249) will allow Casper Imaging to image a target volume by block copying a single disk image made up of the contents of your configuration.

For any packages that need to be installed on a booted system, check the box marked "This package must be installed to the boot volume at imaging time" in the Options tab of the package's Information window in Casper Admin (See the Casper Suite 8.5 Administrator's Guide, pages 114-115). This box signals Casper Imaging to cache the package to the target volume and install it with the first run script. When a configuration containing packages with this option selected is compiled, the package caching is rolled into the compiled disk image, so you can get block copies and install this software. Note that after the compiled disk image is block copied and the newly imaged system boots, the installations will execute locally.

I hope this is helpful.

@milesleacy I remember trying to compile images back in 7.x days and there were issues so we never bothered again. Now we have a client who is asking us to provide an image file. We'd love to, but this was our concern, stuff that had to be installed at reboot, scripts that have to run at reboot, etc.

How reliable is compiling an image under 8.52? Any issues with images that contain AAMEE produced packages? If the concensus is that it works without too many issues, we'll start testing.

Thanks,
Don

@milesleacy
With v8.51 when you compile a configuration from Casper Admin, if you have packages with “install at imaging time” ticked, those packages will not install after deploying the compiled configuration.
https://jamfnation.jamfsoftware.com/discussion.html?id=4322#responseChild20946

With 8.43 it was working fine. I have already logged a support call on this but haven't heard anything back from the QA team.

@Kumarashinghe @milesleacy I did a quick test and we still see issues where PKG installers fail to cache on the compiled image. This, despite having [x] This package must be installed ot the boot volume at imaging time set in Casper. Example is the naked Silverlight and Flash Player packages.

We are doing this logged on to a 10.7.4 computer as root user, we are on 8.43.

Don

external image link

@Don What happens if you try to install the package manually on the same machine with the same setup (10.7.4/root)? Check the install log.

Please try logged on to a 10.7.3 as an admin user and try to compile with 8.43. I don't use 10.7.4 atm as it has some certificate validation issues.

Miles, thanks for the response - my compiled image consists of the 10.7.4 ESD and the handful of Apple updates - Safari 5.17, Airport, Java etc.

If I use just that, I'm block copy, right as rain. If I use that as the basis for a smart config, it looks like the whole enchilada defaults back to file level - is that the expected behavior - and if so, should I just compile the smart config?

@Kumarasinghe The packages install fine manually. But they should not be installing when compiling the image; it should only cache and run on first reboot. The error seems to imply the package is in fact installing, even though it is set to install at reboot.

What kind of certificate issue exists with 10.7.4?

Don

Certificate Issues with 10.7.4
https://jamfnation.jamfsoftware.com/discussion.html?id=4465

@Don
Are you trying to compile a smart configuration? I've seen instances where you'll get these kind of errors. It seems like that "This package must be installed ot the boot volume at imaging time" flag is ignored.

Try this:
Create a new configuration and copy all of the packages in your smart configuration to this new configuration. Essentially, "flattening" your config. While not ideal, it's a workaround. Let JAMF know if this works.

@jarednichols

We've been using a dedicated configuration. The stuff we packaged that can be installed before reboot works fine, but the stuff that is supposed to cache and run on first reboot never does.

At first it didn't work because of errors, but we were able to find the problem installer (Silverlight), removed it, now the image compiles. But when the computer reboots, the first run is AWOL. :(

Never really spent a lot of time with compiled images since it never seemed to work out of the box. I did notice that the Computer Name and Hard Drive name are not what they were supposed to be. If I dig deeper I can probably find more issues. Compiled images and me, we don't get along.

PS, sory for the late response...hoping for a "notify when there are responses" checkbox on threads soon... LOL

Don

We're on Casper 9.72. We are considering using a compiled image built from a smart configuration to speed up our summer imaging process. However, we heavily utilize PKGs installed on the boot volume at imaging time. This thread, along with other research I've done, hasn't given a definitive answer if Casper successfully includes those PKGs in the compiled image to cache and execute at boot time.

In general, are compiled configurations more reliable nowadays?

@majedian21 Just tested this with a compiled config containing a 10.9.5 base image and two pkg's set to install after imaging. Imaging process did just this. Casper 9.72. Can't really say if the compiled configs are more reliable. We don't often use them unless we are re-imaging a bunch of clients at the same time. I feel like it takes too long to re-compile after small changes.

@johnnasset I also just compiled a configuration and it did not include any of the FirstRun scripts/packages. I imaged via target mode imaging and used a local share on the imaging workstation, which only had the compiled image in the CompiledConfigurations sub-folder.

Darn, I was really hoping to use compiled configurations this summer...

Smart configurations based on a compiled base image will probabyl always have to revert back to individual package installs.
The reason is pretty simple, the package installs are ordered based on their priority, if any package in the smart config has a lower priority than any package in the base config then the only way to install them in the correct order is to start from scratch and manually install every package.

@Look I may be misunderstanding your explanation, but how is that any different than re-compiling when I make a change in a standard configuration?

I would expect that a smart configuration, upon initiating a compile, would cache all FirstRun packages (both unique to the smart config and to its parent configs) in the compiled configuration DMG and create the FirstRun script based on that (also placed in the DMG). If I later make a change to the parent's package, it would require a re-compiling of the smart config.

With all of this, I am assuming that a compiled configuration is nothing different than imaging a computer the standard way and capturing a DMG image of that newly-imaged computer the moment before it reboots to run the FirstRun packages. Am I wrong about that?

@majedian21 Oh sorry I think I may have been the one that misread, I read it as imaging a machine with a smart config that was based on a compiled base config (as opposed to a compiled smart config, which I agree should work the same as a compiled base config I would have thought).

You right though, what you should end up with should be effectively a never booted computer install stored as a DMG.

You right though, what you should end up with should be effectively a never booted computer install stored as a DMG.

"Should" as in "this is expected behavior in the current version of Casper Suite"? Or "should" as in "yes, I agree that the software should do that, but unfortunately doesn't"?