Image Reboot Logs Into Temporary Adobe Install Account

@cstout, I've run into the same problem under versions 8.7.3 and 9.3. I've never been able to figure out what triggers this to happen. If I look at the jamf.log file I can see where in the first run script it is so I have an idea about when it's going to reboot into the actual user account. It would be nice if they could fix this bug though.

@cstout I would see this occasionally so I use a payload free package to make sure that jamfHelper actually launches at reboot.

#!/bin/sh
## postflight
##
## Not supported for flat packages.

## Lock down the login window 
/usr/sbin/jamf launchJAMFHelper -path '/Library/Application Support/JAMF/bin/jamfHelper.app'

I have been seeing this on about 1 in 15 macs we image in every 9.x version of Casper we have put into production. Simply rebooting seems to allow the Mac to finish the image process but that is not an acceptable option for a production environment.

@jhbush1973 How/when are you installing this payload free package? Are you choosing to "Install on boot drive after imaging" and setting a higher priority? I am sure this is straight forward but I am having one of those derp moments today I guess.

@FritzsCorner I set it to "Install on boot drive after imaging" with a priority of 1. I was seeing exactly what you describe along with installs that would sit there and actually finish, but never reboot for the second time.

@jhbush1973 Perfect! That's what I thought you were doing but just wanted to make sure. I will give this a shot and see if it works.

Thanks!

@jhbush1973 Thank you for posting your workaround. I'm going to use that until this issue is resolved.

I had this issue too, it was related to login scripts. You have to keep in mind that anything you have to run at user login is going to run for this temporary adobe account. It's best to get adobe installed before anything else to minimize the issues.

@tnielsen, What's interesting about my scenario is that I'm not using login scripts and not installing any adobe products.

If you have any installations that are set to install on the boot volume and therefore being run by the first run script, then I believe you will get the "adobeinstall" account and the jamfHelper fullscreen lock come up. I think there's already a request out there for jamf to rework this process and name it something more generic since its now used for more than just installing Adobe products (its a throwback to earlier days when they had to create this process expressly for Adobe's installers). The name of the temporary account it creates and the screen that comes up should both be updated to something more general now though.

Oh, well, that is interesting... I'd take a hard look at what you have installing after imaging.. specifically the order.

@tnielsen, Definitely interesting. What makes it even more interesting is that I only see it boot directly to the desktop and bypass the Casper Imaging splash screen when imaging MacBook Pros. When I run the same configuration on a Mac mini, for example, I see the splash screen and it images without a problem. The configuration below was structured with the items placed in the install on reboot because they simply wouldn't install without a reboot. I still haven't built out the payload-free package to kick off the jamfHelper fullscreen lock, but I anticipate that will alleviate this strange issue. Side note: In writing this response I did notice that I actually do have one Adobe product in my configuration, but I can't imagine that being the cause of this. Please, correct me if I'm mistaken.

external image link

@cstout as @mm2270 mentioned, when ever you have a pkg installing in the boot volume @ imaging.. You'll have the adobe install account created & logging into perform that action.

@jhbush1973 I setup a pkg just like you outlined and set it to priority 1 on reboot and this MacBook Pro still never loads the splash screen. It seems like the iCloud setup menu which is appearing for the adobe temporary login account is what is creating the hangup here.

@bentoms I understand that is the normal functionality of Casper Imaging, but what I'm outlining here is that the normal functionality is being interrupted by an out-of-the-ordinary event. I just wanted to make sure that it wasn't one of my packages set to install at first boot that was causing the problem.

What I think is strangest here is that the imaging process only interrupts with the iCloud login screen for the "temporary adobe install account" when imaging on a MacBook Pro. On my Mac mini, the splash screen shows and I never see the iCloud prompt or desktop of the temporary adobe account. I may have to open a bug report on this one, unless there's something I'm missing.

In all my experience with seeing this the packages that install after boot when imaging continue to do its thing its just that the lock/splash screen itself does not come up. But if you leave it alone it will run all the scripts and packages it is supposed to and then will restart. You just see the account because the lock screen doesn't come up.

Whenever I see this happen I just leave it alone till it restarts and it completes its post-imaging tasks as expected.

Not saying that it isn't annoying but it hasn't hurt anything in our environment either.

All of a sudden the same thing started happening on my end. I've got a domain join, printer install and an adobe CS6 package post install and it will login automatically into the temp adobe account. Everything works fine if I don't have the CS6 package. Just weird that I haven't updated the casper suite or any of the packages for quite a while now. Are you guys solving it with @jhbush1973 script?

@cstout - I've been stuck in the same boat you have been. Did you hear anything? Seems to be macbook pro's as well for me and i'm getting the same stuff you have been getting.

@michael.ferguson I have an open case with JAMF regarding this. Since the issue (at least in my case) is intermittent we're having a hard time finding evidence as to what is causing this to happen. I highly recommend contacting JAMF and opening a case to troubleshoot. The more people experiencing this issue and getting in contact with JAMF, the more likely we are to see a fix. As far as the script goes to call the splash screen, unfortunately it doesn't work for me. The fault is not that of the script though; it's simply being stopped before it can load just like with the splash screen being stopped (without a script calling it). I've only seen this issue with Mavericks, personally, so I believe a change in their loginwindow handling is to blame.

Long story short, contact JAMF and start collecting and sending imaging logs. We've got a lot of questions and not a lot of answers on this particular issue.

We had this issue since 2012 and this workaround fixed the issue for us.
https://jamfnation.jamfsoftware.com/discussion.html?id=5600#responseChild30922

We have notified our account manager in 2012.

Thank you @jhbush1973 for posting that fix. I have been banging my head against the wall on this one.

Luckily we didn't need the fix on our end. It was a combination of 1 of our 4 netboot images having an old binary of casper imaging on it and the binding domain credentials being locked out. I fixed both of these things and the issue is gone. Triple check everything people, spent a full week on this and it ended up being my bad :P YMMV of course

Bringing this back up because we're having this problem too. It just started happening out of nowhere… the only difference is rather than using the traditional OS X build for imaging we're using AutoDMG and a tweaked version of this script from @rtrouton: https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/first_boot/10.9/first_boot.sh

I wonder if putting the script in with the login window delay is causing the issue. I just having it running in the imaging process on it's own, not in any kind of payload-free package or anything like that. Maybe the workflow of the script is the issue?

I've done no further testing on this to nail anything down but I also noticed that certain netboot images with certain models were causing this issue as well. We have 4 netboot images and on some macbook pro's I've noticed this happens with 1 of the netboot images (our latest, built on a newer model machine). Don't know how much this helps or not. Stuck with one of the older netboot images and they work perfectly. very odd =(

@emilykausalik,

It may be related to when that firstboot script is running. In my own shop, my own firstboot install process installs a package that installs the firstboot script and a launchdaemon in place, but does not actually run the script. The launchdaemon gets loaded after the machine reboots, so the script itself is run during that next reboot. The way I use it, it's actually more of a secondboot script than a firstboot script.

@rtrouton

I started to wonder if the laucndaemon was causing the issue we were running into… not because of your script but because of how I was using it. I really just wanted it to set some basic OS configs during the imaging process, so I took out the launchdaemon and login screen load/unload to test and see if it would simply apply those configs without the sleep or pause. I'm still on the newer side of scripting and understanding the need for order/steps/etc. for some of these things ( I totally sound like I don't know what I'm talking about, that's slightly true)… we'll see if the updated version simply lays in the preferences I want and see if it handles the adobeinstaller account a bit better this time around.

I kind of hate that adobe installer account, if only because it takes this super helpful script https://github.com/kitzy/MacDeploymentScripts/tree/master/makeAdminUser and renders it kind of useless because it just makes the adobeinstaller account the admin. Blergh.

Well, looks like commenting out those launchdaemon/login window lines in the script did the trick. Imaging workflow is back to normal.

Thanks again, @rtrouton, for all of your helpful insights and for the kindness of sharing your scripts and hard work with other Mac admins.