I was always told that no question is a dumb question, but I am not sure about this one. I have to ask because I don't really know and it might lead me to some answers.
For some reason, I have always believed that packages from the developers should be installed after reboot during the imaging process. I have some packages from HP, Epson, Microsoft and more. Is this the case? Should by default, any pkgs be installed after reboot, can they be installed during the initial imaging phase or am I missing something?
Just curious what you folks are doing with packages (PKGs) and not DMG's. I thought I understood this, but now I am second guessing myself.
The answer to your question is, it depends. Many vendor/developer packages expect to be installed from the boot volume onto the boot volume, and some even expect to be run while an account is logged in. In those cases, yes, they would need to be set to run at first boot and not while booted from an imaging partition or Netboot, etc. There are certainly some vendor packages that don't fit this criteria and can be safely installed while the Mac is booted into the imaging environment. Unfortunately, other than asking here and other forums to see if anyone has run into an issue before with a specific package install, or doing some testing on your own will be the only real ways of knowing which are which.
OTOH, you can play it safe and set them all to be run at first boot. Its almost a guarantee that they should work that way.
@mconners I personally have all my packages installed on first boot in the temp Adobe Install account. The only thing that is installed before first boot is the OS. That is block copied from the AutoDMG created DMG. That way I don't have to worry about whether a package requires installation on a booted computer with a user logged in. This has generally been a very reliable method for me. Though I have fought the issue with the full screen JAMF helper window not coming up correctly on occasion.
Thank you for the responses. I too had all of my packages set to install at first boot with the adobe install account. I have been having nothing but issues with the process.
I have been working with my TAM on this and I don't have enough hair to continue pulling out more. Yesterday I had some answers to my other post about the imaging process in general and I may have to venture down another road to get this to work.
I have followed your saga and applaud you for your persistence. I must be in the small percent as the only packages I have run at reboot are adobe cc(limited machines)office 2016,setup script pkgs and munki setup script pkg. The only time I saw the inconsistencies you are coming across was on older hardware, particularly mid 2010 UniBody Macbooks, everything else (2011/2013 iMacs. 2011/2012 MacMinis,2012 Macbook Pro, 2012/2013 Macbook Airs) reboot right to Jamf install screen. I am currently on 9.65, but will be upgrading to whatever is the latest in my assets shortly. hang in there
@mconners I've seen a similar thing as what @LSinNY is mentioning about older computers. I have a 15-inch MacBook Pro (Mid 2010) with a stock Apple SSD that I use as a test machine and I don't get the JAMF splash screen at imaging time. It's been this way for many versions of Casper Imaging. I stopped using that computer to test whether Casper Imaging is working properly. I use newer hardware to verify my imaging workflow doesn't break when we move to a new version of Casper Imaging or a newer NetBoot image. I've also had the same problem when I test Casper Imaging using a NetBooted VMWare Fusion VM. So I stopped testing Casper Imaging with that platform as well. For me I prefer to test my Casper Imaging workflow on real hardware that we are currently deploying. Out of curiosity, what model Macs are you seeing the issue with the splash screen?
Thank you @mpermann and @LSinNY for your feedback. I am kind of behind an eight ball this year which is causing some of the angst you might be seeing in my writing. Most of hardware is getting dated at best. We haven't really don't a refresh of our Macs or PC's for that matter in a few years. This is causing the hardware to start lagging behind. The newer models however are also failing to image properly. I have resorted to removing almost everything from the first run script and the computers will sometimes work. Most of the time, they immediately log into the temp adobe user and sit there. Nothing else happens.
I have taken advice from others and watched the install.log and the jamf.log files and literally, nothing is happening. When I restart, it appears almost normal, but I don't trust it. I cannot in good faith leave a lab thinking it will be fine and move to another lab. I also cannot move to other buildings when I believe something might be amiss. Last summer I had some issues, but for the most part, the process worked really well.
Next summer, we are due for a huge refresh of our Macs so perhaps about 25% will replaced if our budget holds up. I am getting more worried about that, but right now, I have to be able to get this done. It is feeling as if something is not right with this version.
While there are work arounds as people have written about, I am a firm believer that the software should be doing this correctly as designed. Sorry for the rant...
Interesting. I completely understand running installs after boot, but perhaps I'm backward. I install during imaging unless I specifically HAVE to run them after first boot. It's mostly a speed issue. At this point, I would do one of two things. First, if I had the time I would be testing each package as you are. Second, if I were up against the wall, I'd compile the configuration and distribute it that way. Generally, I always compile configurations prior to mass imaging because the speed difference is dramatic. It will solve your issues at least temporarily.
That said, we've made a huge leap (for our environment) and moved to completely modular imaging from a non-booted OS, in hopes that it will make for cleaner installs on specific hardware. I'd venture to guess that compiling the configuration ahead of time may remove that benefit somewhat. I've spent years massaging and managing the deployment of booted OSs with great success and am hoping that I will be improving our own reliability by moving away from that cautiously.
I say this because I'm not sure how compiling the non-booted OS affects a large variety of machines. What have others seen?