First run script to install provide feedback

For the main splash screen, jamfhelper is being used. Nothing would normally be able to appear over the top of it. Is your script running as part of Casper imaging?

In the past we've used the jamfhelper, but with our own custom messages and sometimes bighonkingtext (https://github.com/kitzy/bighonkingtext/blob/master/BigHonkingText)

We use Rich Trouton's https://github.com/rtrouton/First-Boot-Package-Install with our first run script and policy triggers to install stuff that needs to get installed after the reboot. Here is the script that is being run which gets changed to a payload-free package for First Boot Package Install: https://github.com/laurendc/scripts/blob/master/first_run_scripts/firstrunscript-20140925.sh

This method has allowed us to reliably install Adobe applications which can be a few gig depending on things - we used to use the JAMF method of ticking the box to bring up the "imaging process is installing" box but it was unreliable for us before so was replaced with this.

Techs seem to like it because they now have a ton of feedback for everything that has to happen after the Mac reboots.

Its been a kind of long standing complaint that the built in jamfHelper full screen message that comes up during the firstrun script is simply too much of a black box. No feedback on what's going on, no progress, no indication of how long this may take. I realize that some of that stuff is a little hard to do, but its not that hard. I have tons of scripts that I'm using with cocoaDialog for example that show actual installation progress and even how many packages in total are being installed. I'm sure JAMF could build something like this if they wanted to, but I've seen no movement to make the first run process more informative.
Issues like this with Casper Imaging's processes are why we continue to use DeployStudio. We can see what's happening every step of the way with a full log in the background. We wouldn't want an end user seeing all that, but the only people who see it are techs doing the imaging, so its not an issue.

I know this isn't necessarily directly helpful but this is the type of reason why I still build my own Base OS packages as opposed to chasing the best ways to use Never Booted OSs. Read as: I don't have the option to let a unit take it's time to install things. If I can't do everything in less than 10-15 min where a user can see it (less during orientation) I'm dead in the water.

One can always build a machine and then hand it to a user once the build is finished. If it took 15 mins or 15 days to build, as long as it's completed before it's handed to the user, why should the user care how long the build process took?

I absolutely agree that having a new machine "do setup stuff" for a long time before the user can actually use the machine is poor user experience and a bad first impression of your services.

You can also build big, fat images full of pre-installed applications that still have a never-booted OS.

In 2015 it's hard to justify monolithic golden imaging as a good practice for most environments.

@TSOAFTVPPC, what's your imaging workflow?

As @gregneagle advises, surely you can build or install whatever BEFORE handing it to your users?

@TSOAFTVPPC, as an example my workflow is linked below:

https://macmule.com/2014/12/21/my-casper-imaging-workflow/

Process takes tech about 5 minutes, Mac takes 90 minutes to image over 100MB. But Mac is finished for the user, all they need do is login.

I can see a few scenarios where a speedy deployment and setup is beneficial. Specifically small sites that don't have spare machines lying around. When a machine needs erasing and re-deploying quickly, it can get a bit annoying having to wait hours for larger packages to install.

Unfortunately it's hard to get close to the speeds we used to see with good old monolithic images when using modular deployment but there are so many more benefits I would personally never go back!

... Yea, I knew I'd draw a few comments on that one. For me it's my environment and deployment requirements. I don't want to side track the conversation though.

However, a lightly massaged base OS with some picky apps (not full scale suites like Adobe CC, can be packaged and deployed along with a compressed config if necessary, my high demand configs don't require them anyway and are available via self-service). I'm mostly referring to applications that must be installed after boot. If you can prep units in your own time that's fine. I don't always have the luxury. I have days where almost 400 students need to image their own computers within the limits of a normal class day.

In General I maintain only two base OS .DMGs and everything else is a .dmg, .pkg or script where applicable. I compress a few configurations as they are high demand user initiated configurations (pre-staged as well).

It's modular imaging, not thin and not mono (perhaps monolithic deployment though), It's just that I sometimes need a booted OS image instead of a non-booted image thus preventing casper imaging from having to installing post boot packages. Just say in' ;-) there's more than one way to skin a cat, just maybe not in every environment.

@Chris_Hafner, well if it works. :)

Have you a blog post on your workflow?

@bentoms well no, I should though. There are a few things I've been working on that can't quite see the light of day just yet but I could probably post most of it.

@TSOAFTVPPC are you getting anywhere with your issue?

Thanks for all of the feedback on this post. Was under gun to deploy a bunch of systems so we went full speed ahead without feedback. I will consider the tips offered for next time though!
In our environment we are deploying full Adobe Master collection plus Encore CS6, which complicates things. We found that Encore installs caused failure of Remote Update manger for Adobe CC14. So we install the cc suite after boot, not using the install at imaging option, but rather creating a dmg that caches the file locally along with a script that runs the installer.