Inconsistent Imaging Results

[mconners]

After four labs of Macs, roughly 90 Macs, I am getting very frustrated at the failure rate to actually finish the imaging process.

Our core OS was created with AutoDMG. It has worked for a while, but now we are on JSS 9.92.14660200067, the latest. Here is what is happening and I am only asking if others are seeing this as well.

The core OS and DMG's of applications appear to be installing everything fine. After this is finished and the reboot occurs, one of a few things can happen. What is supposed to happen is the first run script begins to install the pkg's and other items such as our scripts that run at reboot. In some cases, this actually works, the JAMF helper screen will appear.

In other cases, the setup assistant appears and the first run script never installs a thing.

Some cases, the first run script finishes and it restarts, however what was in the first run script simply doesn't install everything.

Finally, we have a few that the Temporary Adobe Install id opens but fails to install a thing. I have left Macs for an hour or more and nothing happens.

Are any of you seeing mixed results as well? I don't know how much effort I should go through to get this working more consistently only knowing I am not the only one. I was tempted to create a new core OS but not using AutoDMG. Last summer we were on version 9.8x and I don't recall any of this happening.

Thoughts? Thank you ahead of time for your response.

Mick

[jhalvorson]

Do all 90 macs use the same configuration for imaging? Just wondering if you have some that get dmg packages prior to the reboot and other configs do not. 99% of all our dmg/pkgs are installed "at reboot". For some pkgs, there are valid reasons that can't be installed prior to the reboot and you'll up a flawed OS or non-working jamf.

Yes, I have seen various issues post reboot. Sometimes the JAMF finishing installing full screen appears, sometimes the Apple ID setup assist is the only thing visible, sometimes I see the desktop with the Temp Adobe logged in. Most cases, it's a fluke and you can open the Console to view the jamf.log to see if any activity is happening. Very rare, but it does happen, that the jamf.log doesn't get created and none of the jamf startup script(s) run. The only solution has been to try again.

I think the key recommendation is to look in the jamf.log to see what is or isn't happening.

[mconners]

Thank you @jhalvorson for responding and sharing your experience. Those are the precise things I have been seeing. Fortunately for me, the image is the same one, lab in and out.

What I am attempting to do is rebuild the OS itself for both netboot and the core OS itself. Not sure if the results will be any different. I thought why not go back to what worked for me before pre-AutoDMG.

The jamf.log is a BIGGIE as I didn't think of that one. I will surely look into that. I only wished things were more consistent. Do you know @jhalvorson when the setup assistant screen appears can you click past it and still get the first run script to work? Just curious if I should simply abandon at that point and start over or be more patient.

[jhalvorson]

Oh, I forgot to add that I've been using a AutoDMG OS for a long time. That appears to work properly for us.

When the Apple ID or setup assistant appears, you can click on skip or cancels to get past it. Typically that will get you to the desktop and it will be logged in as the Adobe Temp account. You'll be able to open the Console application and view the jamf.log. The Adobe Temp account does not have admin rights, so doing some functions, such as using Terminal.app won't work and you won't be able to view the system.log.

When the JAMF is finishing installing software full screen is displayed, you can press command + q to exit the overlay. It won't impact JAMF processes in anyway, it just gets rid of the black screen overlay.

I usually open console, and watch both the install.log and the jamf.log. You might observe that, for example, Office 2011 install takes 7 minutes. It might give the impression via the jamf log that it's hung up. But if you switch to the install log, you'll be able see that Office is or isn't actively installing.

EDIT - We only use the AutoDMG dmg when rebuilding a mac. Not for fresh from the factory systems. We leave the OS in place for those. The Parent config does not include an OS and we don't format the drive. A child config includes the OS, it's specifically labeled "For Rebuild", and we do format the drive.

[GabeShack]

I've had imaging issues on almost each release of the Casper updates. My new "SureFire" method (aside from casper imaging unable to delete core storage on new machines) is the following.
I do not use install at reboot for any of my installs since this is what seems to cause the issues.

I've made a new image that auto logins to a local admin user by default. Then I call the jamf helper manually with the 1st part of the Enrollment Complete trigger. Then have any and all packages install via policy on the "Enrollment Complete" Trigger. Then I have it disable the auto login. And ending with software updates and a reboot.

Kind of a pain in the ass, but now it works without issue for me.

Gabe Shackney
Princeton Public Schools

[Eigger]

We see this issue only when netbooting. We have this issue on all versions of JSS since 9.6 up to the latest, and AutoCasperNbi with 10.9 up to 10.11 netboot images. We have a powerful xserve 3,1. 48 Gigs of RAM, 2 Xeon Quad Core, with 10 gig nic. Cisco 2960 Gigabit Switch. Even with those, we still keep seeing this problems, so we will stop doing netbooting next year. Now, we invested on External SSD Drives with thunderbolt and USB 3 ports to image. They are fast, convenient, and consistent. We are not seeing this kind of problems when imaging using hard drives instead of netboot. jamflog wasn't helpful, it doesnt show clearly whats failing, sometimes it shows it successfully finished all the process but it didnt. I think the problem is coming from the network. If we netboot less than 10 machines, problem somewhat goes away ("somewhat" because even with less than 10 machines, there are some that will continue to fail, the only way it works again is to re image the failed machine) We are using the usb image created from AutoCasperNbi. We partition the SSD External HD in to 2, One for the boot image with casper imaging app and one for the packages.

[stevewood]

Like @gshackney I've been using AutoDMG for a long while now, not just for imaging but also for creating NetBoot sets with AutoCasperNBI. I've sporadically had issues where the machine will reboot into the Temp Adobe account. Almost every time I've had the issue, it has boiled down to a problem with one of the packages I was installing.

I've written (a rather lengthy blow hard post) about how I handle imaging. Basically, I have a package file that contains a script and a LaunchDaemon. The script handles installing all software on the machines by calling the necessary policies by ID #. Using this method, I've had next to zero problems with my imaging workflow for new machines (do not replace OS) and for re-deploys (wipe and replace OS).

[mconners]

Thank you all for some great feedback. I am going to try to implement some of these things to see if the results are different. I wished I would have done this in mid June and not the end of July, I am off the last week for family vacation. Luckily, if this works out well, I should be able to fly through the remaining computers.

[freezig]

If the First Run scripts don't run or it logs into the temporaryadobe install account, I simply log into our admin user (createUser.pkg) open Terminal and manually run the postinstall script in /Library/Application Support/JAMF/First Run. If that doesn't work, since I'm using Target Disk Imaging, a re-image takes maybe 10 minutes. A re-image has been necessary on maybe 1% of our clients and needing to manually run the postinstal scripts has occurred on maybe 10%, probably less. I have never bothered troubleshooting beyond the above workarounds.

[stevewood]

@mconners I had a thought. I'm assuming that all of the machines you are imaging are desktops (iMac or MacPro), yes? I was looking at the process I use and realized that I have one more step in the process. I utilize a script that @golbiga wrote to enable external network adapters on laptops:

Enable External Adapters

You might try packaging that up and deploying it during imaging to see if that fixes the problem, if you are imaging laptops.

[mconners]

Yes @stevewood that is correct, the majority are desktops, but I will be doing a large number of laptops. Thank you for sharing this information.

I will be testing stuff tomorrow in one of the labs that was problematic for me today. I think I have made some headway, we will see tomorrow...knock on wood...

Thank you all.